---
title: What File Permissions Should WordPress Use?
description: The file permissions WordPress needs on a cPanel account, why 777 is never the fix, and a ten-minute check you can run today.
date: 2026-09-28
updated: 2026-09-28
tags: [security monday, wordpress, file permissions]
url: "https://drivenhost.com/blog/wordpress-file-permissions"
author: DrivenHost
---

Most of the compromised sites we help clean up were not broken into by anything clever. Something had write access where it should not have had it, a file appeared that nobody uploaded, and the site started serving spam a week later. Permissions are the unglamorous part of WordPress security. They are also one of the few settings you can get right once and then mostly leave alone. So that is where this week's Security Monday lands.

## What the numbers actually mean

Every file and folder on a Linux server carries three sets of permissions: one for the owner, one for the group, one for everyone else. Each set is a number. Read is 4, write is 2, execute is 1, and you add them together. So 6 means read and write, 7 means all three, 5 means read and execute.

That is why you see values like 644. The owner can read and write the file, the group can read it, everyone else can read it. Folders need the execute bit to be opened at all, which is why directories are usually 755 rather than 644. Nothing mysterious is going on. The numbers just look like a password.

## The values WordPress expects

The WordPress handbook is clear about the defaults, and they have not changed in years. Directories should be 755, files should be 644, and `wp-config.php` should be tightened further because it holds your database credentials. The handbook suggests 440 or 400 on shared servers so that no other account can read it.

On a cPanel server like ours, PHP runs as your own account user, so your files do not need to be group or world writable for WordPress to work. If a plugin tells you a folder is not writable and that folder is already 755 and owned by your user, the problem is almost always ownership, not the permission number. That is a support ticket, not a chmod.

One exception worth knowing: some older installs end up with `wp-content/uploads` set wide open so that media uploads work. They do not need it. 755 is enough.

## Why 777 keeps showing up

Here is the pattern we see constantly. A plugin throws a write error, the owner searches for it, some forum post from 2014 says to chmod the folder to 777, and the error goes away. It goes away because 777 means anyone at all can write to that folder, including any process running on the server and any script an attacker manages to sneak in.

If a vulnerable plugin gives someone a foothold, a world writable uploads folder is where they will drop their backdoor, because it is the one place that survives a core update. We covered that behaviour in more detail when we wrote about [what a hacked site looks like from the server side](/blog/hacked-site-server-view). The permissions were nearly always part of the story.

If 777 genuinely makes something work, treat that as a symptom. Ask what user the file is owned by and why your PHP process cannot write to it.

## Where wrong permissions come from

Almost nobody sets 777 on purpose across a whole site. It arrives by accident:

Bulk chmod from an FTP client, where someone applies one value recursively to files and folders together and every file ends up 755 or worse.

Migrations. A backup restored from a different server, or a site copied by an old script, can land with ownership split between two users. The quick workaround was loosening permissions, and it never got tightened again.

Files uploaded under a separate FTP account, which then belong to that user rather than the account user, so WordPress cannot update them cleanly.

Malware itself. Cleanup scripts we run often find permissions that were changed by the intrusion, not before it.

## A ten-minute check

Open File Manager in cPanel, go to your site's document root, and turn on the permissions column. Sort by it if you can. You are looking for anything ending in 7 in the second or third digit, and anything unusual sitting in `wp-content/uploads`.

To fix it in bulk, File Manager lets you apply permissions recursively with separate checkboxes for files and directories. Set directories to 755 in one pass and files to 644 in a second pass. Do not apply one value to both. If you have SSH on your plan, the two standard commands do the same job:

```
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
```

Then set `wp-config.php` back down to 400 or 440, load the site, upload a test image, and confirm the dashboard still updates plugins. If something breaks after that, the permissions were hiding an ownership problem and it is worth getting it looked at properly rather than loosening them again.

Permissions are one layer. They pair with the account-level controls we went through in [hosting account security](/blog/hosting-account-security), and they are part of the baseline we set on new [shared hosting](/hosting) accounts. If you are not sure what your site is running with right now, or a permission change broke something, open a ticket with [our support team](/support) and we will look at the actual file listing with you.

## Sources

- [Hardening WordPress, WordPress Advanced Administration Handbook](https://developer.wordpress.org/advanced-administration/security/hardening/)
- [Changing File Permissions, WordPress Advanced Administration Handbook](https://developer.wordpress.org/advanced-administration/server/file-permissions/)