WordPress theme editor RCE

Un administrador de WordPress puede editar el código PHP de los temas desde Appearance → Theme Editor (theme-editor.php). Como esos ficheros los ejecuta el intérprete PHP al servirse, poder editarlos equivale a ejecución de código en el servidor: es el vector post-autenticación más directo del CMS.

El flujo: con sesión de administrador, se elige un tema (mejor uno inactivo para no romper el sitio), se edita una plantilla poco visible (404.php, page.php...) y se pega una webshell o una reverse shell PHP. Después se solicita ese fichero directamente:

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

Al cargarlo, el PHP inyectado se ejecuta con los privilegios del proceso web. El acceso de administrador puede venir de credenciales por defecto, reutilizadas, filtradas o de un plugin vulnerable.

Matices. Requiere rol de administrador y que la edición de ficheros no esté desactivada. Muchos hostings gestionados definen DISALLOW_FILE_EDIT en wp-config.php, que quita la opción del panel; en ese caso hay que recurrir a subir un plugin/tema malicioso.

Cómo detectarlo. La firma en el log de acceso es un POST a wp-admin/theme-editor.php (o al endpoint REST de edición) con el parámetro newcontent y un file=...php, seguido de un GET directo a esa plantilla (/wp-content/themes/<tema>/404.php), secuencia que un administrador real casi nunca ejecuta. En disco, la modificación de un .php de tema con system(/eval(//dev/tcp salta con FIM sobre wp-content/themes/. La confirmación es el proceso web lanzando sh/bash al servir ese fichero (auditd/Sysmon for Linux).

Defensa. define('DISALLOW_FILE_EDIT', true), proteger la cuenta de administrador (MFA, contraseñas fuertes) y no reutilizar credenciales. Relacionado con subida de fichero a RCE y LFI en plugins de WordPress.