Cómo Eliminar el Rastro de la Versión de WordPress por Código

Es una herencia técnica que WordPress arrastra por inercia desde sus inicios la de «gritar» a los cuatro vientos qué versión exacta está ejecutando el servidor. Aunque la seguridad basada en la oscuridad no debe ser tu única defensa, dejar la versión a la vista es como poner un cartel en tu puerta indicando qué tipo de cerradura tienes; solo sirve para facilitar el trabajo a los atacantes. Ocultar la versión de WordPress es un paso básico de endurecimiento (hardening) que todo desarrollador debería automatizar en sus proyectos.

#Más allá del simple Meta Tag

La mayoría de los tutoriales básicos se limitan a decirte que elimines la etiqueta generator del head. Sin embargo, el rastro de la versión es mucho más profundo: aparece en las URLs de tus archivos CSS y JS como un parámetro ?ver=x.x.x y en el código XML de tus feeds RSS. Esta es una de esas decisiones de arquitectura que chirrían a nivel de ingeniería, ya que el sistema de caché del navegador podría gestionarse de formas mucho más discretas sin comprometer la seguridad del sitio.

#Eliminando el rastro mediante filtros de WordPress

Para lograr una limpieza total, necesitamos atacar tres puntos: los ganchos de la cabecera, los feeds de sindicación y el sistema de encolado de archivos. Cuidado con obsesionarse con el KPI de seguridad si no mantienes el core actualizado; ocultar la versión no te protege si tu código es vulnerable, solo te hace menos visible ante escaneos masivos.

#Configuración en functions.php

Añadir al final del archivo functions.php de tu tema:

/**
 * Limpieza integral de la versión de WordPress.
 * Ataca el head, los feeds y los parámetros de archivos estáticos.
 */

// 1. Elimina la meta etiqueta 'generator' de la cabecera
remove_action('wp_head', 'wp_generator');

// 2. Elimina la versión de los feeds RSS
add_filter('the_generator', '__return_empty_string');

// 3. Elimina la versión de los scripts y estilos encolados
function antigravity_remove_wp_version_strings($src) {
    // Solo eliminamos si el parámetro 'ver' coincide con la versión real de WP
    if (strpos($src, 'ver=' . get_bloginfo('version'))) {
        $src = remove_query_arg('ver', $src);
    }
    return $src;
}
add_filter('script_loader_src', 'antigravity_remove_wp_version_strings', 15);
add_filter('style_loader_src', 'antigravity_remove_wp_version_strings', 15);

#Caso real: Auditoría tras un escaneo masivo de vulnerabilidades

Hace unos meses, mientras monitorizaba un servidor de producción para un cliente, detecté un pico de peticiones 404 en el log de acceso.

Un bot estaba recorriendo sistemáticamente todas las instalaciones de la red buscando el archivo readme.html para identificar versiones específicas de WordPress con un bug de seguridad recién publicado. El síntoma clínico fue un aumento repentino de la carga de CPU debido a miles de peticiones de red simultáneas.

Al principio, en un intento de bloqueo rápido, configuré una regla en .htaccess para denegar el acceso a dicho archivo, pero cometí el error de novato de bloquear también el acceso a recursos públicos por un error de sintaxis en el Regex, dejando el CSS del sitio roto durante unos minutos. Al final, la solución estable fue combinar la limpieza por código que ves arriba con una regla de servidor bien testada.

#El Plan B (Fallback Plan)

Si tras aplicar el código notas que tus archivos CSS o JS antiguos no se actualizan en los navegadores de tus usuarios después de hacer cambios, es porque hemos perdido el sistema de «cache-busting» nativo de WordPress.

Si al guardar los cambios en functions.php el administrador deja de cargar, accede por SFTP y comenta las líneas de los filtros script_loader_src y style_loader_src. Para forzar la actualización de caché sin revelar la versión de WP, puedes pasar una versión manual a cada script mediante la función wp_enqueue_script().

#Cuándo usar / Cuándo NO usar

• Cuándo usar: En cualquier sitio WordPress en producción que quiera reducir su exposición ante ataques automatizados y mantener un código fuente más limpio.
• Cuándo NO usar: En entornos de desarrollo local donde necesitas saber exactamente qué versión manejas o si usas plugins que dependen críticamente del parámetro de versión para evitar conflictos de caché agresivos.

#Pros y Contras

• Pros: Reducción de ataques dirigidos, eliminación de metadatos inútiles y mayor profesionalidad en el código HTML generado.
• Contras: Puede complicar la gestión de caché de archivos estáticos si no se manejan versiones personalizadas para los scripts.

«Ocultar la versión no te hace invulnerable, pero te saca de la lista de objetivos fáciles de los scripts de ‘script kiddies’.»

Para profundizar en las prácticas de seguridad, consulta la guía de Hardening de WordPress o revisa la lista de vulnerabilidades CVE registradas para versiones específicas.