Cuando hablamos de exposición de versiones (version disclosure) nos referimos a cualquier evidencia, directa o indirecta, que permita a un tercero inferir:

  • la versión del core de WordPress,
  • la versión de plugins y temas,
  • y/o componentes del stack (servidor web, framework, runtime).

Eso se usa para fingerprinting: identificar tecnología y versiones para priorizar rutas de ataque (por ejemplo, correlacionar una versión concreta con una vulnerabilidad conocida o con una configuración débil). OWASP, en el contexto de pruebas de seguridad, contempla el fingerprinting del servidor mediante análisis de cabeceras/banners como parte del reconocimiento.

A nivel de clasificación de seguridad, esto encaja en el marco de exposición de información: la severidad depende de qué se exponga, a quién y cómo se aproveche. CWE lo trata como “Exposure of Sensitive Information” y deja claro que el impacto varía según el contexto y la utilidad para un atacante.

📌 Guía completa: Seguridad WordPress (checklist + prioridades).

✅ Acción rápida: Iniciar auditoría gratis y recibir evidencias en minutos.

1) Riesgo real: lo que esta exposición facilita (y lo que no)

Qué facilita

  • Reconocimiento y priorización: un atacante automatiza el mapeo “sitio → tecnología → versión → posibles CVEs/configuraciones”.
  • Ataques oportunistas: escaneos masivos buscan versiones o huellas frecuentes y prueban vectores asociados.
  • Incremento de ruido operativo: más intentos automatizados, más carga en endpoints sensibles.

PortSwigger describe la information disclosure como un tipo de vulnerabilidad que, aunque a veces parezca “menor”, puede proporcionar datos útiles para encadenar ataques.

Qué NO debemos prometer

Reducir fingerprinting no sustituye:

  • actualizar core/plugins/tema,
  • hardening de permisos,
  • controles de autenticación,
  • WAF/rate limiting,
  • y una higiene general de seguridad.

De hecho, WordPress insiste en que la seguridad es reducción de riesgo, no eliminación total.
Y también advierte que “security through obscurity” es, en general, una estrategia primaria poco sólida (aunque puede ayudar en áreas concretas como medida complementaria).

2) Dónde se filtran versiones en WordPress (mapa práctico)

A continuación, los vectores más habituales que observamos en entornos reales:

A) Meta generator y señales en el HTML (wp_generator)

WordPress puede emitir un generator tag a través de la función wp_generator, que se engancha a wp_head. La propia referencia de wp_generator() incluye como caso de uso “remove the WordPress version number”.

B) Query string ?ver= en CSS/JS

WordPress permite añadir un parámetro de versión a scripts y estilos con wp_enqueue_script() y wp_enqueue_style().

  • En ambos casos, la documentación indica que el parámetro de versión se añade a la URL como query string para cache-busting.
  • Además, especifica que si ver se establece a false, WordPress puede añadir automáticamente una versión equivalente a la versión instalada de WordPress; y si se establece a null, no se añade versión.

Esto es importante: muchos sitios terminan filtrando la versión de WP (o de plugins/temas) a través de URLs de assets.

C) Archivos públicos “de cortesía” que revelan versión

En instalaciones típicas, pueden existir archivos como readme.html, license.txt, etc. Aunque no siempre expongan versión exacta en todos los casos, son objetivos habituales de hardening para reducir señales y exposición innecesaria (y, en general, para reducir superficie de información).

D) Cabeceras HTTP del servidor (banner grabbing)

La exposición de stack y versiones también suele venir de cabeceras como Server o X-Powered-By. MDN documenta X-Powered-By como una cabecera no estándar destinada precisamente a identificar la aplicación o framework que generó la respuesta.
Y OWASP WSTG describe cómo el banner grabbing se basa en examinar cabeceras de respuesta del servidor.

3) Cómo verificamos (checklist de auditoría reproducible)

Verificación rápida (sin herramientas especializadas)

  1. Ver código fuente de la home y páginas internas:
  • buscar generator,
  • buscar ?ver= en assets.
  1. Revisar cabeceras:
curl -I https://su-dominio.tld
  • localizar Server, X-Powered-By u otras señales.
  1. Revisar assets críticos:
  • CSS/JS del tema,
  • CSS/JS de plugins comunes (frecuentemente incluyen ?ver=).

Verificación técnica (orientada a evidencias)

  • Identificar qué recursos contienen ?ver= y si ese valor corresponde a WP, tema o plugin (por rutas y patrones).
  • Confirmar si existe wp_generator o generator tags adicionales.
  • Confirmar si el servidor devuelve banners/versiones (cabeceras o páginas de error).
  • Confirmar si hay listados de directorio (autoindex) en rutas como /wp-content/uploads/ (no es “versión”, pero sí fingerprinting + hardening).

4) Enfoque correcto: mitigación por prioridades (sin falsa seguridad)

Prioridad 1 — Mantener todo actualizado (control principal)

WordPress es explícito: versiones antiguas no se mantienen con parches, y cuando una vulnerabilidad se corrige, la información para explotarla suele quedar pública, lo que incrementa el riesgo de quedarse atrás.
Esto aplica todavía más a plugins/temas.

Conclusión operativa: la reducción de fingerprinting solo tiene sentido si el mantenimiento está alineado.

Prioridad 2 — Reducir señales innecesarias (control complementario)

Aquí sí trabajamos “lo que se filtra”, pero con dos reglas:

  • no romper cache/ rendimiento por eliminar ?ver= sin alternativa,
  • no confiar en “ocultar” como si fuera un control de seguridad fuerte (WordPress lo enmarca como complemento).

Prioridad 3 — Endurecer perímetro y exposición de stack

  • retirar banners innecesarios (cuando sea posible),
  • minimizar cabeceras de identificación (X-Powered-By),
  • asegurar que errores/stack traces no llegan al cliente.

5) Controles recomendados (con ejemplos y advertencias)

A) Eliminar generator tag (core)

Podemos retirar el generator tag mediante remove_action, que WordPress documenta como función para eliminar callbacks de hooks.

Ejemplo (en functions.php o en un mu-plugin del equipo):

// Eliminar el generator tag de WordPress en <head>
remove_action('wp_head', 'wp_generator');

Nota técnica: la función wp_generator() está documentada como salida del generator y como candidato típico para “remove version number”.

B) Gestionar ?ver= sin romper cache (controlar el parámetro de versión)

Aquí debemos ser estrictos: no recomendamos “borrar ?ver de todo” si no existe estrategia alternativa de cache-busting.

La documentación oficial deja dos opciones limpias para assets propios:

  • establecer ver a un valor controlado (p. ej. filemtime),
  • o establecer ver a null para no incluir versión.

Ejemplo recomendado para assets del tema (cache-busting por mtime):

$css_path = get_stylesheet_directory() . '/assets/app.css';
wp_enqueue_style(
  'theme-app',
  get_stylesheet_directory_uri() . '/assets/app.css',
  [],
  filemtime($css_path)
);

Para plugins/terceros, el control es más delicado: si eliminamos ?ver= de terceros, podemos causar problemas de cache o dificultar depuración. Por eso, proponemos:

  • aplicar el control solo a assets propios,
  • o hacerlo por lista blanca/negra muy concreta.

C) Reducir banners de servidor y framework

  • Revisar Server y X-Powered-By.
  • X-Powered-By está diseñado para identificar framework/aplicación; si no aporta valor operativo, suele ser preferible retirarlo.
  • OWASP WSTG describe cómo el reconocimiento usa precisamente cabeceras/banners para fingerprinting.

D) Tratar archivos públicos innecesarios

Política general:

  • si un archivo no aporta valor público, se bloquea o elimina.
  • se valida que actualizaciones no lo reintroduzcan.

E) Asegurar que “obscurity” no es la única defensa

Lo dejamos explícito: WordPress considera la obscuridad una estrategia primaria poco sólida, aunque admite usos puntuales como complemento.
En nuestro estándar, esto significa: siempre combinamos esta reducción de señales con mantenimiento y controles reales.

6) Checklist de aceptación (para cerrar un hallazgo de fingerprinting)

Consideramos el riesgo de fingerprinting razonablemente mitigado cuando:

  • Core, plugins y tema están bajo política de actualización y revisión de cambios.
  • No se expone generator tag del core (wp_generator) o está justificado.
  • Los assets propios no filtran versiones sensibles; ver está controlado o se usa una estrategia segura.
  • Las cabeceras de identificación (especialmente X-Powered-By) se han revisado y se han minimizado si no aportan valor.
  • No hay exposición innecesaria de archivos informativos públicos (criterio: “si no es necesario para el negocio, se restringe”).

7) Preguntas frecuentes

¿Eliminar la versión evita que nos ataquen?

No. Reduce señal y ruido, pero el control principal sigue siendo: actualización, hardening y defensa por capas. WordPress lo plantea como reducción de riesgo, no seguridad perfecta.

¿Quitar ?ver= es buena práctica?

Depende. WordPress documenta que ver se usa para cache-busting; si lo retiramos sin alternativa, podemos introducir problemas de cache y despliegue. La recomendación profesional es controlarlo (p. ej., filemtime) en assets propios.

¿Qué es lo más “barato” y eficaz?

  • mantener actualizado,
  • retirar generator tag si no hay dependencia,
  • controlar ver en assets propios,
  • minimizar banners (X-Powered-By) si no aporta.