CVE-2025-4396 - Toolkit d'injection SQL aveugle basée sur le temps pour WordPress Relevanssi

Vue d'ensemble

Ce dépôt contient un toolkit pratique de recherche et de validation pour CVE-2025-4396, une injection SQL aveugle basée sur le temps non authentifiée affectant le plugin WordPress Relevanssi via le paramètre cats.

Le projet a été conçu pour des engagements Purple Team autorisés afin de :

• valider l'exploitabilité de manière contrôlée,
• démontrer différents niveaux de techniques d'attaquant,
• mesurer la couverture de détection du SOC,
• extraire un hash de mot de passe WordPress de manière réaliste,
• et automatiser le flux de travail de cassage hors ligne une fois le hash récupéré.

Le dépôt comprend :

• un script d'extraction standard,
• un script d'extraction plus rapide par recherche binaire,
• et un script d'assistance pour préparer et casser le hash WordPress 6.8+ extrait avec Hashcat.

Avertissement
Ce projet est fourni uniquement à des fins éducatives, de validation défensive et de tests de sécurité autorisés.
Ne l'utilisez pas contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation écrite explicite d'évaluation.

Environnement de test

• Serveur : Debian 11
• WordPress 6.9.1,
• Plugin Relevanssi 4.24.4 (téléchargé depuis https://wordpress.org/plugins/relevanssi/advanced/),
• PoC utilisé depuis le système d'exploitation Kali Linux.

Description de la CVE

CVE-2025-4396 est une vulnérabilité d'injection SQL affectant la fonctionnalité de recherche Relevanssi dans WordPress.

Dans le scénario testé, le problème est accessible via le flux de recherche et plus précisément via le paramètre cats. Le chemin de code vulnérable permet à une entrée contrôlée par l'attaquant d'influencer la requête SQL générée par le plugin.

Étant donné que le point d'accès vulnérable est accessible sans authentification préalable, la faille peut être exploitée par un attaquant distant pour réaliser une injection SQL non authentifiée.

L'impact pratique comprend :

• la manipulation de requêtes de base de données,
• l'injection SQL aveugle basée sur le temps,
• l'extraction de données sensibles telles que les hashs de mots de passe,
• et, selon l'environnement, une éventuelle élévation de privilèges via la récupération d'identifiants valides.

Comment fonctionne la vulnérabilité

Cause racine

La vulnérabilité existe parce que l'entrée contrôlée par l'utilisateur provenant d'un paramètre lié à la recherche n'est pas traitée de manière sécurisée avant d'être incorporée dans une requête SQL.

En pratique, cela signifie qu'un attaquant peut injecter des expressions SQL dans la logique de requête du backend et forcer la base de données à évaluer des conditions supplémentaires.

Pourquoi elle est aveugle

La vulnérabilité est exploitée en mode aveugle, ce qui signifie que l'application n'affiche pas directement les erreurs SQL ni les résultats bruts de la base de données.

Au lieu de lire la sortie de la requête sur la page, l'attaquant pose à la base de données une série de questions vrai/faux et observe un effet secondaire :

• si la condition est vraie, la base de données dort pendant quelques secondes,
• si la condition est fausse, la réponse revient immédiatement.

Pourquoi elle est basée sur le temps

L'exploitation repose sur des fonctions SQL telles que SLEEP() pour créer une différence mesurable dans le temps de réponse du serveur.

Cela permet à un attaquant de déduire des données sans jamais les voir directement.

Par exemple, l'attaquant peut poser des questions telles que :

• « Le premier caractère est-il égal à $ ? »
• « La valeur ASCII du deuxième caractère est-elle supérieure à 77 ? »
• « Les N premiers caractères correspondent-ils à ce motif ? »

En répétant ce processus, l'attaquant peut reconstruire un hash complet caractère par caractère.

Comment fonctionne l'exploitation

Logique d'extraction standard

L'approche standard parcourt un jeu de caractères connu et teste chaque candidat un par un.

Pour chaque position dans le hash cible :

1. Construire une condition SQL ciblant un caractère.
2. Déclencher un délai serveur uniquement si la supposition est correcte.
3. Mesurer le temps de réponse.
4. Renvoyer la même requête pour réduire les faux positifs causés par la gigue réseau.
5. Ajouter le caractère confirmé au hash extrait.
6. Passer à la position suivante.

Cette méthode est simple et fiable, mais relativement lente car elle peut nécessiter de nombreuses requêtes par caractère.

Logique d'extraction par recherche binaire

L'approche plus rapide utilise la recherche binaire sur la valeur ASCII de chaque caractère.

Au lieu de demander :

• « Le caractère est-il égal à a ? »
• « Le caractère est-il égal à b ? »
• « Le caractère est-il égal à c ? »

elle demande :

• « La valeur ASCII est-elle supérieure à 79 ? »
• « Est-elle supérieure à 55 ? »
• « Est-elle supérieure à 43 ? »

Cela divise l'espace de recherche par deux à chaque requête et réduit considérablement le nombre de requêtes HTTP.

Résultat pratique

L'attaque permet à l'opérateur d'extraire la valeur user_pass de wp_users, généralement pour un ID utilisateur WordPress choisi tel que :

• 1 pour l'administrateur par défaut,
• ou un autre ID passé en ligne de commande.

Dans les versions récentes de WordPress, cette valeur peut utiliser le nouveau pipeline de mots de passe WordPress 6.8+, qui combine :

• une étape de pré-hachage utilisant HMAC-SHA384,
• l'encodage Base64,
• et un hash bcrypt final.

Scripts inclus

1. CVE_2025_4396.py

Il s'agit du script d'extraction standard.

Objectif :

Il effectue une injection SQL aveugle basée sur le temps classique et extrait le hash cible caractère par caractère à l'aide d'une recherche linéaire sur un jeu de caractères fixe.

Caractéristiques clés :

• simple et facile à comprendre,
• fiable dans des environnements stables,
• logique de double vérification pour réduire les faux positifs,
• utile comme référence pour l'ingénierie de détection et les démonstrations de PoC.

Comment ça marche :

Pour chaque position de caractère :

• il parcourt un jeu de caractères prédéfini,
• construit une condition SQL correspondant à un seul caractère,
• attend la réponse du serveur,
• et confirme la correspondance avec une seconde requête.

Prérequis :

• python3
• requests
• urllib3

Installation :

pip3 install requests urllib3

Utilisation :

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

Arguments :
    -t, --target : vulnerable target URL including the injectable parameter
    -u, --userid : WordPress user ID to target
    -s, --sleep : sleep threshold in seconds
    -v, --verbose : enable debug logging

2. CVE_2025_4396_Stealth.py

Il s'agit de l'édition à recherche binaire.

Objectif :

Il poursuit le même objectif d'extraction que le script standard, mais remplace la recherche linéaire caractère par caractère par une recherche binaire sur les valeurs ASCII.

Caractéristiques clés :

• nettement moins de requêtes HTTP,
• empreinte réseau plus réduite,
• inclut toujours une étape de double vérification pour éviter les faux positifs.

Comment ça marche :

Pour chaque position :

• Définir une plage ASCII imprimable.
• Tester le point médian.
• Demander si le caractère cible est supérieur à ce point médian.
• Réduire la plage en conséquence.
• Continuer jusqu'à ce que le caractère exact soit identifié.

Prérequis :

• python3
• requests
• urllib3

Installation :

pip3 install requests urllib3

Utilisation :

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

Quand l'utiliser :

• la cible est confirmée vulnérable,
• la latence est suffisamment stable,
• et l'objectif est de réduire le volume de requêtes.

Flux de travail de cassage de hash hors ligne

Une fois le hash de mot de passe extrait de WordPress, l'étape suivante consiste à le casser hors ligne.

Notes sur le hachage WordPress 6.8+. Dans le flux de travail testé, la valeur extraite peut ressembler à :

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

Pour Hashcat, la partie bcrypt utilisable est :

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

Cependant, ce bcrypt n'est pas appliqué directement au mot de passe brut. WordPress applique d'abord une étape de prétraitement :

• un trim (suppression des espaces en début et fin de chaîne) de style PHP sur le mot de passe candidat,
• HMAC-SHA384 utilisant la clé wp-sha384,
• l'encodage Base64 du condensat résultant,
• puis la vérification bcrypt.

Pourquoi une étape de pré-hachage est nécessaire

Cela signifie qu'une liste de mots normale ne peut pas être envoyée directement à Hashcat si vous voulez reproduire la logique exacte de WordPress 6.8+.

Au lieu de cela, chaque mot de passe candidat doit d'abord être transformé en sa représentation pré-hachée compatible WordPress.

Le dépôt comprend également un script « helper » qui :

• accepte le hash extrait comme argument,
• supprime le préfixe $wp$ si nécessaire,
• prétraite la liste de mots fournie,
• génère le dictionnaire transformé,
• crée facultativement un fichier de correspondance (mapping),
• lance Hashcat automatiquement,
• fait correspondre le pré-hash récupéré au mot de passe en clair d'origine.

Flux de travail type

Extraire le hash :

• Exemple de résultat : $wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Préparer l'environnement de cassage :

• python3
• hashcat disponible dans le PATH

Exécuter Auto_Crack.py :

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

We need to escape "$" with "\" -> bash compatibility

Guide de détection pour le SOC

Le contenu de détection suivant peut être utilisé par les équipes SOC pour identifier les tentatives d'exploitation et mesurer la maturité défensive.

Détection 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

Détection 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;)

Détection 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

Détection 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*)

Détection 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]

Lacunes de détection et recommandations

Les détections de base ci-dessus sont efficaces pour une exploitation non obfusquée, mais elles deviennent moins efficaces lorsqu'un opérateur introduit des techniques plus avancées.

La visibilité du SOC se dégrade lorsque l'attaquant commence à utiliser :

• des fonctions SQL alternatives au lieu de fonctions évidentes,
• l'encodage URL et l'obfuscation à base de commentaires,
• un volume de requêtes réduit grâce à la recherche binaire,
• la gigue et des temporisations lentes et progressives (low-and-slow),
• la rotation de proxys,
• l'usurpation de navigateur.

Idées de détection supplémentaires pour le SOC :

• Détecter un trafic de recherche lent inhabituel,
• Surveiller les requêtes vers le point d'accès de recherche WordPress où :
  • les temps de réponse sont élevés de manière répétée,
  • le même client effectue de nombreuses requêtes de recherche,
  • ou le même point d'accès présente des schémas de latence anormaux au fil du temps.
• Alerter sur les paramètres de recherche contenant des opérateurs encodés,
• Même si les mots-clés SQL évidents ne sont pas visibles, surveiller les paramètres de recherche contenant des combinaisons de :
  • d'opérateurs de comparaison encodés,
  • une densité de parenthèses suspecte,
  • une logique numérique répétée,
  • ou des chaînes de requête fortement encodées en URL.
• Corréler par point d'accès, pas uniquement par IP source,
• Si l'attaquant alterne les proxys, la corrélation par IP devient faible. La détection doit également se concentrer sur :
  • l'accès répété au même point d'accès,
  • les réponses retardées répétées,
  • ou les requêtes de recherche malformées répétées ciblant la même page WordPress.
• Utiliser une détection comportementale sur une longue fenêtre :
  • fenêtres de 30 minutes,
  • 1 heure,
  • ou fenêtres de plusieurs heures.
• Surveiller les requêtes lentes côté base de données

Structure du dépôt

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

Mentions légales

À utiliser uniquement dans des environnements où vous êtes explicitement autorisé à effectuer des tests. Les auteurs et contributeurs déclinent toute responsabilité en cas d'utilisation abusive.

Avertissement
Ce projet est fourni uniquement à des fins éducatives, de validation défensive et de tests de sécurité autorisés.
Ne l'utilisez pas contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation écrite explicite d'évaluation.