The WordPress file editor: why to disable it before it is too late

WordPress lets administrators edit theme and plugin files directly from the dashboard via 'Appearance > Theme File Editor' and 'Plugins > Plugin File Editor'. From a security perspective this is catastrophic - and unnecessary, since no serious developer uses it.

Why this matters

An attacker who compromises a single admin account can inject malicious PHP into any theme or plugin file with one click, without ever touching the server. They do not need FTP, SSH or a file upload - they open functions.php in the browser and paste a backdoor. The whole attack takes 30 seconds. With the editor disabled, the same attacker must additionally obtain FTP/SFTP credentials, which is roughly an order of magnitude less common (FTP passwords usually live only on the developer's machine, not in credential-stuffing lists). Disabling the editor is one of the first recommendations in every official WordPress.org hardening guide. There are also documented cases of compromised plugins using the editor on the admin's behalf - creating a 'third plugin' through the editor to maintain persistence after the original plugin was removed.

How to detect

The audit reads wp-config.php and looks for the DISALLOW_FILE_EDIT constant. If it is missing or false, the check is red. Manually: go to Appearance > Theme File Editor or Plugins > Plugin File Editor. If the link appears in the menu, the editor is on. If it is gone, the editor is off. The audit also checks DISALLOW_FILE_MODS which disables plugin installs and updates as well, but that is too aggressive for most sites.

How to fix

1. Edit wp-config.php over FTP/SFTP, host File Manager, or SSH.
2. Before the /* That's all, stop editing! */ line add:

   define('DISALLOW_FILE_EDIT', true);

3. If the line already exists, make sure the value is true, not false.
4. Save the file.
5. Open the dashboard and verify: the Appearance and Plugins menus should still show their full set, but 'Theme File Editor' and 'Plugin File Editor' should be gone.
6. If you want extra hardening and will never install or update plugins from the dashboard:

   define('DISALLOW_FILE_MODS', true);

   This also disables the plugin store and automatic updates. Use it only when you have an external deploy pipeline (Composer + WP-CLI).
7. For future code changes: use SFTP, a local IDE with deploy, or WP-CLI.

Common mistakes

Do not enable DISALLOW_FILE_MODS if you update plugins from the dashboard - you will get stuck. Do not think 'I am the only admin, it is fine' - if your password leaks, the attacker will do exactly what you would have done. Do not toggle the constant off 'just for one quick edit' - if you must edit, use SFTP. Do not assume the host disabled the editor for you - some managed hosts do (Kinsta, WP Engine), most do not.

Verifying the fix

Re-run the audit. Manually: in the dashboard, Appearance should no longer list 'Theme File Editor' and Plugins should no longer list 'Plugin File Editor'. If they are still there, confirm you saved wp-config.php in the file the server actually reads (not a staging copy) and that there is no PHP opcode cache holding the old config (rare).