What this problem looks like
The web server must read WordPress files and write only to wp-content/uploads, cache folders, and upgrade directories. Permissions that are too open let attackers modify PHP. Permissions that are too tight break updates and media uploads.
Never chmod 777 on production. Fix ownership so the PHP user owns wp-content while keeping 755/644 on files.
Step 1: Standard WordPress permission targets
Directories: 755. Files: 644. wp-config.php: 440 or 600 depending on host. wp-content/uploads must be writable by the web server for media uploads.
755onwp-admin,wp-includes,wp-contentdirectories.644on PHP, CSS, and JS files.600or440onwp-config.phpwhen supported.
Step 2: Fix permissions via SSH
On shared hosting, use File Manager in cPanel, Plesk, or Site Tools. Select wp-content, wp-admin, and wp-includes, then change permissions recursively.
Only run the commands below if you have SSH access to the server. They will not work inside File Manager. Run them from the WordPress root.
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php Step 3: Fix uploads and upgrade folders
If media upload fails, confirm wp-content/uploads is 755 and owned by the web server user. Plugin updates need write access to wp-content/upgrade temporarily.
Step 4: Resolve ownership issues
On VPS servers, set ownership to the PHP user, often www-data or nginx. Only run this command if you have SSH access:
chown -R www-data:www-data /path/to/wordpress Step 5: Verify updates and uploads work
Upload a test image in Media Library. Run a minor plugin update on staging. If either fails, check host error logs rather than opening permissions to 777.
When to stop DIY and hire help
Permission problems after a hack often hide backdoors in writable directories. BugShield audits file permissions and removes unauthorised PHP at a confirmed fixed price.