¿Publicás tu WordPress sin pentest? WPScan te salva

Actualizado el 26/03/2026: WPScan incorporó capacidades para evadir Web Application Firewalls (WAF) durante el escaneo, lo que cambia el alcance real de las auditorías y pone en cuestión cómo venían usando la herramienta muchos equipos de seguridad.

WPScan es un escáner de vulnerabilidades open source especializado en WordPress, mantenido por Automattic, que permite auditar plugins, temas y configuraciones antes de poner un sitio en producción. Usarlo como parte de un pentest pre-lanzamiento reduce drásticamente el riesgo de que tu sitio sea comprometido en las primeras horas online, cuando los bots automatizados ya están escaneando.

Qué es WPScan y por qué importa para la seguridad de WordPress

WPScan fue creado en 2011 por Ryan Dewhurst y hoy lo mantiene la comunidad de seguridad con respaldo de Automattic. Está escrito en Ruby, viene preinstalado en Kali Linux, y apunta a un problema muy concreto: WordPress representa el 43% de todos los sitios web activos según W3Techs, lo que lo convierte en el blanco más grande y consistente de ataques automatizados.

La lógica es simple: si vos no escaneás tu sitio antes de lanzarlo, alguien más lo va a hacer por vos. Los bots automatizados rastrean rangos de IP y dominios nuevos buscando instalaciones de WordPress con plugins vulnerables. Según datos de Patchstack, en 2025 se registraron más de 5 millones de intentos de explotación solo contra plugins con vulnerabilidades conocidas.

El problema es que muchos equipos tratan la seguridad como algo que se revisa «después del lanzamiento». Primero diseñan, desarrollan, instalan 15 plugins, configuran WooCommerce, suben contenido, y recién ahí piensan en seguridad. Para ese momento, el sitio ya lleva días online con plugins sin parchear.

Un pentest pre-lanzamiento con WPScan invierte esa lógica. Escaneás en staging, identificás vulnerabilidades, corregís antes de salir, y lanzás con una superficie de ataque reducida. No es infalible, pero te saca del grupo de blancos fáciles.

Cómo instalar WPScan: Docker, RubyGems y Kali Linux

Hay tres formas de tener WPScan funcionando. Cada una tiene su contexto ideal.

Docker es la opción más limpia si no querés lidiar con dependencias de Ruby en tu sistema. Dos comandos y listo:

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

La ventaja de Docker es el aislamiento: corrés el escáner sin instalar nada en el sistema base, y cuando terminás, el contenedor desaparece. Ideal para entornos de CI/CD o máquinas compartidas.

RubyGems es la instalación directa. En Ubuntu o Debian primero necesitás las dependencias:

sudo apt install ruby ruby-dev libcurl4-openssl-dev -y
gem install wpscan

En macOS con Homebrew es más directo todavía, sin necesidad de instalar dependencias manualmente.

Kali Linux ya lo trae preinstalado. Si estás en otra distro basada en Debian, lo instalás con:

sudo apt install wpscan -y

Para la mayoría de los equipos que ya trabajan con Kali para pentesting, esta es la opción natural. El proceso de instalación completo está documentado en detalle acá.

Configuración inicial: API Token y base de datos de vulnerabilidades

WPScan puede detectar componentes sin API token, pero sin él no sabe si esos componentes tienen vulnerabilidades conocidas. La diferencia es enorme: es como hacer un inventario de medicamentos sin saber cuáles están vencidos. Te puede servir nuestra cobertura de comparativa entre firewalls perimetrales y microsegmentación.

El registro es gratuito en wpscan.com. Una vez que tenés el token, lo configurás con:

export WPSCAN_API_TOKEN="tu_token_aquí"

O lo pasás directamente en cada comando con --api-token TU_TOKEN. El tier gratuito da 25 requests diarios, que alcanzan para auditar un sitio completo sin problema.

La base de datos se aloja en wpscan.com y se actualiza continuamente. Antes de cada escaneo importante, conviene forzar una actualización:

wpscan --update

Saltarse ese paso es uno de los errores más comunes: escaneás con una base de datos desactualizada y te perdés vulnerabilidades reportadas en los últimos días.

Cómo funciona WPScan: lo que escanea y cómo interpretarlo

El comando básico es directo:

wpscan --url https://ejemplo.com

WPScan busca la versión del core, plugins y temas activos, usuarios enumerables, archivos de configuración visibles, y cruza todo contra su base de datos. En una instalación real, la salida puede mostrar algo así: WordPress 6.3.1 con vulnerabilidades conocidas, plugin Contact Form 7 versión 5.8 con un CVE activo, y dos usuarios enumerables por la API REST.

Los flags de enumeración son clave para un pentest serio:

• --enumerate vp: plugins con vulnerabilidades conocidas. El vector de ataque más frecuente — el 90% de los problemas en WordPress vienen por acá.
• --enumerate ap: todos los plugins instalados, incluyendo los que no tienen CVEs reportados pero podrían tener configuraciones inseguras.
• --enumerate vt: temas vulnerables. Menos frecuente como vector, pero no irrelevante.
• --enumerate u: usuarios registrados. Si WPScan los puede listar, un atacante también. Es el primer paso para un ataque de fuerza bruta.

Un escaneo completo se vería así:

wpscan --url https://tu-sitio.com --enumerate vp,vt,u --api-token TU_TOKEN

Algo a tener en cuenta: que WPScan no encuentre usuarios no significa necesariamente que el sitio esté bien configurado. Puede haber usuarios con visibilidad restringida que no se exponen por las rutas estándar pero sí por otras vías.

Pentest pre-lanzamiento paso a paso

Para sitios corporativos o blogs

Si tu sitio es un blog o sitio institucional sin ecommerce, el pentest puede ser más acotado. Escaneás plugins vulnerables y usuarios, verificás que xmlrpc.php esté deshabilitado (WPScan lo reporta si está activo), y revisás que el listado de directorios esté bloqueado. Con eso cubrís los vectores más comunes.

Ejemplo concreto: un equipo lanzó un blog corporativo con Contact Form 7 en versión 5.3.1, que tenía una vulnerabilidad de upload arbitrario (CVE-2020-35489). WPScan lo detectó en staging, actualizaron antes de salir a producción, y evitaron que el formulario de contacto se convirtiera en una puerta de entrada para webshells.

Para tiendas WooCommerce

Acá la auditoría tiene que ser más profunda. WooCommerce maneja datos de pago, direcciones y sesiones de usuario. Además de los escaneos estándar, revisá los endpoints de la REST API con --enumerate ap para detectar plugins que exponen endpoints sin autenticación. Prestá especial atención a plugins de pasarela de pago y extensiones de terceros fuera del repositorio oficial.

WPScan cubre lo conocido. Las vulnerabilidades zero-day o las configuraciones inseguras personalizadas requieren revisión manual. Eso no es una crítica a la herramienta, es el límite real de cualquier escáner automatizado. Sobre eso hablamos en nuestra guía sobre plugins gratuitos de WordPress.

Para sitios en hosting compartido

En hosting compartido el riesgo se multiplica porque un vecino comprometido puede afectar tu sitio. Sumá al escaneo una verificación de permisos de archivos (wp-config.php debe ser 400 o 440) y asegurate de que el servidor no exponga el debug.log. Si necesitás aislamiento real entre cuentas y soporte técnico que entienda WordPress, Donweb ofrece planes específicos para el mercado latinoamericano con ese nivel de seguridad a nivel servidor.

Capacidades avanzadas: configuración insegura, fuerza bruta y detección de exposiciones

Más allá de plugins y temas, WPScan identifica una serie de malas configuraciones que pasan desapercibidas pero son puertas de entrada reales:

• Listados de directorios abiertos en /wp-content/uploads/ o similares, que permiten a cualquiera ver qué archivos subiste.
• Archivos de log de debug accesibles públicamente (wp-content/debug.log). Es sorprendente cuántos sitios en producción tienen esto habilitado y expuesto.
• Archivos sensibles como readme.html o license.txt que revelan la versión exacta del core, facilitando ataques dirigidos.
• Software desactualizado en cualquier capa: core, plugins o temas. WPScan los compara contra su base de datos y reporta qué versión es la actual.

WPScan también incluye funciones de prueba de fuerza bruta contra el formulario de login. La idea no es atacar el sitio sino verificar si las contraseñas configuradas resisten un ataque de diccionario básico. Esto es especialmente útil cuando auditás un sitio con múltiples colaboradores, donde la política de contraseñas puede ser laxa.

Lo interesante es que estas funciones combinadas dan un panorama bastante completo sin necesidad de herramientas adicionales para un pentest de nivel medio. Para auditorías más profundas que incluyan análisis de código o pruebas de lógica de negocio, WPScan es el punto de partida, no el destino final.

WPScan ahora puede superar firewalls de aplicaciones web (WAF): qué cambia esto para el escáner de vulnerabilidades WordPress

Esta es la novedad concreta. WPScan desarrolló capacidades para evadir Web Application Firewalls durante el escaneo, y eso cambia bastante la conversación sobre qué tan útil es la herramienta para pentesting real.

El problema de fondo era este: muchos sitios WordPress usan un WAF — ya sea a través de Cloudflare, Sucuri, o el que ofrece directamente su hosting. Cuando WPScan intentaba escanear esos sitios, el WAF detectaba el tráfico de reconocimiento y lo bloqueaba. El resultado era un informe que decía «no se encontraron vulnerabilidades» no porque el sitio fuera seguro, sino porque el escáner nunca llegó a ver el sitio real. Una diferencia importante.

Para pentesting legítimo, eso es un problema serio. Si el escáner no puede pasar el WAF, el informe subestima las vulnerabilidades reales. Un atacante con algo más de paciencia y herramientas puede evadir ese mismo WAF y acceder a lo que el escaneo automatizado no pudo ver. El resultado es una falsa sensación de seguridad basada en un reporte incompleto.

Con la capacidad de evasión de WAF, el escáner puede operar de forma más similar a como lo haría un atacante real. Eso hace que los resultados sean más representativos y que los informes de auditoría reflejen mejor el estado real del sitio.

Habría que ver en detalle cómo implementaron la evasión — las técnicas varían mucho en efectividad según el WAF que enfrenten — pero el principio es correcto. Un escáner que no puede pasar el WAF no puede auditar el sitio de verdad.

Lo que no queda del todo claro es si esta capacidad está disponible en el tier gratuito de la API o si requiere una cuenta paga. Tampoco está documentado públicamente qué WAFs específicos se pueden evadir y cuáles no. Tomalo con pinzas hasta que haya más documentación técnica disponible.

Qué está confirmado y qué todavía no está confirmado

WPScan CLI vs Jetpack Protect: qué cambió en 2026

En 2026 Automattic discontinuó el plugin WPScan para WordPress en su versión gratuita y lo integró dentro de Jetpack Protect. La herramienta CLI sigue activa, open source, y recibiendo actualizaciones. Lo que cambió es el modelo de distribución.

Para pentesting pre-lanzamiento, la CLI sigue siendo la opción correcta. Jetpack Protect está pensado para monitoreo continuo post-lanzamiento: te avisa si aparece una nueva vulnerabilidad en un plugin que ya tenés instalado. Son complementarios, no sustitutos. Cubrimos ese tema en detalle en los parches críticos de Windows para AWS.

La tabla siguiente resume las diferencias clave:

Muchos administradores de WordPress que usaban el plugin WPScan como única herramienta de seguridad se quedaron sin escaneo cuando lo desactivaron, sin saber que la CLI seguía disponible. Si estás en esa situación, la solución es sencilla: instalá la CLI y retomá desde ahí.

Errores comunes al usar WPScan y cómo evitarlos

No configurar el API token. Sin token, WPScan detecta componentes pero no sabe si tienen vulnerabilidades. Es como hacer un inventario sin saber qué está vencido. El registro gratuito en wpscan.com tarda dos minutos.

No actualizar la base de datos antes de escanear. Si saltás el wpscan --update antes de una auditoría importante, podés estar trabajando con datos que tienen días o semanas de retraso. En seguridad, una semana es mucho tiempo.

Confundir ausencia de usuarios enumerados con seguridad total. Que WPScan no encuentre usuarios no significa que no existan. Puede haber usuarios con visibilidad restringida que se exponen por otras rutas no cubiertas por el escaneo estándar.

Confiar solo en el resultado automatizado sin validación manual. WPScan puede reportar falsos positivos — por ejemplo, marcar un plugin como vulnerable cuando ya se aplicó un parche que no cambió el número de versión. También puede dar falsos negativos si un plugin custom no está en su base de datos. El escaneo automatizado es el punto de partida, no el veredicto final.

Escanear sitios de terceros sin autorización escrita. WPScan puede generar tráfico que dispare alertas en el WAF o en el hosting. Sin un documento que respalde tu trabajo, podés terminar con el sitio bloqueado o algo peor. En Argentina no hay legislación específica de pentest, pero eso no te protege si el cliente o el proveedor de hosting interpreta el escaneo como un ataque.

Qué significa para equipos y empresas en Latinoamérica

La mayoría de los sitios WordPress en la región usan algún nivel de protección WAF, ya sea a través de Cloudflare en su plan gratuito, o el WAF que incluye el hosting. Hasta ahora, eso creaba un punto ciego en las auditorías: el escáner veía el WAF, no el sitio real detrás.

Con la evasión de WAF, los equipos de seguridad y los desarrolladores que hacen sus propias auditorías van a poder obtener resultados más completos sin necesidad de herramientas adicionales. Para agencias que manejan múltiples sitios de clientes, eso es una diferencia práctica concreta.

El tema es que también implica una responsabilidad mayor. Un escáner que puede evadir WAFs es más potente, y eso hace que la regla de «autorización escrita siempre» sea todavía más relevante. Usarlo en sitios propios o en auditorías formales con contrato: perfecto. Usarlo en sitios ajenos sin permiso: es la definición de acceso no autorizado, independientemente de la intención. Para más detalles técnicos, mirá el reciente hackeo de Trivy en GitHub Actions.

Para equipos que ya usaban WPScan regularmente, la actualización no cambia el flujo de trabajo. Simplemente los resultados van a ser más precisos. Para los que nunca lo usaron porque «el WAF ya protege el sitio», esta es una buena oportunidad para entender que el WAF y el escaneo de vulnerabilidades son capas distintas que se complementan, no se reemplazan.

Esto se conecta con Built a WordPress scanner that gets past WAFs, donde cubrimos las protecciones avanzadas.

Preguntas Frecuentes

¿WPScan puede evadir cualquier WAF o solo algunos?

Por ahora no hay documentación pública con la lista específica de WAFs que WPScan puede evadir. La funcionalidad fue anunciada pero los detalles técnicos de implementación no están disponibles. Habría que probarla contra el WAF específico que uses para saber si aplica a tu caso.

¿La evasión de WAF está disponible en el plan gratuito de la API?

No está confirmado. WPScan ofrece un tier gratuito con 25 requests diarios y tiers pagos con mayor capacidad. No hay información pública todavía sobre si la evasión de WAF requiere una suscripción paga o está disponible para todos los usuarios. Revisá la documentación oficial en wpscan.com para confirmar.

¿Qué diferencia hay entre escanear con y sin WAF activo?

Sin evasión de WAF, el escáner puede ser detectado y bloqueado antes de ver el sitio real. El resultado es un informe incompleto que no refleja las vulnerabilidades reales. Con evasión activa, el escáner opera de forma más similar a un atacante real, lo que produce resultados más representativos del estado actual del sitio.

¿Sigue siendo legal usar WPScan con evasión de WAF para auditar sitios de clientes?

Sí, siempre que tengas autorización escrita del propietario del sitio. La evasión de WAF no cambia el marco legal: el pentest autorizado es legítimo, el acceso no autorizado no lo es, con o sin evasión de WAF. Si hacés auditorías para clientes, asegurate de que el contrato incluya explícitamente el alcance del escaneo y las herramientas que vas a usar.

Conclusión

WPScan siempre fue la herramienta estándar para auditar sitios WordPress, pero tenía un límite concreto: los WAFs podían cortarle el paso y hacer que los reportes quedaran incompletos. Con la incorporación de evasión de WAF, ese límite se reduce.

Para equipos que hacen pentesting en serio, esto significa resultados más honestos. Para los que usan WPScan de forma ocasional para revisar sus propios sitios, el impacto práctico va a depender de si tienen un WAF activo y de si la funcionalidad está disponible en el tier gratuito — algo que todavía no está confirmado.

Lo que sí queda claro es que la CLI sigue siendo la herramienta correcta para auditorías pre-lanzamiento, y que la discontinuación del plugin de WordPress no cambió eso. La combinación de WPScan CLI para pentesting puntual y Jetpack Protect para monitoreo continuo sigue siendo el enfoque más sólido para sitios que quieren mantener una postura de seguridad activa.

De acá en adelante, conviene seguir la documentación oficial de WPScan para ver cómo van documentando los detalles técnicos de la evasión de WAF. Cuando esa información esté disponible, va a determinar qué tan útil es la funcionalidad en escenarios reales con Cloudflare, Sucuri o los WAFs de hosting administrado.

Fuentes

• Su Espacio — Cómo instalar y utilizar WPScan: tutorial completo
• Listopro Community — WPScan: la herramienta esencial para analizar sitios WordPress
• Medium / Claudio Drews — WPScan: la navaja suiza para auditar WordPress
• RedTiSeg — Conociendo la herramienta WPScan
• KeepCoding — Qué es WPScan en ciberseguridad