WordPress theme editor RCE

A WordPress administrator can edit theme PHP from Appearance → Theme Editor (theme-editor.php). Since those files are run by the PHP interpreter when served, being able to edit them equals code execution on the server: it is the CMS's most direct post-authentication vector.

The flow: with an admin session, pick a theme (preferably an inactive one to avoid breaking the site), edit a low-visibility template (404.php, page.php...) and paste a webshell or a PHP reverse shell. Then request that file directly:

http://<ip>/wp-content/themes/<theme>/404.php

Loading it runs the injected PHP with the web process's privileges. Admin access may come from default, reused, or leaked credentials, or from a vulnerable plugin.

Nuances. It requires the administrator role and that file editing is not disabled. Many managed hosts set DISALLOW_FILE_EDIT in wp-config.php, which removes the option from the panel; in that case you fall back to uploading a malicious plugin/theme.

How to detect it. The access-log signature is a POST to wp-admin/theme-editor.php (or the REST edit endpoint) with a newcontent parameter and a file=...php, followed by a direct GET to that template (/wp-content/themes/<theme>/404.php), a sequence a real admin almost never performs. On disk, modification of a theme .php with system(/eval(//dev/tcp fires FIM on wp-content/themes/. Confirmation is the web process spawning sh/bash when that file is served (auditd/Sysmon for Linux).

Defence. define('DISALLOW_FILE_EDIT', true), protect the admin account (MFA, strong passwords) and do not reuse credentials. Related to file upload to RCE and WordPress plugin LFI.