WordPress File Permissions: The Complete Guide to Securing Your Site

If you run a WordPress site and you’ve never audited your wordpress file permissions, you are leaving the front door wide open — and attackers know it. Security Misconfiguration now ranks #2 on the OWASP Top 10 2025, up from #5, with 719,084 recorded occurrences across mapped CWEs. File permissions are a core component of that misconfiguration category — and WordPress sites are getting hammered for it. If you care about cybersecurity for small business, this is the starting line, not an optional extra.

WordPress powers roughly 42.6% of every website on the internet. That makes it the single biggest target in existence. Over 90,000 attacks per minute target WordPress sites globally, and 96.2% of all infected CMS websites in 2024 were running WordPress. Getting your wordpress file permissions wrong is not a minor housekeeping issue — it’s handing attackers the keys to your kingdom. This guide exists to make sure you never make that mistake.

We’re going beyond what every other guide covers. Yes, we’ll explain 644 vs 755, how to chmod via SSH, and how to fix a 403 error. But we’re also going to show you real attack scenarios, the critical difference between file permissions and file ownership (the gap that breaks most hardening attempts), and advanced hardening techniques the competition glosses over entirely. Lock and load — let’s secure your site.

What Are WordPress File Permissions and Why Do They Matter?

WordPress file permissions are rules enforced by the server’s operating system that control who can read, write to, or execute each file and directory on your WordPress installation. Every file sitting on your Linux server — your theme files, plugin code, configuration files, uploaded images — has a set of permissions attached to it. Those permissions determine whether WordPress itself, your hosting server, visitors, and potential attackers can interact with those files.

Think of wordpress file permissions like a security clearance system. Some personnel (the file owner) get full access. Others (a group) get limited access. And the general public gets whatever’s left. Set the clearances right, and everything runs smoothly and securely. Set them wrong in either direction — too open or too closed — and you’ve got problems. As Sucuri’s security team puts it:

“If permissions are too loose, malicious users or scripts may access, modify, or delete files or inject malicious code, which can compromise security and performance. If permissions are too strict, WordPress may not perform certain operations like updating, installing plugins, or uploading media.” – Rianna MacLeod, Marketing Manager, Sucuri

The Three Permission Types: Read, Write, and Execute

Every wordpress file permissions setting is built from three basic permission types:

• Read (r): The ability to view the contents of a file, or list the contents of a directory. Without read access, a file might as well not exist to that user.
• Write (w): The ability to modify, create, or delete a file. For directories, write permission controls whether new files can be created inside. This is the permission attackers most want to gain.
• Execute (x): For files, this means the ability to run the file as a program or script. For directories, execute permission is needed to access (traverse) the directory at all — even if you have read permissions.

How File Permissions Protect Your WordPress Site

Correctly configured wordpress file permissions create layered barriers against attackers. If a plugin vulnerability allows an attacker to try uploading a malicious PHP file, restrictive permissions on wp-content/uploads can stop the file from being executed even if it lands on the server. If your wp-config.php file (which contains your database credentials) has tight read permissions, a compromised script elsewhere on the server can’t simply read your passwords. Every permission you set correctly is another layer the attacker has to get through.

Understanding Linux File Permission Numbers

When you look at wordpress file permissions through FTP or SSH, you’ll see numbers like 644, 755, or the dreaded 777. These numbers aren’t arbitrary — they’re a compact notation for a very logical system. Understanding this notation is non-negotiable if you want to manage wordpress file permissions with any confidence.

Owner, Group, and Others Explained

Every file on a Linux server has three classes of users it cares about:

• Owner: The user account that owns the file. For WordPress installations, this is typically the user account associated with your hosting account (e.g., “johndoe” or “www-data”).
• Group: A collection of user accounts. The web server process (Apache or Nginx) may run under a specific group. Files can be accessible to all members of that group according to group permissions.
• Others: Everyone else — any user on the system who isn’t the owner and isn’t in the file’s group. On a shared hosting server, this could mean thousands of other hosting accounts.

Breaking Down 644, 755, and 777

Each digit in the permission number represents the combined permission value for one of those three classes. The individual permissions have numeric values: Read = 4, Write = 2, Execute = 1. You add them together to get the digit for each class.

File Ownership vs File Permissions (The Difference Most Guides Skip)

Here’s the part that trips up even experienced admins: wordpress file permissions and file ownership are two separate things, and you need both to be correct. Permissions define what actions are allowed. Ownership defines who those rules apply to.

Imagine you set your wp-config.php permissions to a perfectly restrictive 600. Great. But if the file is owned by a different user than the one your web server runs as, WordPress can’t read it — and your site breaks. Conversely, if files are owned by the web server user (www-data on many servers) when they should be owned by your account user, updates made through FTP may fail because FTP connects as your account user, not www-data.

On most properly configured shared hosting setups, WordPress files should be owned by your hosting account’s username. On VPS servers, the ownership configuration depends on whether you’re using suEXEC, PHP-FPM, or running Apache/Nginx as a shared user. Understanding WordPress user roles and how they map to server-level user accounts is an underappreciated part of this equation. Always run ls -la via SSH to check both permissions AND ownership simultaneously.

The Correct WordPress File Permissions (Complete Reference)

The official WordPress.org documentation provides clear baseline recommendations for wordpress file permissions. Here’s the complete reference, expanded with the nuance other guides leave out.

WordPress Directories: 755

All WordPress directories — including the root WordPress folder, wp-admin, wp-content, and wp-includes — should be set to 755. This gives the owner full read/write/execute access, while the group and others get read and execute (needed to traverse the directory). Never set directories to 777. The execute bit on directories is required for access — removing it entirely (e.g., 644 on a directory) will break navigation through that directory entirely.

WordPress Files: 644

All standard WordPress files — PHP files, CSS, JavaScript, and other assets — should be set to 644. This allows the owner to read and write while everyone else can only read. The web server needs to be able to read PHP files to serve your site, but it does not need write access to them during normal operation. Giving write access to group or others is how malicious code gets injected into your theme and plugin files.

wp-config.php: 600 or 640

Your wp-config.php file is the crown jewel of your WordPress installation. It contains your database name, username, password, authentication keys, and salts. This file should be set to 600 (owner read/write only, everyone else gets nothing) or 640 (adds group read — needed on some server configurations where the web server runs under a different group than the file owner). Before you edit your wp-config.php, make sure you understand what you’re touching. The WordPress.org core team is direct on this: “From a security standpoint, even a small amount of protection is preferable to a world-writable directory.”

.htaccess: 644 or 444

Your .htaccess file controls URL rewriting, access rules, and various server behaviors. Set it to 644 for normal operation (WordPress needs to be able to update it when you change permalink settings). If you want maximum security and don’t need WordPress to auto-update it, set it to 444 (read-only for everyone). Just know that with 444, you’ll need to manually update .htaccess any time permalink settings change.

wp-content/uploads: Special Considerations

The uploads directory is where things get interesting. WordPress needs to be able to write to this directory to save uploaded media — so it needs write access. The standard recommendation is 755 for the directory. However, this is also the most commonly targeted directory in file upload attacks. The advanced solution (covered in the hardening section) is to keep 755 for directory access but add an .htaccess rule that prevents PHP files from executing inside it, so even if an attacker uploads a malicious PHP file, it can’t run.

How to Check Your Current WordPress File Permissions

Before you can fix anything, you need to see what you’re working with. Here are the three main ways to check your current wordpress file permissions.

Using an FTP Client (FileZilla)

Connect to your server using FileZilla (free and widely used). Navigate to your WordPress root directory. In the right-hand pane showing your server’s files, right-click any file or folder and select File Permissions. FileZilla will display the current numeric permission value and show a checkbox breakdown of read/write/execute for owner/group/others. This is the most visual method for beginners checking wordpress file permissions.

Using cPanel File Manager

If your host provides cPanel, log in and open the File Manager. Navigate to your WordPress installation (usually inside public_html). Click any file or directory — the permissions column on the right shows the current setting. You can also select multiple files and click Change Permissions in the toolbar to bulk-update them.

Using SSH and the Command Line

SSH is the fastest and most powerful method for checking wordpress file permissions. Connect to your server and run:

ls -la /path/to/your/wordpress/

This lists all files including hidden ones (like .htaccess) with their permissions in symbolic notation (e.g., -rw-r–r– for 644) AND their ownership. To find files that don’t match expected permissions across your entire install, you can run targeted searches like:

# Find directories not set to 755
find /path/to/wordpress -type d ! -perm 755

# Find files not set to 644
find /path/to/wordpress -type f ! -perm 644

How to Set WordPress File Permissions (Step by Step)

Now that you know what’s wrong, here’s how to fix it. Multiple methods exist — use the one that matches your hosting environment and comfort level.

Method 1: Change Permissions via FTP

In FileZilla, right-click the WordPress root directory and choose File Permissions. Enter 755 in the numeric field, check Recurse into subdirectories, and select Apply to directories only. Click OK. Then repeat the process — this time enter 644 and select Apply to files only. This two-pass approach correctly sets wordpress file permissions to the right values for each type. Then manually navigate to wp-config.php and set it separately to 600.

Method 2: Change Permissions via cPanel

In cPanel’s File Manager, you can select individual files or folders and click Permissions. For bulk operations, select your WordPress root folder, choose Change Permissions, set the value, and apply recursively. The limitation of cPanel is that bulk recursive operations don’t easily distinguish between files and directories — you may need to do this in stages or use SSH for precision.

Method 3: Change Permissions via SSH (chmod)

SSH is the gold standard for managing wordpress file permissions at scale. The GNU chmod utility gives you surgical precision. Connect via SSH and run these two commands from your WordPress root directory:

# Set all directories to 755
find /path/to/wordpress -type d -exec chmod 755 {} \;

# Set all files to 644
find /path/to/wordpress -type f -exec chmod 644 {} \;

# Lock down wp-config.php separately
chmod 600 /path/to/wordpress/wp-config.php

These three commands will correctly configure wordpress file permissions across your entire installation in seconds. Replace /path/to/wordpress with your actual WordPress root path (often something like /home/username/public_html).

Method 4: Using a WordPress Security Plugin

Security plugins like Wordfence and All In One WP Security & Firewall include file permission scanners that check your current wordpress file permissions against recommended values and flag problems. Some can apply fixes directly from the WordPress dashboard. This is the most beginner-friendly method, though SSH gives you more control and is faster on large installations.

What Happens When WordPress File Permissions Are Wrong

Too Permissive: The 777 Disaster

Setting any WordPress file or directory to 777 is the single most dangerous wordpress file permissions mistake you can make. With 777, literally every user and process on the server — including other customers on shared hosting — can read, write to, and execute those files. On shared hosting, that means a compromised site belonging to another customer could be used as a vector to inject malicious code into your files.

The data is damning: 777 permissions are exploited in the vast majority of file upload attacks on WordPress. Attackers specifically scan for world-writable directories because they’re easy to exploit. And they don’t wait around — among heavily exploited WordPress vulnerabilities, 20% were exploited within 6 hours of disclosure, 45% within 24 hours, with a weighted median time to first exploitation of just 5 hours, according to the Patchstack State of WordPress Security 2026 report.

Too Restrictive: When WordPress Cannot Function

Over-restrictive wordpress file permissions break your site in different ways. If wp-content is set to 555 (read/execute only), WordPress can’t save uploaded media. If wp-config.php is set to 000, even the web server can’t read your database credentials and your site goes white. Plugin and theme updates fail when WordPress lacks write access to the relevant directories. These issues are frustrating and often lead site owners to overcorrect by setting 777 — which takes them from one disaster straight into another.

Real-World Attack Scenarios From Misconfigured Permissions

Here’s what a real attack against misconfigured wordpress file permissions actually looks like:

Scenario 1 — The Uploads Backdoor: An attacker finds a plugin with an arbitrary file upload vulnerability (43% of WordPress vulnerabilities are exploitable without authentication). They upload a PHP webshell to wp-content/uploads. If the uploads directory has 777 permissions and no PHP execution restrictions, the attacker navigates directly to the uploaded file URL and has a fully functional backdoor. From there, they can read your wp-config.php, exfiltrate your database, create admin accounts, and install persistent malware. The entire chain requires only one misconfigured directory.

Scenario 2 — The Core File Injection: On a shared host where another account is compromised, world-writable wordpress file permissions on your theme files allow cross-account injection. The attacker’s script writes obfuscated PHP to your functions.php, creating a persistent backdoor that survives plugin updates and even manual malware scans that don’t check file content.

Advanced Permission Hardening for WordPress

Correct wordpress file permissions (644/755/600) are the baseline. If you want to truly secure your WordPress site, there’s a tier above the basics. The OWASP Top 10 2025 specifically calls out missing security hardening across the application stack as the primary driver of Security Misconfiguration — now the #2 most critical web risk. Here’s how to go further.

Disabling PHP Execution in wp-content/uploads

Even with correct directory permissions, the uploads folder allows PHP execution by default. Add the following .htaccess rule inside wp-content/uploads/ to neutralize file upload attacks even when they succeed in placing a file:

# Disable PHP execution in uploads directory
<FilesMatch "\.ph(p[3-8]?|t|tml)$">
    deny from all
</FilesMatch>

This is one of the highest-impact single security changes you can make. Even if an attacker exploits a file upload vulnerability and places a PHP webshell in your uploads directory, this rule prevents it from executing. The file lands but can’t run. Mission failed for the attacker.

Locking Down wp-includes and wp-admin

Add these rules to your root .htaccess file to block direct PHP execution in wp-includes (users should never be directly accessing PHP files there) and add IP-based restrictions to wp-admin if you access it from consistent IP addresses:

# Block direct PHP execution in wp-includes
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

The Principle of Least Privilege Applied to WordPress

The Wordfence Security Team puts it clearly: “One of the most effective ways to limit potential damage from compromised accounts is implementing the principle of least privilege — giving users only the permissions they need to perform their tasks.” In the context of wordpress file permissions, this means:

• Your WordPress files should not be writable by the web server process during normal operation — only when WordPress needs to update itself.
• The wp-config.php file should be owned by your account user, not the web server user.
• Contributors and Editors in WordPress don’t need filesystem-level write access anywhere — manage their access through WordPress user roles, not by opening up file permissions.
• Consider adding two factor authentication to your WordPress admin — file permission hardening pairs with authentication hardening for layered security.

Shared Hosting vs VPS Permission Strategies

The right wordpress file permissions strategy depends on your hosting environment:

Shared Hosting: You have the least control but are also at the mercy of your neighbors on the same server. Stick strictly to 644/755 — never use 777 on shared hosting because the “others” category includes every other account on that physical server. Most shared hosts run PHP as your user account via suPHP or PHP-FPM, which means the web server effectively IS the file owner, and 644/755 works perfectly.

VPS/Dedicated Server: You have full control. If you’re running Nginx + PHP-FPM with separate user pools, files can often be owned by your deploy user with the PHP-FPM pool running as a different user — requiring you to set group permissions carefully. The NIST SP 800-209 Security Guidelines for Storage Infrastructure provides federal-grade guidance on file system security controls worth reading if you’re managing your own server.

Managed WordPress Hosting: Hosts like Kinsta, WP Engine, and Flywheel typically manage wordpress file permissions for you within their containerized environments. They often use more aggressive hardening by default (disabling file editing in the dashboard, enforcing read-only core files, etc.). The tradeoff is less manual control — but if you’re not a sysadmin, this is often the safest bet.

Troubleshooting WordPress File Permission Errors

Wrong wordpress file permissions produce specific, recognizable error messages. Here’s how to diagnose and fix each one. When in doubt, knowing how to update WordPress safely before and after permission changes is good practice.

403 Forbidden Error

A 403 Forbidden error means the server understood your request but refuses to fulfill it — almost always a permissions issue. Check that your .htaccess file exists and is set to 644. Verify that your WordPress directories are set to 755, not 700 or 500. If the error only happens on specific pages, a corrupted .htaccess is often the culprit — replace it with the default WordPress .htaccess content and set the permissions correctly. SSH fix:

find /path/to/wordpress -type d -exec chmod 755 {} \;
chmod 644 /path/to/wordpress/.htaccess

“Could Not Create Directory” Error

This error appears when WordPress tries to create a directory (during plugin installation, media upload, or updates) but lacks write permission. The web server process needs write access to the target directory. Check wp-content permissions (should be 755) and verify ownership. If the web server runs as www-data but files are owned by your account user, you may need to add www-data to your user’s group, or configure PHP-FPM to run as your account user. This is the ownership problem discussed earlier — permissions alone won’t fix it.

Plugin or Theme Update Failures

When plugin or theme updates fail with permission errors, WordPress typically cannot write to wp-content/plugins or wp-content/themes. Verify those directories are 755. If you’ve been editing a WordPress child theme via FTP as a different user than the web server runs as, ownership mismatch is the likely cause. You may also see WordPress prompt for FTP credentials — this happens when WordPress detects it can’t write files directly and falls back to FTP-based updates. Fix the ownership issue and direct filesystem access is restored.

White Screen of Death From Permission Issues

A blank white screen (or White Screen of Death) related to wordpress file permissions usually means PHP can’t read a critical file. Check wp-config.php — if it’s set too restrictively (like 000), the web server can’t read it. Check that your wp-includes directory and its PHP files are at least readable (644 for files, 755 for directories). Enable WordPress debug logging by temporarily adding define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); to wp-config.php to see the actual error before the screen goes white.

Frequently Asked Questions About WordPress File Permissions

Keep Your WordPress Site Locked Down

Getting your wordpress file permissions right is one pillar of a complete WordPress security posture — but it’s not the only one. File permissions stop attackers from exploiting the filesystem. Authentication security stops them from logging in. Update discipline stops them from exploiting known vulnerabilities before you patch them. Every layer matters.

The OWASP Top 10 2025 makes it clear that misconfiguration — including incorrect wordpress file permissions — is now the second-most exploited vulnerability category across all web applications. The Patchstack State of WordPress Security 2026 report shows highly exploitable vulnerabilities in WordPress increased by 113% year-on-year. This threat landscape is accelerating. Baseline hardening like correct wordpress file permissions is the minimum ante to play in this game securely.

Here’s your action plan right now: SSH into your server, run the find/chmod commands to set all your wordpress file permissions to 644 (files) and 755 (directories), lock down wp-config.php to 600, add the PHP execution block to your uploads .htaccess, and then go set up two factor authentication on your admin account. Then come back and explore the Arsenal for every tool you need to maintain those defenses going forward. You’ve got the knowledge — now execute.