Cómo proteger /wp-admin/install.php en WordPress

Cada instalación de WordPress incluye un archivo llamado wp-admin/install.php. En un sitio sano es prácticamente inofensivo. WordPress detecta que el sitio ya está configurado y devuelve una breve página de "Ya instalado". Pero existe un caso particular que muchos propietarios de sitios subestiman. En el momento en que algo va mal con la base de datos, ese mismo archivo se convierte en un asistente de instalación totalmente operativo. Un atacante que tropiece con él en el momento adecuado puede reinstalar WordPress sobre tu dominio, apuntarlo a una base de datos que él controle y largarse con el control total.

Esta guía explica cuándo install.php es realmente peligroso, qué plugins de seguridad cubren genuinamente este caso (no todos lo hacen, a pesar de lo que sugiere su marketing) y cómo bloquear el archivo correctamente. Eso incluye la situación menos cómoda en la que estás en un hosting compartido sin acceso a la configuración del servidor.

¿Cuándo es realmente un problema install.php?

Si visitas https://tudominio.com/wp-admin/install.php en un sitio sano, WordPress comprueba si la tabla wp_options ya contiene un siteurl. En caso afirmativo, muestra la pantalla "Ya instalado" y ahí termina la historia. Sin formulario, sin acción, sin toma de control.

El problema empieza en el momento en que WordPress no puede leer ese valor. Escenarios típicos:

• Las credenciales de la base de datos en wp-config.php se rompieron (contraseña incorrecta tras una migración de hosting, nombre de BD mal escrito).
• Alguien eliminó o truncó la tabla wp_options, ya sea por accidente durante una migración o intencionadamente mediante una inyección SQL en un plugin vulnerable.
• Un clon de staging fallido dejó el sistema de archivos en su sitio pero la base de datos vacía.
• El usuario de la base de datos perdió permisos en tablas concretas.

En todos esos casos, el asistente de instalación queda disponible para cualquiera en internet. Quien llegue primero podrá elegir el nombre de usuario, contraseña y correo electrónico del administrador, y se queda efectivamente con el dominio. Por eso esta comprobación existe en InspectWP aunque el archivo sea "normal" en cualquier instalación de WordPress.

¿Qué plugins de seguridad pueden proteger realmente install.php?

Esta es la parte que confunde a muchos, así que merece la pena ser preciso. La mayoría asume que cualquier plugin de seguridad de WordPress cubrirá automáticamente install.php. Eso es verdad a medias. La respuesta depende totalmente de cómo se carga el plugin.

Un plugin normal de WordPress arranca dentro de WordPress. Necesita la base de datos para iniciarse. Si tu BD está rota o vacía (que es el único escenario realista en el que install.php se vuelve peligroso), WordPress nunca arranca lo suficiente como para cargar el plugin. La petición aterriza directamente en install.php y PHP renderiza alegremente el asistente de instalación. Los plugins de seguridad que se ejecutan como plugins normales no pueden ayudar en esa situación, por definición.

Sin embargo, varios plugins utilizan un mecanismo de PHP llamado auto_prepend_file. Ese ajuste indica a PHP que ejecute un archivo concreto antes de cualquier otro script PHP en el servidor. Cuando un plugin de seguridad se registra de esta forma, se ejecuta antes de wp-config.php, antes de que se intente la conexión a la base de datos y antes de install.php. Tiene sus propios archivos de configuración y, cuando es necesario, su propia conexión a la base de datos. Una instalación de WordPress rota no le afecta.

Plugins que admiten este modo (y que, por tanto, pueden proteger install.php incluso cuando la base de datos de WordPress está caída):

• Wordfence en modo Extended Protection (a veces llamado Optimized Mode). Este no es el modo por defecto tras la instalación. Tienes que habilitarlo explícitamente en los ajustes del firewall de Wordfence. Una vez activo, se coloca un archivo llamado wordfence-waf.php en la raíz de WordPress y se registra mediante .htaccess, .user.ini o php.ini.
• NinjaFirewall (WP Edition). Utiliza auto_prepend_file como modo predeterminado. Se configura así en la instalación, sin necesidad de ningún interruptor adicional.
• NinjaFirewall (Pro / Full WAF). Mismo mecanismo, pero registrado a nivel de servidor. Se ejecuta totalmente fuera de WordPress.
• BitFire Security. Admite un modo "Always On Protection", también basado en auto_prepend_file. Comportamiento comparable al de Wordfence Extended Protection.
• Shield Security (ShieldPRO). También se carga mediante auto_prepend_file, aunque adopta un enfoque más conservador y no modifica directamente .htaccess.
• MalCare. Utiliza auto_prepend_file como parte de su configuración de WAF.

Plugins que no pueden bloquear install.php cuando WordPress está roto, porque se ejecutan como plugins normales de WordPress:

• Wordfence en el Modo Básico por defecto (antes de habilitar Extended Protection).
• Solid Security (antes iThemes Security). No incluye un WAF que se ejecute antes de WordPress.
• All-In-One WP Security & Firewall. Bueno para el endurecimiento de archivos y de inicio de sesión, pero se ejecuta dentro de WordPress.
• La mayoría de los firewalls basados en plugins que no se apoyan en auto_prepend_file.

Una consecuencia práctica: si usas Wordfence, ve a Wordfence, Firewall, Manage WAF y comprueba si el mensaje indica "Optimized" o "Extended Protection Enabled". Si todavía dice Basic Mode, el asistente de optimización te guiará para configurar auto_prepend_file en tu servidor. Este único cambio es lo que convierte a Wordfence de un plugin reactivo en un genuino firewall previo a WordPress.

Una advertencia para ambos caminos. El mecanismo requiere que tu hosting permita realmente auto_prepend_file mediante .htaccess, .user.ini o php.ini. En la mayoría de hostings compartidos esto funciona de serie. En algunos hostings gestionados muy restringidos, el ajuste está limitado, y el asistente de optimización fallará en silencio o mostrará un aviso. En ese caso vuelves al enfoque de regla en el servidor web descrito a continuación.

Opción 1: bloquear install.php mediante .htaccess (Apache)

Si tu hosting usa Apache (que es lo que utilizan la mayoría de proveedores de hosting compartido como IONOS, Strato, All-Inkl, Hostinger, DomainFactory, SiteGround, Bluehost), puedes añadir el siguiente bloque al archivo .htaccess en el directorio raíz de WordPress:

<Files "install.php">
  Require all denied
</Files>

Esto funciona en Apache 2.4 y superior, que es lo que prácticamente todos los hostings llevan años utilizando. Si tienes algo más antiguo (Apache 2.2), usa la sintaxis heredada:

<Files "install.php">
  Order allow,deny
  Deny from all
</Files>

Coloca el fragmento por encima del marcador # BEGIN WordPress para que la gestión automática de reescrituras de WordPress no lo toque durante las actualizaciones.

Tras guardar el archivo, visita https://tudominio.com/wp-admin/install.php en una ventana privada del navegador. Deberías ver una respuesta 403 Forbidden. Si sigues viendo la página "Ya instalado", las sobreescrituras de .htaccess están deshabilitadas en tu hosting. Pasa a la Opción 3.

Opción 2: bloquear install.php mediante nginx

En nginx no hay .htaccess. Si gestionas tu propio servidor (VPS, dedicado o un hosting flexible como Hetzner Cloud), añade esto dentro del bloque server de tu sitio:

location = /wp-admin/install.php {
  deny all;
  return 403;
}

Recarga nginx con sudo nginx -t && sudo systemctl reload nginx y prueba con curl -I https://tudominio.com/wp-admin/install.php. Deberías obtener un 403.

Algunos hostings gestionados que usan nginx por debajo (como Raidboxes, Kinsta, WP Engine) ya incluyen este tipo de regla. Merece la pena revisar la documentación de tu hosting o abrir un ticket de soporte. La respuesta suele ser "ya está cubierto" o te añaden la regla.

Opción 3: hosting compartido sin sobreescrituras de Apache

Si estás en un hosting nginx compartido y se ignora el .htaccess, tienes menos opciones, pero no estás atascado. Por orden de preferencia:

1. Instala uno de los firewalls previos a WordPress mencionados arriba. En hostings compartidos donde se permite auto_prepend_file, un plugin como NinjaFirewall o Wordfence en modo Extended Protection te ofrece la misma protección que una regla del servidor, sin tocar la configuración del servidor. Suele ser el camino más pragmático.
2. Pregunta a tu hosting. La mayoría de los hostings de WordPress gestionados añadirán una regla a nivel de servidor por ti si la pides. Les lleva cinco minutos y lo hacen rutinariamente.
3. Sustituye el contenido del archivo. Puedes abrir wp-admin/install.php mediante SFTP y sustituir todo el archivo por una sola línea:

   <?php // deshabilitado intencionadamente, ver install.php.bak

   Guarda una copia de seguridad del original (install.php.bak) fuera de la raíz web pública por si alguna vez necesitas reinstalar legítimamente. La desventaja: las actualizaciones del núcleo de WordPress restaurarán el archivo original, así que tendrás que volver a aplicar el cambio tras cada actualización mayor. Un pequeño must-use plugin puede automatizar esto (consulta el snippet de código relacionado).
4. Denegar mediante permisos de archivo. Cambiar el modo del archivo a 000 mediante SFTP también bloquea el acceso en la mayoría de hostings. Misma advertencia: las actualizaciones del núcleo lo restablecerán.

¿Qué hay de renombrar o eliminar install.php?

Técnicamente puedes eliminar install.php por completo. WordPress no lo necesita para el funcionamiento normal. Solo se utiliza durante la configuración inicial y para algunas rutinas internas de actualización. La pega es que el archivo se restaura con cada actualización del núcleo de WordPress, así que la eliminación no es una solución permanente. También es referenciado ocasionalmente por el proceso de actualización automática, por lo que puedes ver avisos en tu registro de errores si falta.

Renombrarlo es aún peor. WordPress no encontrará el archivo con su nuevo nombre, pero recreará alegremente el original durante la siguiente actualización. Acabas con dos copias.

Bloquear el acceso a nivel del servidor web, o mediante un firewall previo a WordPress, es casi siempre la mejor respuesta.

Cómo verificar tu configuración

Después de aplicar una de las opciones anteriores:

1. Abre https://tudominio.com/wp-admin/install.php en una ventana privada o de incógnito.
2. Deberías ver una página 403 Forbidden (o 404 si eliminaste el archivo, o la página de bloqueo personalizada del firewall si elegiste la opción del plugin).
3. Si ves la página "Ya instalado" o, mucho peor, un formulario de instalación real, la regla no está activa. Vuelve a comprobar la ruta del archivo, vacía cualquier caché (Cloudflare, Varnish, caché de página a nivel de servidor) e inténtalo de nuevo.
4. Ejecuta un nuevo análisis con InspectWP. La comprobación "install.php expuesto" en la sección de WordPress debería ponerse verde.

Comprobaciones relacionadas que merece la pena ejecutar

Mientras estás reforzando la seguridad, merece la pena aplicar el mismo tipo de bloqueo a nivel de servidor web (o regla de firewall previo a WordPress) a otros endpoints sensibles: xmlrpc.php (a no ser que lo uses activamente), wp-config.php.bak, .git/, .env y cualquier archivo phpinfo.php que algún desarrollador haya podido dejar olvidado. InspectWP marca todos estos automáticamente en su sección de seguridad.

El caso de install.php es un buen ejemplo de defensa en profundidad. WordPress se protege a sí mismo, un plugin de seguridad bien configurado añade otra capa, y una regla en el servidor web cubre el único escenario en el que ambos pueden fallar. Elige la combinación que se adapte a tu hosting. Cinco líneas de configuración, o un único interruptor en un plugin de firewall, son suficientes para cerrar la brecha de forma definitiva.