DISALLOW_FILE_EDIT也挡不住？WordPress被篡改急救指南

opens disallow_file_edit If "Theme/plugin files have been changed, code inserted" still appears, then it may not be that the switch is not working, but that theTampering occurs "outside the editor.": Server file permissions, panel/FTP, account theft, plug-in vulnerability implanted backdoor, etc. can directly change the file.

1) Let's get the concept out of the way first: what can DISALLOW_FILE_EDIT only block?

disallow_file_edit will only disable the WordPress backstageAppearance/plugin file editor(Theme/Plugin Editor).
itwill not (act, happen etc)Stop the following behaviors:

pass (a bill or inspection etc) FTP/SFTP/SSH/Panel File ManagerDirect file change
The malicious code is executed on the server as PHP process permissionsWrite/overwrite files
Uploading webshell, writing wp-content/uploads,mu-plugins et al. (and other authors)
Changing files through the "update/install" mechanism (this requires another switch.)DISALLOW_FILE_MODS)

So "still tampered with" basically points to that:Your site or server still has writable entriesThe

(2) The 9 most common types of causes

2.1 Excessive file system permissions / owner errors (most common)

wp-content/, theme directories, and plug-in directories are not available to users running the Web (e.g., the www-data) is writable, malicious PHP can change the file once it's landed
Typical performance: repeated insertion of the same paragraph eval/base64/gzinflateYou deleted it and then came back a few hours later.

2.2 WordPress Administrator Account or Cookie Stolen

Accounts are bumped, weak passwords, reused passwords, no 2FA
Cookie theft by browser extensions with "fake plugins/injection scripts".

2.3 FTP/SFTP/Panel Account Leakage

Pagoda/1Panel/cPanel Login Leakage or Weak Passwords
FTP plaintext transfers intercepted (especially old FTP)

2.4 High-risk plugin/theme vulnerabilities exist (upload, deserialization, RCE, arbitrary file write)

Representation:uploads occurring in .php,phtml, strangely named images (actually PHP)
Or "you never installed" files in the plugin directory.

2.5 Persistent backdoors: mu-plugins / drop-in / automated tasks

Focused Look:

wp-content/mu-plugins/
wp-content/plugins/ It is disguised as a system plug-in.
wp-content/advanced-cache.php,object-cache.php drop-in
wp-cron Timed write-back and restore of malicious code

2.6 Database injection: scripts hidden in options tables/widgets/article content

wp_options(AUTOLOAD) Stuffed with malicious JS.
Widget/page builder module plugged in <script>(Looks like "file not changed but page hijacked.")

2.7 Server tier has been taken down (lateral infection of other sites/shared hosts on the same machine)

Multiple stations on the same host, as long as one station is compromised, it may affect other stations through permissions configuration issues

2.8 Cache/CDN misjudged as "still tampered"

You fixed the source site files, but the CDN/cache is still spitting out old content
(It is recommended to check "whether the hash of the source file has changed again" first to avoid misjudgment)

2.9 Development/deployment links leading to "automatic overrides"

Git/CI, Sync Scripts, Backup Restore Tasks to overwrite old files (including malicious ones) back in

3) How to quickly identify: who is actually changing? What was changed?

Doing them in sequence separates miscarriages of justice from "recurrent infections":

3.1 Confirm whether you really changed the file or the cache first

Recording of tampered documentsModification time mtimetogether withhash (computing)
Check for changes after 30-60 minutes

If the hash changes: it's actually changing the file; if it doesn't change but the page is abnormal: it's probably caching/database injection/front-end hijacking

3.2 Perform an integrity check (locate "documents that should not have changed but did")

WordPress Core: verify that the core document has not been replaced
Plugins/themes: compare against the official package or re-download it

3.3 Check "recently added/recently modified" files (fastest way to catch backdoors)

Focused Catalog:

wp-content/uploads/
wp-content/mu-plugins/
wp-includes/,wp-admin/(Be on high alert for unfamiliar files in the core directory)
Whether the root directory is extra randomly named PHP

Linux Common Troubleshooting (Example)

# php files modified in the last 3 days (by number of days needed)
find . -type f -name "*.php" -mtime -3 -print

# uploads with php basically not working
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -print

# Quick search for common confusing features (not convictions, just catching clues)
grep -R --line-number -E "base64_decode|gzinflate|str_rot13|eval\(|assert\(" wp-content | head

4) High Success Rate Repair Process

4.1 Stop the bleeding immediately

Temporarily enable maintenance pages / restrict backend logins (whitelist IP or Basic Auth)
Immediately change: WP administrator password, database password, panel password, SFTP/SSH password, all API Keys
Force all administrators to re-login (password change + disabled cookie)

4.2 Clearing the back door

removing uploads All executable scripts in the uploads (principle: uploads should not be PHP)
Check and clean up mu-pluginsThe file, drop-in file (if you're not sure of the source, back it up first and then remove the verification)
surname Zha wp-cron: Whether there are tasks that are timed to write, remotely pull scripts

4.3 Trusted reloading

recover WordPress Core document（Don't move. wp-config.php respond in singing wp-content (media)
Plugins & Themes: reinstalled only from trusted sources.Don't keep the old zip/old directory

4.4 Modification of authority

Recommended baseline (generic idea):

Catalog:755
Documentation:644
wp-config.php: Tighter (e.g. 600/640(Look at your runtime users and groups)
Ensure that the user running the web does not have write access to the "whole site", at least not to the core directory.

4.5 Disabling uploads

Nginx/Apache Configuration Disable wp-content/uploads Executing PHP
This step cuts right through a lot of the "upload and execute" attack chain.

5) Reinforcement recommendations (making "tampering" difficult at the root)

opens DISALLOW_FILE_MODS(prevents backend installation/updating of files, reduces write surface): best suited only if you have a standardized deployment process (Git/CI)
Enable 2FA, limit login attempts, change default login path (better with WAF)
Turn off unwanted XML-RPC (or limitations)
Regular update: WP core/plugins/themes (the shorter the vulnerability window, the better)
On WAF (Cloudflare/WAF plugin/host protection), blocking common RCE/upload exploits
File integrity monitoring: alerts on file changes (saves a lot of time compared to troubleshooting after the fact)

6) When should I "rebuild servers/full migration"?

If either of the following occurs, it is recommended to simply reinstall the system/migrate to a clean environment and then start from theTrusted BackupRecovery:

You found the webshell and can't determine the time of the breach.
Multiple abnormal logins to the server account/panel
The core directory is repeatedly changed and you have cleaned up the plugin theme still writes back

Contact Us
Can't read the tutorial? Contact us for a free answer! Free help for personal, small business sites!	Customer Service
① Tel: 020-2206-9892
② QQ咨询：1025174874
(iii) E-mail: [email protected]
④ Working hours: Monday to Friday, 9:30-18:30, holidays off