How to Check WordPress File Permissions After a Hack
If your site has been compromised, file permissions are one of the first places to investigate.
Knowing how to check WordPress file permissions after a hack helps you spot malicious changes, stop reinfection, and restore safe access control.
Attackers often alter permissions to make backdoors writable, hide malware, or keep themselves persistent.
A quick audit of files, folders, ownership, and server behavior can reveal problems that are easy to miss in a visual website scan.
What file permissions control in WordPress
WordPress runs on a Unix-like filesystem where permissions determine who can read, write, and execute files.
These settings apply to the web server user, your hosting account, and other system users on the same server.
- Read: allows viewing a file or listing a directory.
- Write: allows editing, replacing, or creating files.
- Execute: allows running a file or entering a directory.
In a healthy WordPress install, the web server should not need broad write access to every file.
If permissions are too open, a single exploited plugin or vulnerable upload endpoint can modify core files, themes, or configuration files.
Common permission patterns to review
Before checking for tampering, confirm the expected baseline.
While hosting environments differ, these patterns are common on shared hosting, VPS, and managed WordPress servers.
- Directories: often set to 755.
- Files: often set to 644.
- wp-config.php: often restricted to 600 or 640 depending on ownership and hosting setup.
- Executable scripts: only when needed, such as specific CLI tools or legitimate server-side scripts.
Permissions that are too permissive, such as 777, are a red flag.
They allow almost anyone on the system to write to a file or directory and are frequently abused after a compromise.
How to check WordPress file permissions after a hack using SSH
If you have SSH access, use it first.
Command-line checks are faster, more accurate, and easier to repeat during cleanup.
List permissions recursively
Run a directory listing from the WordPress root:
find . -type d -exec stat -c "%a %n" {} \;
find . -type f -exec stat -c "%a %n" {} \;
These commands help you see which folders and files are outside the normal baseline.
Look for unexpected 777, 775 on public files, or writable PHP files inside wp-admin, wp-includes, or plugin directories.
Check for recently modified files
After a hack, changed timestamps matter as much as permissions.
Compare current files against a clean backup or install package.
find . -type f -mtime -7
This shows files modified in the last seven days.
Narrow the window if you know when the breach occurred.
Pay close attention to PHP files in uploads, cache directories, and custom plugin folders.
Inspect ownership
Permissions alone do not tell the full story.
Ownership determines who can change a file without special privileges.
ls -la
If files are owned by an unexpected user, or if the web server user owns large sections of the site that should belong to your account, investigate immediately.
Incorrect ownership often indicates either a bad deployment process or a compromise that used server-side write access.
How to check WordPress file permissions after a hack in hosting control panels
If SSH is unavailable, cPanel, Plesk, and similar dashboards can still help.
Use the File Manager to inspect the WordPress root, wp-content, plugin folders, and the uploads directory.
- Open the file manager and sort by permissions.
- Review wp-config.php, .htaccess, index.php, and active theme files.
- Check for PHP files inside wp-content/uploads, which is often a malicious indicator.
- Look for new .php, .phtml, or .php8 files in image directories.
Control panels are less efficient than SSH, but they are useful when you need quick verification on a shared host or when you are locked out of terminal access.
Red flags that suggest malicious permission changes
Attackers rarely announce themselves directly.
Instead, they change security settings to make future actions easier.
- 777 permissions on directories or files.
- Writable PHP files in theme or plugin directories.
- Executable files in wp-content/uploads.
- Unexpected .htaccess changes that redirect traffic or hide backdoors.
- New cron jobs or scheduled tasks that recreate malware.
- Modified wp-config.php with injected code or extra database credentials.
If you find a suspicious file that is both writable and recently modified, treat it as a likely compromise until proven otherwise.
How to restore safe WordPress permissions
After you identify dangerous settings, reset them carefully.
Avoid blanket changes that could break your site or accidentally preserve malicious ownership.
- Set directories back to 755.
- Set files back to 644.
- Restrict wp-config.php more tightly if your host supports it.
- Remove write access from PHP files unless absolutely necessary.
- Delete unknown PHP files from uploads after verifying they are not part of a legitimate workflow.
If you are using WP-CLI or SSH, you can often automate a safer reset, but only after you have backed up evidence and confirmed the site’s current state.
Always keep a copy of suspicious files for forensic review before deleting them.
Also verify security beyond permissions
File permissions are only one layer.
A hack can persist even when permissions look normal if the attacker planted backdoors elsewhere.
- Scan active plugins and themes for injected code.
- Check database tables for malicious admin users or spam redirects.
- Review .htaccess, php.ini, and user.ini for hidden directives.
- Rotate WordPress salts and all passwords.
- Update WordPress core, plugins, and themes from trusted sources.
In many incidents, the root cause is a vulnerable plugin, reused password, or outdated theme.
Fixing permissions without removing the initial access path often leads to reinfection.
Best practices for prevention after cleanup
Once the site is stable, make future checks easier by hardening your setup.
Good operational hygiene reduces the chance that a compromised account can modify critical files.
- Limit FTP and SFTP access to trusted users only.
- Use unique, strong passwords and enable multi-factor authentication where possible.
- Keep regular backups that include both files and the database.
- Monitor file integrity with tools such as Wordfence, Sucuri, or hosting-level malware scanners.
- Log permission changes and alert on unexpected file creation in wp-content.
A periodic audit is especially useful after plugin installs, theme updates, or account changes.
The sooner you spot an abnormal permission shift, the smaller the incident becomes.
What to prioritize during a post-hack permission review
When time is limited, focus on the areas most likely to be abused.
These are the files and directories that usually reveal the fastest signal.
- wp-config.php
- .htaccess and other server config files
- wp-content/uploads
- Active theme files
- Recently installed plugins
- Cache and backup directories inside the web root
If you can verify these locations, compare them against a clean copy, and normalize their permissions and ownership, you will catch most permission-related persistence techniques used after a WordPress hack.