Detectar plugins vulnerables con WPScan antes del exploit

«`html

En pocas palabras: WPScan detecta plugins vulnerables identificando la versión exacta de cada plugin instalado en tu WordPress y cruzándola contra su base de datos, que en 2026 registra 50.773 vulnerabilidades. El escáner te avisa en minutos qué plugin tiene un CVE publicado antes de que un atacante lo explote.

WPScan sirve para detectar plugins vulnerables en WordPress antes de que alguien explote la falla: identificá la versión exacta de cada plugin instalado, cruzala contra una base con más de 50.000 vulnerabilidades documentadas y sabé en minutos qué plugin tiene un CVE publicado que todavía nadie explotó.

WPScan es un escáner de seguridad gratuito y de código abierto, escrito en Ruby, especializado en WordPress. La herramienta pertenece a Automattic (la empresa detrás de WordPress.com) desde 2022 y compara las versiones de tu núcleo, plugins y temas contra una base de datos propia que en 2026 acumula alrededor de 50.773 vulnerabilidades registradas. Su función es anticiparse: encontrar fallas ya divulgadas antes de que un atacante las explote en tu sitio, según el sitio oficial de WPScan.

¿Qué es WPScan y cómo encuentra fallas antes del exploit?

WPScan detecta un plugin vulnerable en dos pasos: primero identifica qué tenés instalado y en qué versión exacta, después contrasta ese inventario contra su base de vulnerabilidades, que se actualiza a diario con avisos públicos, investigaciones propias y reportes de la comunidad. El código está abierto y lo podés auditar en el repositorio oficial del proyecto en GitHub; Kali Linux, por cierto, lo trae preinstalado.

Acá está el punto que importa: entre la divulgación pública de una falla y la llegada del exploit automatizado masivo suele pasar un tiempo, días o semanas. Esa «ventana de oro» es justo donde trabaja WPScan. Un atacante manual necesita horas para darse cuenta de que tu sitio usa la versión afectada; un escaneo tuyo de tres minutos te lo dice antes.

¿Y por qué confiar en ese número de registros? Es el contador que publica la propia base, así que tomalo como orden de magnitud, no como censo auditado. Igual que con cualquier herramienta de seguridad, la pregunta correcta no es cuántos registros tiene sino qué tan rápido incorpora los nuevos.

¿Qué necesito para instalar WPScan en 2026?

Los requisitos son mínimos: un entorno Linux o macOS (Windows entra vía WSL2 o Docker Desktop), una versión de Ruby mantenida si instalás por gemas (verificá el mínimo vigente en la gemspec del proyecto), y nada más. Todo lo pesado vive del lado del servidor de la API, no del tuyo.

• Sistema operativo: Debian, Ubuntu, macOS, o Windows mediante WSL2 o Docker Desktop.
• Ruby: una versión mantenida (el mínimo exacto figura en la gemspec oficial), junto con ruby-dev, libcurl4-openssl-dev y make si elegís la instalación clásica por RubyGems.
• Docker: la alternativa que recomiendo; aislás dependencias y actualizás con un solo pull.
• Acceso al sitio: una URL alcanzable desde tu máquina; si el wp-login está protegido, credenciales para pruebas opcionales.
• Autorización: escaneá únicamente sitios propios o con permiso expreso del dueño. Sin excepciones.

Ese último punto va en serio. Un escaneo no autorizado puede configurar delito en varios países, aunque no rompas nada técnico. Si trabajás para un cliente, pedilo por escrito.

¿Cómo se instala WPScan: Docker o RubyGems?

Hay dos caminos válidos. Docker es el más simple y el que menos dolores de cabeza da; RubyGems conviene si ya administrás un servidor con Ruby o querés integrarlo en scripts sin capa extra. Relacionado: qué escáner encuentra más CVEs.

Instalación con Docker (recomendada)

docker pull wpscanteam/wpscan
docker run -it --rm wpscanteam/wpscan --url https://tusitio.com

Listo, eso es todo. Cada vez que quieras la base al día, repetís el pull y tenés la imagen fresca. Sin dependencias locales, sin compilaciones fallidas, sin sorpresas.

Instalación con RubyGems en Debian

sudo apt install ruby-full ruby-dev libcurl4-openssl-dev make
gem install wpscan
wpscan --update

Si alguna vez compilaste software en Linux, ya imaginás lo que viene: corré gem install wpscan, te tira un error de extensiones nativas, instalás ruby-dev, volvés a compilar y la instalación vuelve a fallar porque falta libcurl4-openssl-dev, agregás el paquete, recompilás, y recién en el tercer intento la gema compila limpia. La guía de instalación completa de WPScan en Debian 12 de En Guillem documenta ese camino paso a paso si te trabás en algún punto.

Un detalle de permisos: si la gema se instala solo para root, anteponé sudo o usá la opción de instalación por usuario. Y acordate de correr wpscan --update cada tanto, porque la base local necesita refrescarse.

¿Necesito un token de API? Costo y límites del plan gratuito

El token no es obligatorio para escanear, pero sí para ver los datos de vulnerabilidades: sin él, WPScan enumera plugins, temas y versiones, aunque no te dice cuáles tienen CVE asociado. O sea, ves el inventario pero no el diagnóstico.

Conseguirlo toma dos minutos: creás una cuenta en wpscan.com, el token aparece en tu página de perfil, y lo pasás al escáner con --api-token o lo guardás en un alias de shell para no escribirlo cada vez.

• Plan gratuito: 25 consultas a la API por día, según la documentación oficial de la API, consultada el 2026-08-24.
• Consumo real: cada componente enumerado que se contrasta con la base gasta consultas, así que un escaneo completo agresivo puede quemar varias de golpe.
• Traducción práctica: alcanza justo para un escaneo profundo diario de un sitio, o para varios sitios con escaneos livianos.
• Planes pagos: existen para agencias con muchos clientes y necesitan cupos mayores; los precios varían, así que fijate en la web oficial.

Ojo con esto: si estás probando comandos a lo loco un martes, el jueves no vas a tener cupo cuando lo necesites de verdad. Planificá.

¿Qué comandos uso para detectar plugins vulnerables con WPScan?

Para detectar plugins vulnerables con WPScan, el comando central es wpscan --url TU_SITIO -e vp --api-token TU_TOKEN: la opción -e vp (enumerar plugins vulnerables) filtra la salida para mostrar únicamente los componentes con falla confirmada en la base.

# Escaneo básico: versión de WordPress, headers, temas visibles
wpscan --url https://blog.tld

# Todos los plugins detectados
wpscan --url https://blog.tld -e ap

# Solo plugins con vulnerabilidad conocida (requiere token)
wpscan --url https://blog.tld -e vp --api-token ABC123

# Usuarios expuestos y carpetas de backup
wpscan --url https://blog.tld -e u -e bf

• –url: el punto de partida; define qué sitio escaneás.
• -e ap: enumera todos los plugins que pueda identificar, vulnerables o no.
• -e vp: la joyita; devuelve únicamente los que tienen CVE registrado, con su referencia y versión corregida.
• -e u: lista usernames expuestos, útil para saber si facilitás los ataques de fuerza bruta.
• -e bf: busca carpetas de backup accesibles, otro clásico descuidado.
• –api-token: habilita la capa de datos de vulnerabilidades.

La salida marca hallazgos con [+] y alertas con [!]. Si ejecutás sin token, van a aparecer los primeros y nunca los segundos, y uno podría malinterpretar eso como «no hay problemas». Hay que leerlo bien. Tema relacionado: si un solo firewall alcanza.

¿Cómo interpreto los resultados del escaneo de WPScan?

La salida se lee como un informe de arriba hacia abajo: primero lo que encontró (versión del núcleo, temas, plugins con su número de versión), después las alertas, cada una con identificador CVE, score CVSS y la versión donde el desarrollador publicó el arreglo. Cuando un reporte señala algo como CVE-2026-07409 en Ninja Forms o CVE-2026-3427 en Yoast SEO, cada entrada trae su gravedad y su «Fixed in», que es el campo decisivo.

Ponele que heredaste un WordPress con nueve años de plugins acumulados y nadie sabe qué sigue vivo y qué no. Corrés el escaneo, salen cuatro alertas, y la pregunta pasa a ser por dónde arrancar. Para eso está el score CVSS:

Score CVSS	Severidad	Plazo de acción	Movimiento típico
9.0 a 10.0	Crítica	El mismo día	Desactivar o parchear de inmediato
7.0 a 8.9	Alta	Dentro de 48 horas	Actualizar en staging y pasar a producción
4.0 a 6.9	Media	Esta semana	Programar la actualización
0.1 a 3.9	Baja	Próxima ventana	Anotarlo en el backlog

Si el resultado viene vacío de alertas, no celebres todavía: verificá que el token haya funcionado y que el modo de detección haya podido ver tus plugins. Un escaneo silencioso por bloqueo del firewall se parece mucho a un sitio sano.

¿Qué hago si WPScan encuentra un plugin vulnerable?

La respuesta corta: priorizá por CVSS y seguí este orden. Primero mirá el campo «Fixed in» del reporte; si existe versión parcheada, ese es el camino rápido. Después actuá así:

1. Buscá la actualización en el admin: Escritorio, Actualizaciones. Si el parche existe, es cuestión de clics.
2. Probala en staging antes: sobre todo en WooCommerce o formularios, donde una actualización rota flujos de venta sin avisar.
3. Sin parche disponible, buscá reemplazo: casi siempre hay un plugin mantenido que hace lo mismo.
4. Ni parche ni reemplazo razonable: desactivá y borrá. Un plugin muerto pero activo es una puerta abierta con carteles de «pasen».

Regla extraída de años de limpiar sitios ajenos: un plugin sin actualizaciones durante seis meses o más hay que tratarlo como riesgo, tenga o no CVE hoy. El abandono es el mejor predictor de la próxima vulnerabilidad.

¿Revisa también temas y el núcleo de WordPress?

Sí, la misma base cubre los tres frentes. Con -e at enumerás todos los temas y con -e vt solo los vulnerables, igual que hiciste con plugins. La versión del núcleo se detecta en el escaneo básico y se contrasta contra los avisos de seguridad de WordPress.org. Si usás un tema hijo o un theme premium poco difundido, los resultados pueden venir más pobres, porque la huella digital es más difícil de confirmar desde afuera. Para más detalles técnicos, mirá configurar las cabeceras HTTP de seguridad.

¿Cómo escaneo en modo pasivo sin que el firewall me bloquee?

La opción --detection-mode passive reduce los pedidos al servidor al mínimo: WPScan deduce versiones solo con lo que tu HTML ya publica, sin sondear rutas de plugins una por una. Sumale --random-user-agent para rotar el identificador de navegador.

¿Cuándo importa esto? Cuando el sitio corre con Wordfence u otro firewall que corta la «enumeración agresiva» al detectar cientos de pedidos seguidos. El modo pasivo baja el ruido y evita bloqueos temporales de tu IP.

Eso sí, no es «invisibilidad total». El modo pasivo no ve plugins que el frontend no menciona en ningún lado, así que puede devolver una lista más corta que la real. ¿Y qué parece una lista corta de plugins? Buenas noticias falsas. Contrasta siempre con la lista del panel de administración.

¿Con qué otras herramientas conviene combinar WPScan?

WPScan cubre la detección externa; para defensa completa sumale un firewall de aplicación y monitoreo interno. Ninguna herramienta sola cubre el 100%, y quien te diga lo contrario está vendiendo algo. Según el análisis de Axarnet sobre detección de plugins vulnerables en WordPress, la combinación de escáner externo y protección en el servidor es el enfoque que mejor funciona en la práctica.

Herramienta	Tipo	Fortaleza principal	Límite
WPScan	CLI externa	Base CVE específica de WordPress con detalle por versión	25 consultas diarias en el plan gratis
Wordfence	Plugin + firewall	Bloqueo de exploits en tiempo real dentro del sitio	Consume recursos del propio servidor
Sucuri Security	Plugin + monitoreo	Integridad de archivos y alertas de blacklists	Escaneo remoto superficial frente a WPScan
WPVulnerability	Plugin liviano	Consulta automática de CVEs desde el admin	Sin enumeración profunda desde afuera
Patchstack	SaaS de vulnerabilidades	Alertas tempranas y parcheo virtual	Lo útil está en planes de pago

¿Y los escáneres generales tipo OpenVAS o Nuclei? Sirven para la infraestructura completa del servidor, pero ninguno llega al nivel de detalle por versión de plugin que tiene WPScan. Son capas distintas del mismo problema.

¿Cómo automatizo escaneos semanales con cron?

Un cron semanal resuelve el 90% del trabajo operativo: lunes a las 7 de la mañana, escaneo con token, resultado al log. La línea queda así:

0 7 * * 1 docker run --rm wpscanteam/wpscan \
 --url https://tusitio.com -e vp \
 --api-token "$WPSCAN_TOKEN" >> /var/log/wpscan.log 2>&1

• Guardá el token fuera del crontab: en una variable de entorno o archivo con permisos 600, no en texto plano en la tabla de tareas.
• Escaneá desde otra máquina: correrlo desde el mismo servidor te da una perspectiva distinta a la de un atacante externo.
• Repartí el cupo: si administrás varios sitios sobre un VPS, como los servidores virtuales de DonWeb, concentrá los escaneos ahí y distribuí las 25 consultas diarias entre los proyectos.

El resto es rutina: leés el log los lunes, actuás según la tabla de CVSS de arriba, y dormís un poco mejor. Más contexto en endurecer tu WordPress con Patchstack.

Errores comunes al usar WPScan (y cómo evitarlos)

• Escanear con la base desactualizada: si tu imagen Docker o tu instalación local lleva semanas sin refrescar, te perdés los CVE nuevos. Solución: docker pull wpscanteam/wpscan o wpscan --update antes de cada ciclo semanal.
• Leer «sin resultados» como «sitio seguro»: el modo pasivo más un firewall hostil producen falsos negativos elegantes. Contrastá siempre con la lista de plugins del admin.
• Quemar el cupón de 25 consultas en pruebas: cada experimento con -e ap gasta requests. Dejá el escaneo completo para el cron y reservá consultas para verificaciones puntuales.
• Enumeración agresiva en horario pico: cientos de pedidos simultáneos pueden disparar bloqueos del WAF o degradar la experiencia de visitantes reales. Programá de madrugada.

Preguntas Frecuentes

¿Cuánto cuesta usar WPScan para detectar vulnerabilidades?

La herramienta de línea de comandos es gratuita y de código abierto. El plan gratuito de la API incluye 25 consultas por día (documentación oficial consultada el 2026-08-24), suficiente para un escaneo completo diario de un sitio; los planes pagos amplían el cupo para agencias con decenas de clientes.

¿Es legal escanear un sitio de WordPress que no es mío?

Solo con autorización expresa del dueño. Sin permiso, un escaneo puede configurar infracción penal según la legislación local y violar los términos de servicio de cualquier hosting, aunque técnicamente no cause daño.

¿WPScan detecta fallas de día cero?

No. Su base registra vulnerabilidades ya divulgadas públicamente; una falla sin parche y sin aviso no figura hasta que alguien la reporta. Por eso el escáner se combina con un WAF que bloquea patrones de ataque desconocidos.

¿Funciona WPScan en Windows?

Sí, mediante Docker Desktop o WSL2. La instalación nativa de Ruby sobre Windows existe pero complica las dependencias nativas de compilación; el contenedor evita todo ese trabajo.

¿Cada cuánto conviene escanear mi sitio?

Una vez por semana como mínimo, y siempre después de instalar o actualizar un plugin. Si aparece un aviso CVE relevante para un componente que usás, escaneá ese mismo día.

Conclusión

Lo que cambió en 2026 no es la herramienta sino el margen de error: con más de 50.000 vulnerabilidades documentadas y exploits automatizados circulando horas después de cada divulgación, enterarte del problema leyendo un blog de noticias ya no es estrategia. WPScan te da la detección barata, programable y específica para WordPress que faltaba en tu rutina.

El plan concreto: registrá el token hoy, montá el contenedor Docker, corré tu primer -e vp y programá el cron del lunes. Después, disciplina: parchear en staging, reemplazar lo abandonado y borrar lo que no tenga arreglo. Tres hábitos, quince minutos por semana, y la brecha entre divulgación y explotación deja de ser tu problema.

Fuentes

• WPScan – Sitio oficial del escáner y base de datos de vulnerabilidades
• WPScan API – Documentación oficial del token y límites del plan gratuito
• GitHub wpscanteam/wpscan – Repositorio de código fuente del proyecto
• En Guillem – Guía completa de instalación de WPScan en Debian 12
• Axarnet – Artículo sobre detección de plugins vulnerables en WordPress