Cómo detectar la versión exacta de un plugin de WordPress

Saber qué plugin usa una web es fácil. Saber qué versión exacta es el paso siguiente, y donde casi todos los escáneres se rinden. Pero la información suele estar ahí, si sabes dónde mirar.

Por qué importa la versión

La versión delata cosas serias:

• Si está desactualizada, a veces con vulnerabilidades públicas (CVE). Oportunidad para una auditoría de seguridad.
• Si es una versión Pro (muchos plugins Premium tienen un naming distinto: elementor-pro, wpforms), detecta que el cliente ya paga licencias.
• Si tiene un número menor reciente, sabes que el dueño actualiza con disciplina — útil para segmentar leads.

Método 1: el query string ?ver=

WordPress carga cada asset CSS/JS con un sufijo de cache-busting que suele ser la versión del plugin:

<link rel='stylesheet' href='/wp-content/plugins/wordpress-seo/css/dist/block-editor.css?ver=21.0'>

Ese ?ver=21.0 casi nunca miente. El único caso raro es cuando el tema o un plugin de cache lo sustituye por un hash — entonces pasamos al método 2.

Método 2: el readme.txt del plugin

Cada plugin del repositorio oficial publica un readme.txt en su raíz. En una instalación estándar está servido en:

https://midominio.com/wp-content/plugins/NOMBRE-PLUGIN/readme.txt

Su encabezado contiene la línea que nos interesa:

Stable tag: 21.0
Tested up to: 6.4

Es el mismo readme que ves en wordpress.org, pero servido desde el propio sitio, así que la "Stable tag" refleja lo que el dueño realmente instaló. Con que bajes los readme.txt de los 10 plugins detectados por la REST tienes un mapa completo de versiones.

Método 3: API REST de WordPress

Ya vimos en la guía principal que /wp-json/ lista los namespaces de los plugins. Algunos plugins registran la versión en la descripción del namespace, aunque es menos fiable.

Método 4: changelog público

Cuando tienes dos candidatos (por ejemplo "WPForms 1.8.4" o "1.8.5") puedes desempatar buscando una función específica que se introdujo en una versión concreta:

• Endpoint REST nuevo que no existía en la anterior.
• Clase CSS renombrada entre releases.
• Campo del formulario con nombre distinto.

Trucos que funcionan en 2026

Algunos plugins han empezado a firmar sus archivos para impedir bajarles el readme.txt directamente. En ese caso:

• Mira la cabecera Last-Modified de un CSS del plugin: te da la fecha de actualización, y con eso cruzas al changelog.
• Algunos plugins emiten su versión como comentario CSS (/* WooCommerce 8.4.0 */) al principio del stylesheet compilado.
• En WooCommerce, el endpoint /wp-json/wc/store/v1/cart devuelve un header x-wc-store-api-version.

Automatizarlo

Este es exactamente uno de los detectores que corre QueUsan por defecto. El motor:

1. Llama /wp-json/ para enumerar plugins.
2. Lanza 10-20 requests paralelas a los readme.txt.
3. Fallback al query string ?ver= si el readme devuelve 404.
4. Correlaciona con nuestra base de CVEs para marcar versiones vulnerables.

Errores comunes

• No verificar con dos métodos. El ?ver= puede ser cualquier cosa si lo manipula un plugin de cache. Cruza con el readme siempre que puedas.
• Confiar en versiones de la cabecera X-Generator. Es de WordPress en general, no del plugin.
• Pensar que plugins Premium no se detectan. Plugins como Elementor Pro, WPForms Pro y Divi mantienen sus propias carpetas /wp-content/plugins/elementor-pro/ y sus readme son accesibles cuando el dueño no los blinda (el 90% no lo hace).

Mini-ejercicio

Ábrete https://midominio.com/wp-json/ de cualquier web que uses, copia los namespaces y pídele a QueUsan que correlacione. En segundos tendrás el inventario completo con versiones.

Sigue con: detectar el tema · identificar el hosting.