Permission problems are rarely just permission problems; ownership and unexpected files are usually the real story. Drop in your own hosting scan output and this walks the same evidence-first sequence.
Security
Audit file permissions after a suspected compromise
Hosting support flagging a world-writable wp-config.php, 777 upload folders, and one suspicious PHP file with executable permissions, worked through to tell misconfiguration from an active backdoor and fix it without breaking the site.
Works with Claude / GPT112 uses★ 3.8
The prompt
security-file-permissions-audit-after-compromise
Hosting support's permission scan flagged: [- wp-config.php: 666 - /wp-content/uploads/ and 3 subdirectories: 777 - /wp-content/uploads/2026/05/x.php: 755, present in the file list, not a file the site owner recognizes or recalls uploading - .htaccess: modified 2 days ago, no one on the team recalls changing it - File owner on most files is the correct SFTP user, but x.php is owned by the web server user instead] Audit and fix this the way a responder would, not a blanket chmod-everything pass: 1. State the correct baseline permissions for each item (typically 644 for wp-config.php and most files, 755 for directories, never 777 in normal operation) and explain why 777 on uploads and 666 on wp-config aren't just sloppy, they're actively dangerous: world-writable means any process on shared hosting, or any script that gets onto the server, can modify them. 2. Treat the ownership mismatch on x.php as the most important clue here: a file owned by the web server user rather than the SFTP user strongly suggests it was written by a script running through the website itself (an upload handler or an already-planted backdoor), not uploaded by someone on the team. Explain what that implies about how it got there. 3. Before touching permissions, preserve x.php and the recently modified .htaccess for review, quarantine rather than delete outright, since deleting first destroys the evidence needed to root-cause the entry point. 4. Sequence the fix: correct file and directory permissions site-wide back to the safe baseline, add a rule blocking PHP execution inside the uploads directory specifically (uploads should never need to execute code), then review .htaccess and x.php's contents to confirm what they actually do before deciding whether the fix is complete. 5. Recommend an ongoing check, such as periodic permission and file-integrity scans, that would catch this drifting back to unsafe values or a new backdoor appearing before it's found by accident.