Quick answer
After a WordPress hack, review file permissions to reduce unauthorized writes while keeping legitimate updates and uploads working. Look for world-writable files, executable scripts in uploads, writable configuration files, suspicious ownership, and folders that malware modified. Fix permissions carefully and test the site afterward.
File permissions control who can read, write, and execute files on the server. After malware cleanup, permissions can reveal how attackers wrote files and how to reduce reinfection risk.
Permissions are not the only security control, but overly loose permissions make many attacks easier.
Why this matters
If sensitive files are writable by too many users, malware can modify configuration, templates, or plugin files more easily.
If permissions are too strict, legitimate uploads, updates, and cache generation may fail. The goal is balance, not maximum restriction everywhere.
Warning signs to look for
- Files or folders are world-writable.
- PHP scripts appear in uploads.
- wp-config.php is writable unexpectedly.
- Ownership differs between files.
- Updates fail after cleanup changes.
Permissions depend on hosting setup, so use host guidance when available.
Where this usually hides
Permission problems often appear in uploads, cache folders, wp-config.php, plugin folders, theme folders, and backup directories.
Attackers may also change permissions to keep a backdoor writable or executable.
Safe investigation steps
List permissions and ownership for important directories. Compare suspicious files with nearby legitimate files.
Check whether the web server user can write to places it should not need to write.
- Review wp-config.php permissions.
- Inspect uploads for executable scripts.
- Check plugin and theme directory permissions.
- Review ownership consistency.
- Test updates and uploads after changes.
Cleanup priorities
Fix obviously unsafe permissions and remove malicious executable files. Block PHP execution in uploads where compatible.
Coordinate with hosting if ownership is wrong. Incorrect ownership can break updates or require server-level repair.
- Back up before changing permissions.
- Correct unsafe writable files.
- Remove malicious scripts.
- Test uploads and updates.
- Monitor for permission changes.
What to avoid
Do not apply random chmod commands from forums without understanding your hosting environment.
Do not make everything read-only if the site needs updates, uploads, or cache writes.
Prevention after cleanup
Use secure hosting defaults, limit file manager access, and monitor critical file changes.
Regular maintenance should include permission review after migrations, restores, or cleanup.
Helpful resources
Related services include WordPress security hardening, security audit, and hidden backdoor removal.
WordPress.org’s hardening guide includes file permission concepts and broader hardening advice.
When to get expert help
Get help if permissions are inconsistent, uploads are broken, or malware keeps writing files after cleanup.
How to confirm the cleanup worked
For WordPress file permissions after hack, verification should match the original symptom. A single admin-side check is not enough. Test the affected URL as a logged-out visitor, from a private browser window, and from the device type involved in the report. If the issue affected search traffic, inspect the exact search-facing URL and compare the rendered source with the dashboard content.
Clear WordPress cache, server cache, CDN cache, and browser cache before making the final call. Old cached output can make a clean site look infected, while logged-in testing can make an infected site look clean. Verification should include files, database, users, redirects, and the public page output.
What evidence to save
Keep a short incident note for this case. Include the first report date, affected URLs, screenshots, warning messages, suspicious files, changed users, plugins involved, and the cleanup actions taken. That record helps if the issue returns or if hosting, Google, an ad platform, or a client asks what was fixed.
Evidence is also useful for learning the entry point. If you know which file changed first, which admin account was used, or which plugin path appeared in logs, future prevention becomes much more targeted than simply installing another security plugin.
SEO and trust impact
Security incidents affect more than code. Visitors who see warnings, redirects, broken pages, or suspicious prompts may lose trust quickly. Search engines and ad platforms may also need time to recrawl and re-evaluate the site after cleanup.
After the technical fix, check important landing pages, internal links, metadata, forms, and conversion paths. A page can be technically clean but still lose value if the user experience remains broken or if search snippets still show old compromised text.
Questions before closing the ticket
- What was the most likely entry point?
- Was any admin, hosting, SFTP, database, or API credential exposed?
- Were files, database records, users, redirects, and cache all reviewed?
- Was the vulnerable plugin, theme, setting, or password fixed?
- Is monitoring active so recurrence is caught quickly?
If any answer is unknown, mark the incident as cleaned and monitoring rather than fully closed. That small caution can prevent the same issue from returning unnoticed.
How to confirm the cleanup worked
For WordPress file permissions after hack, verification should match the original symptom. A single admin-side check is not enough. Test the affected URL as a logged-out visitor, from a private browser window, and from the device type involved in the report. If the issue affected search traffic, inspect the exact search-facing URL and compare the rendered source with the dashboard content.
Clear WordPress cache, server cache, CDN cache, and browser cache before making the final call. Old cached output can make a clean site look infected, while logged-in testing can make an infected site look clean. Verification should include files, database, users, redirects, and the public page output.
What evidence to save
Keep a short incident note for this case. Include the first report date, affected URLs, screenshots, warning messages, suspicious files, changed users, plugins involved, and the cleanup actions taken. That record helps if the issue returns or if hosting, Google, an ad platform, or a client asks what was fixed.
Evidence is also useful for learning the entry point. If you know which file changed first, which admin account was used, or which plugin path appeared in logs, future prevention becomes much more targeted than simply installing another security plugin.
SEO and trust impact
Security incidents affect more than code. Visitors who see warnings, redirects, broken pages, or suspicious prompts may lose trust quickly. Search engines and ad platforms may also need time to recrawl and re-evaluate the site after cleanup.
After the technical fix, check important landing pages, internal links, metadata, forms, and conversion paths. A page can be technically clean but still lose value if the user experience remains broken or if search snippets still show old compromised text.
Questions before closing the ticket
- What was the most likely entry point?
- Was any admin, hosting, SFTP, database, or API credential exposed?
- Were files, database records, users, redirects, and cache all reviewed?
- Was the vulnerable plugin, theme, setting, or password fixed?
- Is monitoring active so recurrence is caught quickly?
If any answer is unknown, mark the incident as cleaned and monitoring rather than fully closed. That small caution can prevent the same issue from returning unnoticed.
FAQ
What permissions should WordPress files use?
It depends on hosting, but files and directories should not be more writable than needed.
Can wrong permissions cause malware?
They can make exploitation easier, though they are usually one part of a larger issue.
Should uploads execute PHP?
Usually no. Blocking PHP execution in uploads is often a good hardening step.
Can changing permissions break updates?
Yes. Test after changes and follow host-specific guidance.