Cómo desactivar el editor de temas y plugins con DISALLOW_FILE_EDIT

Ocultas en cada instalación predeterminada de WordPress hay dos páginas que casi nadie usa a propósito, pero que silenciosamente convierten una contraseña de administrador robada en un compromiso total del servidor. Apariencia, Editor de archivos del tema y Plugins, Editor de archivos de plugins. Ambas permiten a un administrador editar archivos PHP en bruto dentro de la instalación directamente a través del navegador. Ambas siguen activadas por defecto en 2026. Y ambas son completamente opcionales.

Esta guía explica por qué desactivar los editores es uno de los cambios de endurecimiento con mayor impacto que puedes hacer en un sitio WordPress, cómo es la única línea de configuración necesaria y qué esperar después (incluidos un par de casos límite que sorprenden a la gente).

¿Por qué es un problema el editor de código integrado?

En un día normal, nadie usa el editor. Los cambios en el tema pasan por un tema hijo o por la pipeline de despliegue de un desarrollador. Los cambios en los plugins se hacen en staging, no en producción. El editor está ahí, sin uso, accesible solo para administradores.

"Accesible solo para administradores" es la parte que se rompe bajo ataque. La forma en que se desarrolla la toma de control típica de WordPress no tiene nada que ver con vulnerabilidades a nivel de código en el propio editor. Tiene este aspecto:

1. Se filtra una contraseña de administrador. Phishing, reutilización de contraseñas de un servicio comprometido, el portátil de un desarrollador con malware, un plugin comprometido que extrae cookies de sesión. Cualquiera de los puntos de entrada habituales.
2. El atacante inicia sesión en /wp-admin como un administrador real. Desde la perspectiva de WordPress, no pasa nada raro: es un inicio de sesión legítimo.
3. El atacante va directamente a Apariencia, Editor de archivos del tema, abre functions.php y pega una pequeña puerta trasera en PHP al principio.
4. Desde ese momento, cada petición a la portada del sitio ejecuta el código del atacante. Tienen una shell remota en tu servidor.

El editor convierte "contraseña de administrador robada" en "servidor web robado". Sin él, un atacante que robe una contraseña de administrador sigue teniendo acceso de administrador (lo cual ya es bastante malo), pero tiene que tomar la ruta más lenta y ruidosa de subir un plugin o tema malicioso en zip para conseguir ejecución de código. Ese paso adicional es una oportunidad más para que un plugin de seguridad, un escáner de integridad de archivos o un WAF a nivel de servidor detecten y bloqueen la subida.

La relación coste-beneficio está totalmente desequilibrada. El editor lo usan unas pocas veces al año una minoría diminuta de administradores. El riesgo aparece en cada sitio que sufre una filtración de credenciales. Desactivar el editor es uno de esos cambios en los que el peor caso es "alguien tiene que usar SFTP para una edición de cinco minutos" y el mejor caso es "la toma de control nunca escala de filtración de contraseña a puerta trasera".

La solución: una sola línea en wp-config.php

WordPress tiene una constante integrada exactamente para este caso. Abre wp-config.php en el directorio raíz de WordPress y añade la siguiente línea, en cualquier punto por encima del comentario que dice /* That's all, stop editing! Happy publishing. */:

define('DISALLOW_FILE_EDIT', true);

Guarda el archivo. Eso es todo. El menú Editor de archivos del tema en Apariencia y el Editor de archivos de plugins en Plugins desaparecen inmediatamente para todos los usuarios, incluidos los administradores. Las propias páginas devuelven un error de permisos si se accede a ellas directamente por URL. No hay ningún plugin que instalar, ningún ajuste que mantener, ninguna superficie de compatibilidad de la que preocuparse. La constante forma parte del núcleo de WordPress desde la versión 3.0 (publicada en 2010) y no va a desaparecer.

¿Y si también quiero bloquear las subidas de plugins y temas desde el admin?

WordPress tiene una constante hermana más estricta llamada DISALLOW_FILE_MODS. Hace lo que hace DISALLOW_FILE_EDIT, y además bloquea las subidas de plugins, las subidas de temas y las actualizaciones del núcleo desde dentro de la interfaz de administración. Establecerla tiene exactamente el mismo aspecto:

define('DISALLOW_FILE_MODS', true);

Esa es un cambio mucho mayor en el comportamiento. Con DISALLOW_FILE_MODS activada, ya no puedes instalar ni actualizar plugins, temas ni el núcleo de WordPress a través de la interfaz de administración habitual. Todas las actualizaciones tienen que venir de otro sitio: WP CLI, una pipeline de despliegue, una subida por SFTP o el panel central de un host gestionado.

Para la mayoría de los sitios eso es demasiado restrictivo. Las actualizaciones son la tarea de seguridad más importante en un sitio WordPress, y dificultarlas suele significar que la gente las salte. DISALLOW_FILE_MODS tiene sentido en dos entornos concretos: pipelines de despliegue donde la instalación de producción debe ser de solo lectura, y configuraciones de alta seguridad donde alguien es realmente responsable de empujar las actualizaciones desde fuera. Para todo lo demás, simplemente DISALLOW_FILE_EDIT es el punto óptimo entre "gran ganancia de seguridad, sin dolor operativo".

¿Qué cambia para los usuarios después de configurarla?

Para el 99% de los administradores en el 99% de los sitios: nada visible. Las dos entradas de menú desaparecen del escritorio. Nadie se da cuenta, porque nadie las estaba usando.

Los casos en los que alguien sí lo nota:

• Un desarrollador que edita producción directamente. Si tienes a alguien en el equipo que edita habitualmente archivos de tema o plugin a través del navegador, tendrá que cambiarse a SFTP o a una pipeline de despliegue. Eso es un cambio de flujo de trabajo, no un bloqueador. Si acaso, este es un buen momento para preguntar por qué se está editando código en producción en directo en primer lugar.
• Plugins que se enganchan al editor. Un puñado pequeño de plugins amplían el editor integrado con funciones extra. Fallarán silenciosamente al cargar su interfaz cuando el editor desaparezca. El plugin en sí suele seguir funcionando, solo se rompe la integración con el editor. Si dependes de uno de ellos, verás la diferencia durante las pruebas.
• Código personalizado que usa las capacidades edit_themes o edit_plugins. La constante elimina esas capacidades de todos los roles, incluido el de administrador. El código que condiciona funciones a esas capacidades exactas se comportará como si nadie las tuviera. Es raro, pero conviene saberlo si mantienes un plugin personalizado que hace este tipo de comprobación de capacidades.

Verificar que está activa

1. Inicia sesión en WordPress como administrador.
2. Abre el menú Apariencia en la barra lateral del admin. La entrada "Editor de archivos del tema" debería haber desaparecido.
3. Abre el menú Plugins. La entrada "Editor de archivos de plugins" debería haber desaparecido.
4. Para una comprobación adicional, navega directamente a https://tudominio.com/wp-admin/theme-editor.php. WordPress debería redirigirte a una página que diga "Lo siento, no tienes permiso para editar archivos de tema".
5. Lanza un nuevo análisis de InspectWP. La comprobación de "editor de archivos habilitado" en la sección de seguridad debería pasar a verde.

Si las entradas de menú siguen ahí después de guardar wp-config.php, las razones más comunes son: caché de objetos (vacíala), caché de opcode como OPcache (puede tardar un momento en detectar el archivo nuevo, o puedes reiniciar PHP FPM), la edición acabó en un wp-config.php equivocado en un directorio padre, o la constante se establece más adelante en el archivo por algo más y tu línea está siendo sobrescrita. Abre wp-config.php desde el principio y busca DISALLOW_FILE_EDIT; deberías ver tu línea y nada más estableciéndola de nuevo después.

Qué hace y qué no hace esta solución

Vale la pena dejar claro qué tipo de ataque detiene DISALLOW_FILE_EDIT y qué deja intacto. Detiene la ruta concreta en la que un atacante usa un inicio de sesión de administrador robado para escribir PHP en archivos de tema o plugin a través del navegador. No detiene:

• Que un atacante suba un plugin o tema malicioso en zip desde el admin (usa DISALLOW_FILE_MODS para eso, con las contrapartidas descritas arriba, o restringe las capacidades para subir plugins).
• Que un atacante explote una vulnerabilidad a nivel de código en un plugin para escribir archivos. Eso requiere parchear el propio plugin.
• Que un atacante con acceso por SFTP o por shell. Llegados a ese punto, la capa de WordPress queda totalmente sorteada.

DISALLOW_FILE_EDIT es una capa defensiva, no una estrategia completa. Encaja de forma natural con contraseñas de administrador robustas, autenticación en dos pasos en las cuentas de administrador y un plugin de seguridad que vigile cambios inesperados en los archivos. La combinación elimina la ruta de toma de control más fácil y hace que las más difíciles sean lo bastante ruidosas como para detectarlas.

Una línea en wp-config.php, sin plugin, sin mantenimiento, sin superficie de compatibilidad. Si no haces nada más en un sitio WordPress este mes, haz esto.