Most WordPress security advice focuses on plugins, passwords, and SSL certificates. File permissions? They sit quietly in the background, misconfigured on the majority of sites we audit, and nobody talks about them until something breaks — or gets exploited.
That's not an accident. Permissions feel abstract. Numbers like 755 and 644 don't explain themselves. But these numbers control who can read, write, and execute every file on your server. Get them wrong in one direction and your site breaks. Get them wrong in the other direction and you've left a door open for attackers.
This article explains what WordPress file permissions actually mean, why incorrect settings are a genuine security vulnerability, and how to fix them without guessing.
The Number System Nobody Explains Properly
Unix-based file permissions use a three-digit octal number. Each digit maps to a permission group:
- First digit — Owner (the user who owns the file)
- Second digit — Group (other users in the same group as the owner)
- Third digit — World (everyone else, including the public)
Each digit is the sum of three possible values:
- 4 = Read
- 2 = Write
- 1 = Execute
So 7 = 4+2+1 (read, write, execute). 5 = 4+1 (read and execute, no write). 6 = 4+2 (read and write, no execute).
That makes 755 mean: owner can read, write, execute — group and world can only read and execute.
And 644 means: owner can read and write — group and world can only read.
Now apply that to WordPress. Your files and folders live on a server. The web server process (Apache or Nginx) runs as a specific user. WordPress's PHP processes run as a user. If you're on shared hosting, your files might be owned by a different user than the web server process. This matters enormously — and it's why a blanket chmod 777 "fix" is one of the most dangerous shortcuts in WordPress development.
What WordPress Actually Needs
There's a standard that WordPress itself documents and that most experienced server administrators follow. Here it is plainly:
- WordPress root directory →
755 - wp-admin/ →
755 - wp-includes/ →
755 - wp-content/ →
755 - wp-content/themes/ →
755 - wp-content/plugins/ →
755 - wp-content/uploads/ →
755 - All .php files →
644 - wp-config.php →
440or400 - .htaccess →
644
Folders at 755 means WordPress can traverse them. PHP files at 644 means the web server can read and execute them, but nobody except the owner can write to them. That's the principle of least privilege applied to your file system.
wp-config.php deserves special attention. This file contains your database credentials, authentication keys, and salts. Setting it to 440 means only the owner and group can read it — nobody can write to it from the outside. On some server configurations, 400 (owner-read-only) is even tighter. Either way, 644 on wp-config.php is negligent.
Where It Goes Wrong: The Two Failure Modes
Failure Mode 1: Permissions Too Permissive (777)
This is the dangerous one.
777 means everyone — owner, group, and world — can read, write, and execute. Most servers have the web server running as www-data or apache, a system user with no elevated privileges. But 777 permissions mean that if any file on your server gets compromised — through a vulnerable plugin, a poorly written theme, or an exposed upload — an attacker can write new files to your WordPress installation.
Across dozens of WordPress security audits, the pattern is consistent: sites compromised with malware injections almost always have one of two root causes. Either a plugin with a known CVE was never updated, or file permissions were set to 777 somewhere in the wp-content/ directory — usually by a developer who did it temporarily "to debug an issue" and never changed it back.
That's not a hypothesis. It's a pattern you see after cleaning enough infected sites manually.
When an attacker can write to your file system, they don't just deface your homepage. They install backdoors. They inject redirect malware into wp-settings.php. They drop PHP shells into wp-content/uploads/ — a directory that rarely gets scanned because it's assumed to contain media files, not executable code.
Failure Mode 2: Permissions Too Restrictive (400 on Everything)
The overcorrection is its own problem.
Locking everything down to 400 breaks WordPress's ability to write to itself. Plugin updates fail silently. The wp-content/uploads/ directory can't accept new media. WordPress's cron jobs — responsible for scheduled posts, plugin background tasks, and cleanup operations — may start throwing errors because they can't write temporary files.
If you've ever seen an inexplicable error after "tightening security," overly restrictive permissions are often the cause. WP-CLI can help diagnose this: running wp option get upload_path or checking error logs via wp cron event list will often surface permission-related failures before they become visible to end users. Transients failing to store properly in wp_options is another symptom — the database write works, but if the object cache layer relies on file-based caching with locked temp directories, you'll see stale data and performance degradation side by side.
The correct approach isn't maximum restriction. It's appropriate restriction.
The Special Cases That Trip Everyone Up
wp-config.php
Most tutorials tell you to set wp-config.php to 644. Don't. 644 makes your database credentials readable by group and world processes on a shared server. Use 440 minimum, and if your server setup allows it, 400.
One additional layer: WordPress itself recommends moving wp-config.php one directory above the WordPress root. Combined with 400 permissions, this means even if someone traverses into your WordPress directory, they don't have a path to your database credentials.
The Uploads Directory
wp-content/uploads/ is a common attack vector because it must be writable — WordPress needs to store images there. But writable doesn't have to mean executable.
On Apache, you can block PHP execution in the uploads directory by adding a custom .htaccess file inside wp-content/uploads/ with this content:
<Files *.php>
deny from all
</Files>
This allows WordPress to write image files but prevents any PHP file dropped into that directory from executing. This single rule neutralizes one of the most common file-upload attack vectors. It's a two-minute change that most sites never make.
wp-cron.php
WordPress's default cron system runs via HTTP requests to wp-cron.php. If permissions on this file are wrong, or if you're running a real server-side cron job via WP-CLI (wp cron event run --due-now) and the file ownership is mismatched, cron failures accumulate silently. Scheduled posts don't publish. Transients don't get cleared. wp_options bloat builds up because the cleanup hooks never fire.
This is one of those slow-decay failure modes that doesn't show up in your uptime monitor. The site appears functional. Traffic continues. But underneath, the database accumulates autoloaded garbage, expired transients never purge, and the cron queue grows until something more visible breaks.
Understanding File Ownership (The Other Half of the Equation)
Permissions alone tell only half the story. Ownership — controlled by chown — determines which user the permission bits actually apply to.
On a properly configured VPS, your WordPress files should be owned by your system user (say, ubuntu or deploy), and the web server (www-data) should be in the same group. That way, 755 on directories means the web server can read and traverse — but not write. 644 on PHP files means the web server can read — but not write.
Where this breaks down is on shared hosting, where the web server and your file owner are the same user. In that configuration, 644 on PHP files still works, but ownership-based isolation between sites disappears. This is why shared hosting is structurally less secure than a properly configured VPS, regardless of the chmod settings you apply to WordPress files.
If you manage WordPress via WP-CLI and run commands as a different system user than the file owner, you'll start seeing permission errors on things like wp plugin update --all or wp core update. The fix isn't to chmod everything to 777 — it's to align the user running WP-CLI with the actual file owner, or use sudo -u www-data wp ... as appropriate for your server's configuration.
How to Audit and Set WordPress Folder Permissions Correctly
Using SSH
Here's how to set WordPress file permissions correctly in one pass:
# Set all directories to 755
find /var/www/yoursite -type d -exec chmod 755 {} \;
# Set all files to 644
find /var/www/yoursite -type f -exec chmod 644 {} \;
# Lock down wp-config.php
chmod 440 /var/www/yoursite/wp-config.php
# Ensure uploads directory is writable by web server
chmod 755 /var/www/yoursite/wp-content/uploads
Replace /var/www/yoursite with your actual document root.
Checking Current Permissions
ls -la /var/www/yoursite/
Look at the permission string on the left. drwxr-xr-x is 755 on a directory. -rw-r--r-- is 644 on a file. -r--r----- is 440.
If you see drwxrwxrwx anywhere outside of a temp or cache directory, that's 777 — and it needs to change immediately.
On Shared Hosting (No SSH)
Most shared hosting panels (cPanel, Plesk) include a File Manager with a "Change Permissions" option. You can right-click any file or folder and set the numeric value. It's slower, but the same rules apply.
If your host doesn't give you SSH access and permission changes require a support ticket, that's a signal your hosting environment doesn't give you the control your site's security requires. Factor that into your infrastructure decisions.
The Maintenance Problem Behind the Permission Problem
Here's the part nobody says directly: file permissions drift.
You install a new plugin, and its installer temporarily elevates permissions to write files — and doesn't reset them afterward. You run a debug session and chmod something to 777 to eliminate variables. A WordPress core update rewrites certain files and your automation doesn't include a permission reset step.
Over months, your permission structure becomes inconsistent. Some files are too open. Some are too locked. The result isn't a dramatic hack — it's a slow degradation of your security posture that becomes exploitable the moment a plugin vulnerability surfaces.
This is exactly the kind of thing that should be on a recurring WordPress maintenance checklist — not as a one-time fix but as a periodic audit item. Most site owners never look at permissions again after initial setup. That's the gap attackers rely on.
If you want to understand the full scope of what server-level WordPress maintenance involves, our WordPress support and maintenance services cover this as part of a structured care plan — not a list of things we'll do if you ask.
What a Permission Audit Actually Looks Like
A proper audit doesn't just run find and reset everything to defaults. It includes:
- Identifying file ownership — who owns each file, and whether that matches the web server user
- Checking for world-writable directories — especially in
wp-content/ - Auditing
wp-config.php— permissions and location - Reviewing
.htaccess— permissions and content, particularly the uploads directory execution block - Testing post-audit — confirming WordPress can still write to uploads, run cron, and update plugins without errors
If you're on a WordPress care plan that includes security hardening, this should be part of what you're getting. If your current plan doesn't include server-level permission auditing, you have a security plan in name only.
The Default Belief Worth Challenging
Most site owners assume that security means installing a security plugin and calling it done. Wordfence will scan your files. iThemes Security will block IPs. These tools have value. But they operate at the application layer.
File permissions are below that. A security plugin can't fix a 777 directory. It can alert you — sometimes — but it can't restructure your file system ownership model. That requires server-level access and someone who understands the difference between chown and chmod and why both matter for WordPress security.
Application-layer security without server-layer hygiene is incomplete. It's like locking your front door and leaving your basement window open.
Fix This Before It Becomes an Emergency
If your WordPress site runs on a VPS, a dedicated server, or any environment where you have SSH access, auditing your file permissions takes less than ten minutes. The commands are straightforward. The logic isn't complicated.
The reason most sites run with incorrect permissions for years isn't complexity. It's that nobody scheduled the audit. Nobody owns it. It sits outside the mental model of "WordPress maintenance" for most owners.
Look — I'm writing this because this is a problem I see constantly, and it's also exactly what we built Vimsy to solve. If you want professionals handling this instead of hoping nothing breaks, book a free call.
Your WordPress file permissions are either correct right now, or they're not. The only way to know is to check.
Arslan Aslam is the founder of Vimsy and has been working with WordPress at the server level for 13+ years. If you need emergency help with a hacked or misconfigured site, see our emergency WordPress support service.
