Why the WP file editor is insecure

The WordPress editor for plugins and themes is an old legacy you must disable on your installation. Its purpose is to allow editing PHP/CSS files directly from the interface.

You find it on appearance > editor or plugins > editor, and if you can’t access to this screen on your installation, it’s a good news. That would probably mean it’s deactivated.

If it’s still enabled, go to your wp-config.php and add:

define ("DISALLOW_FILE_EDIT", true);

Ok, but why?

In short:

  • live editing PHP code can quickly lead to chaos (e.g. white screen of death)
  • likewise you may break CSS/HTML
  • any user who can access to such screen can embed dynamic code!

WP lovers might say:

  • WordPress catches now fatal errors with a dedicated screen (see fatal error handler)
  • core teams are aware of the risk and have included some alert to encourage users to disable file editing

While it’s true, it’s still enabled by default, and even if the “feature” gets patched eventually, many installations won’t be fixed, as websites owners do not want or cannot update.

Hacking is not trivial but way less difficult than before

Everything is pretty much online, these days. On the one hand, that’s good, as you can learn and practice for free, but kiddies and cybercriminals have access to an extensive range of documentations, videos, scripts, software, and many other resources to start hacking in the wild.

The easiness is shocking. Whether it’s a good thing or not is not relevant, to me. It’s out there, enjoy or deal with it. However, it’s essential to be aware of the phenomenon, at least.

In our specific case, let’s say I’m some kinda of administrator on your WordPress installation. Unfortunately, owners often give that role unwisely to “technical” profiles and webmasters because it allows to manage the entire installation.

It’s convenient but very permissive, and even if you don’t give me ssh/server access, I can manage to hack it, even root the machine sometimes.

The web is full of free PHP scripts, such as reverse shells, ready for use. Users only have to provide an IP (the attacker’ server) and a port to listen connections. One of the most popular PHP shells is probably PenTest Monkey. It uses variables to store your custom configuration:

$VERSION = "1.0";
$ip = '';  // CHANGE THIS
$port = 1234;       // CHANGE THIS
$chunk_size = 1400;
$write_a = null;
$error_a = null;
$shell = 'uname -a; w; id; /bin/sh -i';
$daemon = 0;
$debug = 0;

It’s monkey efficient, and if I can access to the WP file editor, I can include it wherever I want to spawn a shell. It might depend on other factors, though, like additional security measures on the server, but if I get that shell, that would not be surprising.

If I’m lucky enough, which is not rare, as servers often use default configurations, I can even manage to root the machine and use it to do whatever I want, including distributing malware or stealing data.

Of course, I won’t do that. It’s illegal! However, I don’t think hackers will hesitate.

Wrap up

define ("DISALLOW_FILE_EDIT", true);