WordPress File Permission Checker & Chmod Tool
Validate WordPress directory and file permissions (755 vs 644 vs 600), identify dangerous 777 configurations, and generate Linux terminal hardening commands.
Octal Permission Risk Evaluator
Standard hardened WordPress permission. Only the file owner has write access, protecting the integrity of your code.
WordPress Hardened Permission Standards Matrix
/ (root), /wp-admin/, /wp-includes/, /wp-content/
Owner has read/write/execute. Web server & visitors can read/execute without write access.
index.php, wp-login.php, wp-settings.php, *.php
Owner has read/write. Group and other have read-only access. Prevents unauthorized file overwrites.
wp-config.php
Contains plaintext database passwords and security keys. Must be strictly readable only by the owner.
.htaccess
Controls URL rewriting and security headers. Should be read-only (444) to prevent malicious injection.
/wp-content/uploads/
Must be writable by WordPress for media uploads, but PHP script execution must be blocked via .htaccess/Nginx.
Linux Terminal Remediation Script Generator
# 1. Set standard ownership to web server user
sudo chown -R www-data:www-data /var/www/html
# 2. Set 755 permissions for all directories
sudo find /var/www/html -type d -exec chmod 755 {} \;
# 3. Set 644 permissions for all standard files
sudo find /var/www/html -type f -exec chmod 644 {} \;
# 4. Lock down wp-config.php (owner read/write only)
sudo chmod 600 /var/www/html/wp-config.php
# 5. Lock down .htaccess (if on Apache/LiteSpeed)
if [ -f "/var/www/html/.htaccess" ]; then
sudo chmod 644 /var/www/html/.htaccess
fi
# 6. Verify no 777 permissions exist
echo "Searching for dangerous 777 permissions..."
find /var/www/html -perm 0777Technical Deep-Dive: Linux File Permissions for WordPress
📌 On this page
1. How Linux permissions actually work
Every file and directory on a Linux server carries three permission sets — owner, group, and other (everyone else) — each independently controlling read, write, and execute access. For a directory, "execute" specifically controls whether a process can enter (cd into) it and list/access files inside, which is why directories conventionally get 755 (execute enabled) while regular files get 644 (execute disabled, since PHP files are interpreted by the PHP process, not executed directly as binaries).
2. Why 777 is catastrophic on a shared host
On shared hosting, "other" often includes every other customer account on the same physical server — not just the general public. A 777 permission on a WordPress directory means any of those other accounts (and, if the web server process itself is compromised through any vector, effectively anyone) can write, replace, or delete files in it. This is precisely how one compromised low-security WordPress install on shared hosting can sometimes lead to cross-contamination of neighboring sites when permissions are misconfigured this loosely.
3. wp-config.php: the single most sensitive file
wp-config.php contains your database credentials in plaintext, along with the secret authentication keys and salts WordPress uses to sign session cookies — anyone who can read this file gains a direct path to your database and can potentially forge valid login sessions. Locking it to 600 (owner read/write only) or even 400 (owner read-only) ensures that even if another process or account on the same server can browse the filesystem, this specific file remains inaccessible to anyone but the legitimate owner process.
4. Ownership vs permissions: two different problems
Permissions (chmod) define what owner/group/other can do; ownership (chown) defines who counts as "owner" and "group" in the first place — and misconfigured ownership is just as common a source of WordPress problems as misconfigured permissions. If files are owned by root but the web server process runs as www-data (or nginx, or apache), WordPress cannot self-update, install plugins, or save uploads even with otherwise-correct 755/644 permissions, because the web server process is evaluated against the "other" permission bucket, not "owner." The chown command in the generated script above addresses exactly this mismatch.
5. Why the uploads directory needs special treatment
/wp-content/uploads/ is unusual because it genuinely needs to be writable by the web server process (to accept new media uploads) — unlike most of the WordPress codebase, which should ideally stay read-only from the web server's perspective outside of update/install operations. This writability creates risk: if an attacker can smuggle a PHP file into an upload-accepting directory, standard 755 permissions alone won't stop it from executing. The critical additional control is disabling PHP execution specifically inside that directory via a dedicated .htaccess rule or Nginx location block, independent of the file permission settings.
6. Checking and fixing permissions safely
Before running any bulk chmod/chown command, check current permissions first with `ls -la` (for a directory listing) or `stat filename` (for a single file) via SSH, and always take a backup or at minimum note the current state before making sweeping changes to a live production site. Run bulk permission fixes during low-traffic windows when possible, and verify the site still loads correctly and that plugin/theme updates still work immediately afterward — an overly restrictive fix can just as easily break WordPress as an overly permissive one leaves it exposed.
Frequently Asked Questions
Why should you never use chmod 777 on WordPress?
Setting 777 ("rwxrwxrwx") grants full read, write, and execute permissions to everyone on the server, including unauthenticated web visitors and shared hosting neighbor accounts. Any attacker who finds a file upload exploit can execute arbitrary malicious PHP code.
What are the correct permissions for WordPress files and directories?
The WordPress official security standard recommends 755 (drwxr-xr-x) for all directories and 644 (-rw-r--r--) for all files. Sensitive files like wp-config.php should be locked down further to 600 or 400.
Why does WordPress fail to update plugins or upload images when permissions are too strict?
If directories are set to 555 or owned by a user other than the web server process (e.g. root instead of www-data or nginx), WordPress cannot write new plugin files or save uploads, displaying "Unable to create directory" errors.
How can I prevent PHP execution in the /wp-content/uploads/ directory?
Add a .htaccess file inside /wp-content/uploads/ containing: <Files *.php>deny from all</Files>. On Nginx, add a location block matching uploads/*.php returning 403 Forbidden.
Does this tool scan my live server for actual permission misconfigurations?
No — this is a reference and educational tool, not a live server scanner. It evaluates whatever octal value you manually type in (checking it against known-safe and known-dangerous patterns) and generates a ready-to-run shell script based on the web server user and path you specify; it does not connect to your server or inspect real file permissions. Run the generated script (or an SSH `stat` / `ls -la` command) directly on your own server to see your actual current permissions.
What do the three digits in a chmod octal value (like 755) actually mean?
Each digit represents permissions for a different group, in order: owner, group, and other (everyone else), each ranging 0-7 where the value is a sum of read (4), write (2), and execute (1). So 755 means the owner gets 7 (4+2+1 = read+write+execute), while group and other each get 5 (4+1 = read+execute, no write) — exactly the pattern that lets the file owner modify content while everyone else can only read/execute it, never write.