CVE-2025-4396 - Kit de Inyección SQL Ciega Basada en Tiempo para WordPress Relevanssi

Resumen

Este repositorio contiene un kit práctico de investigación y validación para CVE-2025-4396, una Inyección SQL Ciega Basada en Tiempo sin autenticación que afecta al plugin Relevanssi de WordPress a través del parámetro cats.

El proyecto fue creado para ejercicios autorizados de Purple Team con el fin de:

• validar la explotabilidad de manera controlada,
• demostrar diferentes niveles de tácticas de atacante,
• medir la cobertura de detección del SOC,
• extraer un hash de contraseña de WordPress de forma realista,
• y automatizar el flujo de descifrado fuera de línea una vez recuperado el hash.

El repositorio incluye:

• un script de extracción estándar,
• un script de extracción más rápido mediante búsqueda binaria,
• y un script auxiliar para preparar y descifrar el hash extraído de WordPress 6.8+ con Hashcat.

Aviso legal
Este proyecto se proporciona únicamente con fines educativos, validación defensiva y pruebas de seguridad autorizadas.
No lo utilice contra sistemas que no posea o para los que no tenga permiso explícito por escrito para evaluar.

Entorno de prueba

• Servidor : Debian 11
• WordPress 6.9.1,
• Plugin Relevanssi 4.24.4 (descargado de https://wordpress.org/plugins/relevanssi/advanced/),
• POC utilizado desde el sistema operativo Kali Linux.

Descripción de CVE

CVE-2025-4396 es una vulnerabilidad de Inyección SQL que afecta a la funcionalidad de búsqueda de Relevanssi en WordPress.

En el escenario probado, el problema es accesible a través del flujo de búsqueda y, más específicamente, a través del parámetro cats. La ruta de código vulnerable permite que la entrada controlada por el atacante influya en la consulta SQL generada por el plugin.

Debido a que el punto final vulnerable es accesible sin autenticación previa, la falla puede ser explotada por un atacante remoto para realizar una inyección SQL sin autenticación.

El impacto práctico incluye:

• manipulación de consultas en la base de datos,
• Inyección SQL Ciega Basada en Tiempo,
• extracción de datos sensibles como hashes de contraseñas,
• y, dependiendo del entorno, posible escalada de privilegios mediante la recuperación de credenciales válidas.

Cómo Funciona la Vulnerabilidad

Causa Raíz

La vulnerabilidad existe porque la entrada controlada por el usuario proveniente de un parámetro relacionado con la búsqueda no se maneja de forma segura antes de incorporarse a una consulta SQL.

En la práctica, esto significa que un atacante puede inyectar expresiones SQL en la lógica de consulta del backend y forzar a la base de datos a evaluar condiciones adicionales.

Por qué es Ciega

La vulnerabilidad se explota en modo ciego, lo que significa que la aplicación no muestra directamente errores SQL ni resultados sin procesar de la base de datos.

En lugar de leer la salida de la consulta desde la página, el atacante le hace a la base de datos una serie de preguntas de verdadero/falso y observa un efecto secundario:

• si la condición es verdadera, la base de datos se duerme durante unos segundos,
• si la condición es falsa, la respuesta regresa inmediatamente.

Por qué se basa en Tiempo

La explotación se basa en funciones SQL como SLEEP() para crear una diferencia medible en el tiempo de respuesta del servidor.

Esto permite a un atacante inferir datos sin verlos directamente.

Por ejemplo, el atacante puede hacer preguntas como:

• "¿El primer carácter es igual a $?"
• "¿El valor ASCII del segundo carácter es mayor que 77?"
• "¿Los primeros N caracteres coinciden con este patrón?"

Al repetir este proceso, el atacante puede reconstruir un hash completo carácter por carácter.

Cómo Funciona la Explotación

Lógica de Extracción Estándar

El enfoque estándar itera a través de un conjunto de caracteres conocido y prueba cada candidato uno por uno.

Para cada posición en el hash objetivo:

1. Construir una condición SQL dirigida a un carácter.
2. Provocar un retardo en el servidor solo si la suposición es correcta.
3. Medir el tiempo de respuesta.
4. Reenviar la misma solicitud para reducir falsos positivos causados por la fluctuación de la red.
5. Agregar el carácter confirmado al hash extraído.
6. Pasar a la siguiente posición.

Este método es simple y confiable, pero relativamente lento porque puede requerir muchas solicitudes por carácter.

Lógica de Extracción por Búsqueda Binaria

El enfoque más rápido utiliza una búsqueda binaria sobre el valor ASCII de cada carácter.

En lugar de preguntar:

• "¿El carácter es igual a a?"
• "¿El carácter es igual a b?"
• "¿El carácter es igual a c?"

pregunta:

• "¿El valor ASCII es mayor que 79?"
• "¿Es mayor que 55?"
• "¿Es mayor que 43?"

Esto divide el espacio de búsqueda a la mitad en cada solicitud y reduce drásticamente el número de peticiones HTTP.

Resultado Práctico

El ataque permite al operador extraer el valor user_pass de wp_users, típicamente para un ID de usuario de WordPress elegido, como:

• 1 para el administrador predeterminado,
• u otro ID pasado por línea de comandos.

En versiones recientes de WordPress, este valor puede usar el nuevo pipeline de contraseñas de WordPress 6.8+, que combina:

• una etapa de pre-hashing usando HMAC-SHA384,
• codificación Base64,
• y un hash final bcrypt.

Scripts Incluidos

1. CVE_2025_4396.py

Este es el script de extracción estándar.

Propósito :

Realiza una Inyección SQL Ciega Basada en Tiempo clásica y extrae el hash objetivo carácter por carácter mediante una búsqueda lineal sobre un conjunto de caracteres fijo.

Características Clave :

• simple y fácil de entender,
• confiable en entornos estables,
• lógica de doble verificación para reducir falsos positivos,
• útil como línea base para ingeniería de detección y demostraciones de PoC.

Cómo Funciona :

Para cada posición de carácter:

• itera a través de un conjunto de caracteres predefinido,
• construye una condición SQL que coincide con un solo carácter,
• espera la respuesta del servidor,
• y confirma el acierto con una segunda solicitud.

Requisitos :

• python3
• requests
• urllib3

Instalación :

pip3 install requests urllib3

Uso :

python3 CVE_2025_4396.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Argumentos :
    -t, --target : URL objetivo vulnerable incluyendo el parámetro inyectable
    -u, --userid : ID de usuario de WordPress al que apuntar
    -s, --sleep : umbral de sueño en segundos
    -v, --verbose : habilita el registro de depuración

2. CVE_2025_4396_Stealth.py

Esta es la edición de búsqueda binaria.

Propósito :

Realiza el mismo objetivo de extracción que el script estándar, pero reemplaza la búsqueda lineal carácter por carácter con una búsqueda binaria sobre valores ASCII.

Características Clave :

• significativamente menos peticiones HTTP,
• huella de red más pequeña,
• todavía incluye un paso de doble verificación para evitar falsos positivos.

Cómo Funciona :

Para cada posición:

• Definir un rango ASCII imprimible.
• Probar el punto medio.
• Preguntar si el carácter objetivo es mayor que ese punto medio.
• Reducir el rango en consecuencia.
• Continuar hasta que se identifique el carácter exacto.

Requisitos :

• python3
• requests
• urllib3

Instalación :

pip3 install requests urllib3

Uso :

python3 CVE_2025_4396_Stealth.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Cuándo Usarlo :

• el objetivo está confirmado como vulnerable,
• la latencia es lo suficientemente estable,
• y el objetivo es reducir el volumen de solicitudes.

Flujo de Descifrado de Hashes Fuera de Línea

Una vez que se ha extraído el hash de contraseña de WordPress, el siguiente paso es descifrarlo fuera de línea.

Notas sobre el Hash en WordPress 6.8+. En el flujo de trabajo probado, el valor extraído puede verse así:

$wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Para Hashcat, la porción bcrypt utilizable es:

$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Sin embargo, este bcrypt no se aplica directamente a la contraseña sin procesar. WordPress primero aplica una etapa de preprocesamiento:

• recorte al estilo PHP de la contraseña candidata,
• HMAC-SHA384 usando la clave wp-sha384,
• codificación Base64 del resumen resultante,
• luego verificación bcrypt.

Por qué se Necesita un Paso de Pre-Hashing

Esto significa que una lista de palabras normal no se puede enviar directamente a Hashcat si se desea reproducir la lógica exacta de WordPress 6.8+.

En su lugar, cada contraseña candidata debe transformarse primero en su representación de pre-hash compatible con WordPress.

El repositorio también incluye un script "auxiliar" que:

• acepta el hash extraído como argumento,
• elimina el prefijo $wp$ cuando sea necesario,
• preprocesa la lista de palabras suministrada,
• genera el diccionario transformado,
• opcionalmente crea un archivo de mapeo,
• lanza Hashcat automáticamente,
• resuelve el pre-hash recuperado de vuelta a la contraseña en texto claro original.

Flujo de Trabajo Típico

Extraer el hash :

• Resultado de ejemplo : $wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Preparar el entorno de descifrado :

• python3
• hashcat y disponible en PATH

Ejecutar Auto_Crack.py :

python3 Auto_Crack.py -H '\$wp\$2y\$10\$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.' -w /usr/share/wordlists/rockyou.txt

Es necesario escapar "$" con "\" -> compatibilidad con bash

Guía de Detección para el SOC

El siguiente contenido de detección puede ser utilizado por los equipos del SOC para identificar intentos de explotación y medir la madurez defensiva.

Detección Sigma

title: Potential Time-Based Blind SQLi (CVE-2025-4396 Relevanssi)
id: 5a8a1c93-5c74-4b5b-a620-8e1c3e41ab5d
status: experimental
description: Detects HTTP GET requests containing typical Time-Based Blind SQL injection payloads often used to exploit CVE-2025-4396 in the WordPress Relevanssi plugin (bypassing comma filters).
author: n3fhara
date: 2026-03-18
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2025-4396
logsource:
    category: webserver
detection:
    selection_endpoint:
        cs-uri-query|contains:
            - 's='
            - 'cats='
            - 'tags='
    selection_payload:
        cs-uri-query|contains:
            - 'SLEEP('
            - 'WAITFOR'
            - 'SUBSTRING('
            - 'ASCII('
            - 'LENGTH('
    selection_bypass_indicators:
        cs-uri-query|contains:
            - 'FROM'
            - 'FOR 1'
            - '*('
    condition: selection_endpoint and selection_payload and selection_bypass_indicators
falsepositives:
    - Highly unlikely. Legitimate search queries should not contain SQL functions.
level: high

Detección Suricata

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET EXPLOIT WordPress Relevanssi SQLi Attempt (CVE-2025-4396)"; flow:established,to_server; content:"GET"; http_method; content:"cats="; http_uri; pcre:"/(cats|tags)=.*(SLEEP|WAITFOR)%28.*(%2A|\*).*SUBSTRING/i"; classtype:web-application-attack; sid:1000001; rev:1; metadata:created_at 2026_03_18, cve CVE_2025_4396;)

Detección SPLUNK

index=web_logs sourcetype=access_combined 
| regex uri_query="(?i)cats=|tags="
| stats count as request_count, avg(response_time) as avg_time, max(response_time) as max_time, dc(uri_query) as unique_payloads by clientip
| where request_count > 20 AND max_time > 2000
| sort - max_time

Detección KQL

url.query : (*cats=* OR *tags=* OR *s=*) AND url.query : (*SLEEP* OR *WAITFOR* OR *SUBSTRING* OR *ASCII*) AND url.query : (*FROM* OR *FOR* OR *%2A*)

Detección EQL

sequence by source.ip with maxspan=1m
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]

Brechas de Detección y Recomendaciones

Las detecciones base anteriores son buenas para explotación no ofuscada, pero se debilitan cuando un operador introduce tácticas más avanzadas.

La visibilidad del SOC se degrada cuando el atacante comienza a usar:

• funciones SQL alternativas en lugar de las obvias,
• ofuscación basada en codificación URL y comentarios,
• volumen reducido de solicitudes mediante búsqueda binaria,
• jitter y temporización lenta y baja,
• rotación de proxies,
• suplantación de navegador.

Ideas Adicionales de Detección para el SOC :

• Detectar tráfico de búsqueda inusualmente lento,
• Monitorear solicitudes al endpoint de búsqueda de WordPress donde:
  • los tiempos de respuesta están repetidamente elevados,
  • el mismo cliente realiza muchas solicitudes de búsqueda,
  • o el mismo endpoint muestra patrones de latencia anormales a lo largo del tiempo.
• Alertar sobre parámetros de búsqueda que contengan operadores codificados,
• Incluso si no se ven palabras clave SQL obvias, parámetros de búsqueda que contengan combinaciones de :
  • operadores de comparación codificados,
  • densidad sospechosa de paréntesis,
  • lógica numérica repetida,
  • o cadenas de consulta fuertemente codificadas en URL.
• Correlacionar por endpoint, no solo por IP de origen,
• Si el atacante rota proxies, la correlación por IP se vuelve débil. La detección también debe centrarse en :
  • acceso repetido al mismo endpoint,
  • respuestas retardadas repetidas,
  • o consultas de búsqueda malformadas repetidas dirigidas a la misma página de WordPress.
• Usar detección conductual de ventana larga :
  • ventanas de 30 minutos,
  • 1 hora,
  • o de varias horas.
• Monitorear consultas lentas en la base de datos

Estructura del Repositorio

.
├── CVE_2025_4396.py
├── CVE_2025_4396_Stealth.py
├── Auto_Crack.py
├── README.md
└── relevanssi.4.24.4.zip

Aviso Legal

Úselo solo en entornos donde tenga autorización explícita para realizar pruebas. Los autores y colaboradores no asumen ninguna responsabilidad por su uso indebido.

Aviso legal
Este proyecto se proporciona únicamente con fines educativos, validación defensiva y pruebas de seguridad autorizadas.
No lo utilice contra sistemas que no posea o para los que no tenga permiso explícito por escrito para evaluar.