Exposición WordPress: versión, readme.html, install.php, listado de directorios

Los atacantes no adivinan — verifican 4 archivos específicos. Los tests #41 a #44 revelan si tu sitio WordPress está difundiendo sus vulnerabilidades al mundo.

Antes de lanzar un ataque real, cada hacker sigue la misma checklist. No empieza con fuerza bruta o inyección SQL. Empieza con reconocimiento — recopilando información sobre el objetivo. Y WordPress se lo pone extraordinariamente fácil.

Por defecto, WordPress expone su número de versión en el código fuente HTML, deja un archivo readme.html en el directorio raíz, mantiene el script de instalación accesible y permite a cualquiera navegar por los directorios internos. Cada uno de estos es una pista gratuita para un atacante.

Orilyt ejecuta 4 tests complementarios para detectar estas exposiciones. El test #41 verifica el fingerprinting de versión. El test #42 sondea readme.html y license.txt. El test #43 prueba si install.php es accesible. El test #44 verifica el listado de directorios en wp-content, wp-includes, uploads, plugins y themes. Juntos, mapean toda la superficie de fuga de información de un sitio WordPress.

Test #41: ¿Tu versión de WordPress está expuesta?

El test #41 busca 4 señales distintas que revelan tu versión de WordPress a cualquiera que se tome la molestia de mirar:

1. Etiqueta meta generator — WordPress inyecta <meta name="generator" content="WordPress X.X"> en el head HTML por defecto. Es la divulgación de versión más directa. Cualquier escáner la detecta instantáneamente
2. Cadenas de versión en assets — los archivos CSS y JS de wp-includes y wp-content incluyen parámetros ?ver=X.X.X. Estas cadenas a menudo coinciden exactamente con la versión del núcleo de WordPress
3. Endpoint REST API — /wp-json/ es accesible por defecto y confirma que WordPress está instalado. La respuesta incluye información de namespaces que revela la versión de la API
4. Cabecera Link — WordPress envía una cabecera HTTP Link que referencia wp-json, confirmando el CMS incluso antes de que se cargue el cuerpo de la página

Puntuación: si la etiqueta meta generator y las cadenas de versión de assets están presentes, la puntuación cae a 30/100. Una señal crítica más la API REST = 50. Solo la API REST (sin datos de versión) = 80. Si todas las señales están ocultas, la puntuación es 100.

Test #42: ¿Son accesibles readme.html y license.txt?

Cada instalación de WordPress incluye dos archivos en la raíz: readme.html y license.txt. No sirven para nada en producción — pero confirman el CMS y pueden revelar detalles de versión:

1. readme.html — este archivo es una página HTML formateada que muestra "WordPress" en grande y a menudo incluye el número de versión exacto. Es la verificación de fingerprint más simple: solicitar /readme.html, comprobar si devuelve 200
2. license.txt — contiene el texto de la licencia GPL con "WordPress" en la cabecera. Menos útil directamente para los atacantes que readme.html, pero confirma el CMS y que no se aplicó ningún endurecimiento

Puntuación: ambos archivos accesibles = 30/100. Solo readme.html accesible = 40. Solo license.txt = 60. Ambos devuelven 403 o 404 = 100. Estos archivos simplemente no deberían servirse en producción.

Test #43: ¿Es accesible install.php?

El instalador de WordPress se encuentra en /wp-admin/install.php. En un sitio correctamente configurado, este script redirige a la página de login o devuelve 403/404. Pero en servidores mal configurados, puede ser directamente accesible:

1. El test solicita /wp-admin/install.php y verifica la respuesta HTTP. Si la respuesta es 200 y el cuerpo contiene "install WordPress" o la palabra clave "wp-install", el script está expuesto
2. Un instalador accesible es un hallazgo crítico. En el peor caso, un atacante podría desencadenar una reinstalación — reiniciando la conexión a la base de datos, creando una nueva cuenta de administrador y tomando el control total del sitio
3. La mayoría de los entornos de hosting lo protegen automáticamente, pero las configuraciones de servidor personalizadas, setups Docker o Nginx sin reglas adecuadas a menudo lo dejan expuesto

Puntuación: si la página de instalación es accesible y parece el asistente de instalación de WordPress, la puntuación cae a 30/100. Una respuesta 403/404 = 100. Una redirección = 95.

Test #44: ¿Está activado el listado de directorios?

El listado de directorios (autoindex) permite a cualquiera navegar por el contenido de una carpeta a través del navegador. El test #44 verifica 5 directorios WordPress críticos:

1. /wp-content/ — el directorio principal de contenido. Listarlo revela todos los plugins instalados, temas y carpetas de uploads de un vistazo
2. /wp-includes/ — archivos del núcleo de WordPress. El listado confirma la estructura de la instalación y la versión
3. /wp-content/uploads/ — archivos subidos por usuarios. Puede contener documentos sensibles, facturas o archivos de respaldo que nunca debían ser públicos
4. /wp-content/plugins/ — cada plugin instalado es visible con su nombre de directorio exacto, facilitando la búsqueda de vulnerabilidades conocidas en cada uno
5. /wp-content/themes/ — todos los temas visibles, incluidos los inactivos que pueden tener fallos de seguridad sin parchear

El test solicita cada directorio y busca marcadores de autoindex en la respuesta: "Index of /", "Directory listing for", enlaces "Parent Directory". Si el servidor devuelve una página HTML listando archivos en lugar de un 403, el directorio está expuesto.

Puntuación: 3 o más directorios expuestos = 20/100. Dos expuestos = 35. Uno expuesto = 50. Todos bloqueados (403/404) = 100. El directorio uploads recibe peso extra porque puede contener datos de usuario.

Correcciones comunes — todas en menos de 5 minutos

Cada una de estas exposiciones se corrige con simples cambios de configuración. Sin código, sin plugins, sin tiempo de inactividad:

1. Eliminar la etiqueta meta generator — añade remove_action('wp_head', 'wp_generator') en el functions.php de tu tema. Una línea, efecto inmediato
2. Eliminar las cadenas de versión — añade un filtro para quitar los parámetros ?ver= de scripts y estilos. O usa un plugin de seguridad que lo haga automáticamente
3. Bloquear readme.html y license.txt — añade una regla deny en .htaccess: <Files "readme.html"> Require all denied </Files>. O simplemente elimina los archivos (volverán con las actualizaciones, así que .htaccess es mejor)
4. Bloquear install.php para no autenticados — la mayoría de los hosts lo gestionan, pero si el tuyo no lo hace, añade una regla .htaccess en wp-admin/ que restrinja el acceso a install.php
5. Desactivar el listado de directorios — añade Options -Indexes en tu .htaccess raíz. Esta única línea bloquea el autoindex para todo el sitio. Debería estar ya presente en la mayoría de las instalaciones WordPress, pero muchas configuraciones personalizadas lo omiten

El patrón es constante: todos son problemas de configuración por defecto. WordPress viene en un estado permisivo para facilitar la instalación. El endurecimiento es un paso separado que la mayoría de los propietarios nunca dan.

Por qué estos hallazgos venden contratos de mantenimiento

Para freelances y agencias, estos 4 tests son poderosos iniciadores de conversación. Son fáciles de demostrar, visualmente obvios, y el cliente no necesita entender código:

En el informe Orilyt, cada test genera una recomendación FIA:

1. Hecho: "La versión WordPress 6.4.1 es visible en el código fuente HTML" o "5 directorios son navegables libremente"
2. Impacto: "Los atacantes pueden buscar exploits conocidos para esta versión exacta" o "Todos los plugins instalados son visibles, permitiendo un escaneo dirigido de vulnerabilidades"
3. Acción: "Eliminar la etiqueta meta generator y quitar las cadenas de versión" o "Añadir Options -Indexes al .htaccess"

Estos hallazgos crean urgencia porque son tangibles. Puedes abrir el navegador del cliente, escribir /readme.html y mostrarle la versión de WordPress en pantalla. Puedes navegar /wp-content/plugins/ y listar cada plugin instalado. No es abstracto — es una demostración en vivo de la exposición.

Los 4 archivos que los hackers verifican primero — testeados en segundos

La exposición WordPress no es cuestión de ataques sofisticados. Es cuestión de frutos al alcance de la mano. Números de versión, archivos por defecto, instalador accesible, listado de directorios — son las primeras cosas que cualquier escáner o atacante verifica. Y todo se corrige en minutos.

Los tests #41 a #44 cubren toda esta superficie. Detectan cada fuga de información común, evalúan la gravedad y generan recomendaciones claras. Ejecútalos antes de que un atacante lo haga.

Para auditorías orientadas al cliente, los hallazgos de exposición WordPress son el punto de entrada perfecto. Son visuales, urgentes, y las correcciones son rápidas. Si un sitio falla en estos 4 tests, hay una conversación de seguridad pendiente — y probablemente un contrato que firmar.