CVE-2025-4396 - WordPress Relevanssi Time-Based Blind SQL Injection Toolkit

Overview

This repository contains a practical research and validation toolkit for CVE-2025-4396, an unauthenticated Time-Based Blind SQL Injection affecting the WordPress Relevanssi plugin through the cats parameter.

The project was built for authorized Purple Team engagements in order to:

• validate exploitability in a controlled manner,
• demonstrate different attacker tradecraft levels,
• measure SOC detection coverage,
• extract a WordPress password hash in a realistic way,
• and automate the offline cracking workflow once the hash has been recovered.

The repository includes:

• a standard extraction script,
• a faster binary-search extraction script,
• and a helper script to prepare and crack the extracted WordPress 6.8+ hash with Hashcat.

Disclaimer
This project is provided for educational, defensive validation, and authorized security testing only.
Do not use it against systems you do not own or do not have explicit written permission to assess.

Test Environnement

• Server : Debian 11
• WordPress 6.9.1,
• Relevanssi plugins 4.24.4 (downloaded from https://wordpress.org/plugins/relevanssi/advanced/),
• POC used from kali linux OS.

---

CVE Description

CVE-2025-4396 is a SQL Injection vulnerability affecting the Relevanssi search functionality in WordPress.

In the tested scenario, the issue is reachable through the search workflow and more specifically through the cats parameter. The vulnerable code path allows attacker-controlled input to influence the SQL query generated by the plugin.

Because the vulnerable endpoint is accessible without prior authentication, the flaw can be exploited by a remote attacker to perform unauthenticated SQL injection.

The practical impact includes:

• database query manipulation,
• Time-Based Blind SQL Injection,
• extraction of sensitive data such as password hashes,
• and, depending on the environment, possible privilege escalation through valid credential recovery.

---

How the Vulnerability Works

Root Cause

The vulnerability exists because user-controlled input from a search-related parameter is not safely handled before being incorporated into a SQL query.

In practice, this means an attacker can inject SQL expressions into the backend query logic and force the database to evaluate additional conditions.

Why It Is Blind

The vulnerability is exploited in blind mode, which means the application does not directly display SQL errors or raw database results.

Instead of reading query output from the page, the attacker asks the database a series of true/false questions and observes one side effect:

• if the condition is true, the database sleeps for a few seconds,
• if the condition is false, the response returns immediately.

Why It Is Time-Based

The exploitation relies on SQL functions such as SLEEP() to create a measurable difference in server response time.

This allows an attacker to infer data without ever seeing it directly.

For example, the attacker can ask questions such as:

• “Is the first character equal to $?”
• “Is the ASCII value of the second character greater than 77?”
• “Do the first N characters match this pattern?”

By repeating this process, the attacker can reconstruct a full hash character by character.

---

How the Exploitation Works

Standard Extraction Logic

The standard approach iterates through a known character set and tests each candidate one by one.

For each position in the target hash:

1. Build a SQL condition targeting one character.
2. Trigger a server delay only if the guess is correct.
3. Measure the response time.
4. Re-send the same request to reduce false positives caused by network jitter.
5. Append the confirmed character to the extracted hash.
6. Move to the next position.

This method is simple and reliable, but relatively slow because it may require many requests per character.

Binary Search Extraction Logic

The faster approach uses binary search on the ASCII value of each character.

Instead of asking:

• “Is the character equal to a?”
• “Is the character equal to b?”
• “Is the character equal to c?”

it asks:

• “Is the ASCII value greater than 79?”
• “Is it greater than 55?”
• “Is it greater than 43?”

This divides the search space in half on every request and reduces the number of HTTP requests dramatically.

Practical Result

The attack allows the operator to extract the user_pass value from wp_users, typically for a chosen WordPress user ID such as:

• 1 for the default administrator,
• or another ID passed on the command line.

In recent WordPress versions, this value may use the new WordPress 6.8+ password pipeline, which combines:

• a pre-hashing stage using HMAC-SHA384,
• Base64 encoding,
• and a final bcrypt hash.

---

Included Scripts

1. CVE_2025_4396.py

This is the standard extraction script.

Purpose :

It performs a classic Time-Based Blind SQL Injection and extracts the target hash character by character using a linear search over a fixed charset.

Key Characteristics :

• simple and easy to understand,
• reliable in stable environments,
• double-verification logic to reduce false positives,
• useful as a baseline for detection engineering and PoC demonstrations.

How It Works :

For each character position:

• it iterates through a predefined character set,
• builds a SQL condition matching a single character,
• waits for the server response,
• and confirms the hit with a second request.

Requirements :

• python3
• requests
• urllib3

Installation :

pip3 install requests urllib3

Usage :

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

This is the binary search edition.

Purpose :

It performs the same extraction objective as the standard script, but replaces the linear character-by-character search with a binary search on ASCII values.

Key Characteristics :

• significantly fewer HTTP requests,
• smaller network footprint,
• still includes a double-check step to prevent false positives.

How It Works :

For each position:

• Define a printable ASCII range.
• Test the midpoint.
• Ask whether the target character is greater than that midpoint.
• Reduce the range accordingly.
• Continue until the exact character is identified.

Requirements :

• python3
• requests
• urllib3

Installation :

pip3 install requests urllib3

Usage :

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

When to Use It :

• the target is confirmed vulnerable,
• latency is stable enough,
• and the goal is to reduce request volume.

---

Offline Hash Cracking Workflow

Once the password hash has been extracted from WordPress, the next step is to crack it offline.

WordPress 6.8+ Hashing Notes. In the tested workflow, the extracted value may look like:

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

For Hashcat, the usable bcrypt portion is:

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

However, this bcrypt is not applied directly to the raw password. WordPress first applies a preprocessing stage:

• PHP-style trim on the candidate password,
• HMAC-SHA384 using the key wp-sha384,
• Base64 encoding of the resulting digest,
• then bcrypt verification.

Why a Pre-Hashing Step Is Needed