Permissions are a containment control
WordPress vulnerabilities are not limited to an attacker changing a setting. A compromised plugin, administrator session, upload handler, or PHP process may attempt to write a backdoor into a theme, replace a plugin, alter the configuration, or modify core files. If the runtime owns the application tree, that persistence is easy.
Read-only application code does not prevent every compromise. It narrows what the compromised process can change and makes unexpected write attempts more visible.
Separate the deployer from the runtime
A privileged deployment or update process should own code changes. The web server should serve the result. This separation mirrors other production systems: the process handling public requests does not also need permission to rewrite its executable code.
Use a dedicated operating procedure for updates: back up, unlock or run as a privileged owner, apply official updates, verify checksums and behaviour, then restore secure ownership. Do not leave the tree writable because updates happen occasionally.
Know the common baseline and its limits
A common baseline is 755 for application directories and 644 for application files, owned by a privileged account rather than the web-service account. The configuration file can be tighter when the web-service group only needs read access. Exact ownership matters as much as the numeric mode.
Avoid 777. It grants every local account write access and usually signals that the real ownership problem was bypassed. Group-writable 775/664 is also inappropriate when the PHP service belongs to that group and no request-time write is required.
Identify legitimate runtime writes
Uploads normally require write access so WordPress can store and transform media. A deliberately configured cache or temporary upgrade directory may also require it. Give each location the narrowest ownership and mode compatible with operation.
Writable uploads must not become executable application code. Deny PHP-like extensions at the web-server layer and validate upload types in the application. Store private or sensitive files outside the public document root when possible.
Do not break updates silently
If files become read-only but background updates remain presented as active, the organization gains false confidence. Explicitly disable runtime file modification and document the controlled update command, owner, backup, verification, and expected cadence.
Monitor upstream releases for components that do not use the WordPress.org update channel. A secure permission model and an abandoned plugin are not a safe combination.
Verify the effective result
Inspect ownership and modes recursively, confirm no unexpected world-writable files remain, and test media upload only if the site actually uses it. Verify that WordPress can read the configuration, that public pages and the editor work, and that a direct request cannot expose sensitive files.
Run official core checksum verification. Record the pre-change permissions so rollback is exact. Then connect the control to the broader WordPress VPS defence-in-depth checklist.
