DISALLOW_FILE_EDIT: desactivar el editor de archivos de WordPress

Añada una línea a wp-config.php: define( 'DISALLOW_FILE_EDIT', true );. Esa línea elimina del escritorio el editor de archivos de temas y el de plugins. Lleva dos minutos y no afecta a las actualizaciones. Además suprime el camino más corto entre una contraseña de administrador robada y código ejecutándose en su servidor.

Este artículo explica por qué importa DISALLOW_FILE_EDIT, cómo configurarlo sin riesgos y qué no impide. También trata de cuándo merece la pena el bloqueo más fuerte, DISALLOW_FILE_MODS, pese al trabajo extra que exige.

Por qué importa DISALLOW_FILE_EDIT: del acceso de administrador al código en ejecución

WordPress incluye dos editores de código integrados. El editor de archivos de temas está en Apariencia en los temas clásicos, o en Herramientas en los temas de bloques. El editor de archivos de plugins está en Plugins en los temas clásicos, o también en Herramientas en los temas de bloques. Ambos permiten a los administradores (en multisitio, a los superadministradores) modificar archivos PHP desde el navegador y guardarlos, y el servidor ejecuta ese código en la siguiente carga de página.

Un acceso de administrador equivale, en la práctica, a una shell. Quien tenga una contraseña de administrador obtenida por phishing, reutilizada o adivinada por fuerza bruta puede abrir functions.php y pegar una puerta trasera. También puede añadir una redirección oculta para los visitantes que llegan desde buscadores o inyectar un skimmer de tarjetas en la plantilla del pago. Nada de esto requiere FTP ni acceso al hosting: basta el login.

La mayoría de los sitios en producción no necesita editar código desde el navegador. Los desarrolladores trabajan en su propio editor, en un entorno de pruebas (staging) o con control de versiones. Editar PHP en vivo en un cuadro de texto no tiene deshacer ni revisión, y un solo error de sintaxis puede tumbar el sitio. En una web de empresa en producción, el editor añade riesgo y poco más.

Proteger el propio acceso es otra tarea, que tratamos en nuestra guía sobre la autenticación en dos pasos para administradores de WordPress. DISALLOW_FILE_EDIT limita lo que puede hacer un login robado.

Cómo añadir DISALLOW_FILE_EDIT a wp-config.php

1. Descargue una copia de wp-config.php y guárdela como copia de seguridad. En muchos hosting está en la raíz de WordPress; algunas instalaciones lo colocan un directorio por encima.
2. Abra el archivo por SFTP o con el administrador de archivos de su hosting. No use un plugin de WordPress para esto.
3. Busque DISALLOW_FILE_EDIT en el archivo. Si ya está definida, modifique esa línea en lugar de añadir otra: definir una constante dos veces provoca una advertencia de PHP.
4. Añada la línea encima del comentario que empieza por /* That's all, stop editing!. Debe ir antes de que se cargue wp-settings.php.
5. Guarde, suba el archivo y recargue el escritorio.

/* Desactivar los editores de archivos de temas y plugins en el escritorio */
define( 'DISALLOW_FILE_EDIT', true );

/* That's all, stop editing! Happy publishing. */

Después, compruebe el resultado. Las entradas de menú del editor de archivos de temas y del editor de archivos de plugins deberían haber desaparecido. Si abre directamente /wp-admin/theme-editor.php, ahora debería ver un error de permisos en lugar del editor.

Esta constante no se puede reactivar desde el escritorio, y eso es precisamente lo que se busca. Quien quiera recuperar el editor necesita acceso a los archivos del servidor, no solo una contraseña de administrador. El ajuste se aplica a toda la instalación y, en multisitio, a todos los sitios de la red. La documentación oficial de wp-config.php la incluye junto con el resto de constantes de configuración.

Si no tiene acceso por SFTP ni al administrador de archivos, el plugin Security Audit & Compliance de secaudit.eu incluye un interruptor opcional que desactiva los editores de archivos del escritorio.

Qué no impide desactivar el editor de archivos

DISALLOW_FILE_EDIT elimina la vía más fácil. No vuelve inofensiva una cuenta de administrador. Un administrador, o un atacante que use esa cuenta, todavía puede:

• subir un zip de plugin o de tema con código malicioso, en Plugins → Añadir nuevo plugin o Apariencia → Temas
• crear nuevas cuentas de administrador, cambiar el correo del administrador o restablecer las contraseñas de otros usuarios
• cambiar ajustes como la URL del sitio, el registro de usuarios o el rol por defecto
• exportar datos de usuarios y de pedidos

Los atacantes con acceso por FTP, SSH, panel de hosting o base de datos se saltan WordPress por completo, y ninguna constante de wp-config.php los detiene. La constante tampoco sirve contra plugins vulnerables que se pueden explotar sin ningún login. Es un problema distinto, con sus propias soluciones, que tratamos en nuestra guía sobre plugins vulnerables de WordPress.

Considere DISALLOW_FILE_EDIT una capa más. Es barata y muy recomendable, pero no corrige un login débil ni un plugin sin parchear.

Plugins de gestión de archivos y de fragmentos de código: el editor con otro nombre

Varios tipos de plugins recuperan el mismo riesgo, y DISALLOW_FILE_EDIT no los cubre:

• plugins de gestión de archivos que permiten explorar, editar y subir archivos desde el escritorio
• gestores de fragmentos de código (snippets) que almacenan PHP y lo ejecutan en cada petición
• campos de «insertar código en el encabezado/pie» que aceptan scripts o PHP
• opciones del tema o del constructor de páginas con un cuadro de «código personalizado»

Si alguno de ellos está activo, un atacante con acceso de administrador sigue teniendo un editor de código.

Empiece por hacer inventario. Recorra Plugins → Plugins instalados y las opciones de su tema, y anote todo lo que pueda editar archivos o ejecutar código personalizado. Después trate cada tipo:

• Gestores de archivos: elimínelos en cuanto termine la tarea puntual. Desactivarlos no basta, porque el código sigue en el servidor y puede tener sus propias vulnerabilidades.
• Fragmentos que realmente necesita: muévalos a un pequeño plugin propio o a un tema hijo, y manténgalos bajo control de versiones. Así los cambios pasan por su despliegue habitual en lugar de hacerse en el navegador.
• Gestores de fragmentos que conserve: compruebe qué roles pueden crear o editar fragmentos y restrinja ese permiso al menor número de personas posible.

DISALLOW_FILE_MODS: un cierre más fuerte, con contrapartidas reales

define( 'DISALLOW_FILE_MODS', true ); va más allá. Bloquea la instalación, actualización y eliminación de plugins y temas desde el escritorio, y desactiva también las actualizaciones automáticas en segundo plano de WordPress. Así se cierra la vía de la subida de zips que DISALLOW_FILE_EDIT deja abierta.

El coste es que nada se actualiza por sí solo. Si nadie ejecuta las actualizaciones por otra vía, el sitio se va quedando atrás en correcciones de seguridad. Los avisos habituales de actualización desaparecen además del escritorio. Solo Salud del sitio indica que las actualizaciones en segundo plano están desactivadas, de modo que es fácil pasarlo por alto.

Prepare una vía de actualización antes de activar DISALLOW_FILE_MODS

Elija uno de estos enfoques y conviértalo en rutina:

• WP-CLI en el servidor. Ejecute las actualizaciones desde la línea de comandos, a mano o como tarea programada:

wp core update
wp plugin update --all
wp theme update --all

• Despliegue con Git o Composer. Las versiones de plugins y temas se definen en su repositorio, y un pipeline compila y despliega el sitio. Las actualizaciones pasan a ser commits que se pueden revisar y revertir.
• Herramientas de actualización del hosting gestionado. Algunos proveedores ejecutan las actualizaciones por usted, a menudo con una copia de seguridad o una comprobación visual previa. Averigüe exactamente qué cubren y si incluyen los plugins premium.

Pruebe el método elegido en una copia de staging con DISALLOW_FILE_MODS ya activado. La configuración de su servidor determina qué funciona allí, así que confírmelo antes de tocar producción.

Programe las actualizaciones con una tarea cron o un disparador del pipeline, y compruebe que la tarea se ejecuta de verdad. Una tarea que falla en silencio no es mejor que no tener ninguna. Lleve un registro de qué se actualizó y cuándo: ese registro es una buena prueba de las «medidas técnicas y organizativas apropiadas» del artículo 32 del RGPD.

La rapidez importa. Patchstack, un proveedor de seguridad, indica en su informe State of WordPress Security in 2026 que la mediana ponderada del tiempo hasta la explotación masiva fue de 5 horas para las vulnerabilidades muy explotadas. Una ronda mensual de actualizaciones manuales no sigue ese ritmo.

Compruebe que el bloqueo sigue en su sitio

Las constantes se pierden con facilidad en migraciones, cambios de hosting y depuraciones «temporales». Revíselas de vez en cuando:

grep -n DISALLOW_FILE wp-config.php
wp config get DISALLOW_FILE_EDIT

El primer comando muestra cada línea coincidente con su número de línea. El segundo muestra el valor que WP-CLI lee de la configuración. Ejecute ambos de nuevo tras cada traslado a un servidor o hosting nuevo. Vigile también los cambios inesperados en los archivos PHP de su tema y de sus plugins. Con el bloqueo activo, un cambio así significa que alguien entró por otra vía.

Si descubre que el editor ya se ha utilizado en su contra, esto ya no es hardening sino respuesta a incidentes. Lea nuestras guías sobre cómo encontrar web shells y cómo eliminar malware de WordPress antes de cambiar nada más.

El plugin de auditoría de secaudit.eu comprueba los ajustes de hardening y de configuración, incluido el editor de archivos. También hace un seguimiento de la integridad de los archivos frente a una referencia (baseline), de modo que los cambios en los archivos del tema y de los plugins aparecen en el informe → secaudit.eu

FAQ

¿DISALLOW_FILE_EDIT rompe mi sitio o las actualizaciones?

No. Solo elimina los dos editores del escritorio. Las actualizaciones de plugins, temas y del núcleo, incluidas las automáticas, siguen funcionando. Solo DISALLOW_FILE_MODS cambia la forma en que se actualiza.

¿Puedo reactivar el editor temporalmente?

Sí. Ponga la constante en false o comente la línea, y restáurela después. Es mejor editar el archivo por SFTP o en staging, de modo que el editor no tenga que volver nunca.

¿WordPress incluye este ajuste en el escritorio?

No. El núcleo no ofrece ninguna opción en el escritorio; es una constante que se define en wp-config.php. Si no puede editar ese archivo, use un plugin que ofrezca un interruptor para desactivar los editores de archivos.