CVE-2025-5878

Executive Summary

CVE-2025-5878 is a critical vulnerability in the OWASP ESAPI (Enterprise Security API) Java Legacy library, specifically within the Encoder.encodeForSQL interface. This function is designed to provide SQL injection defense, but due to improper neutralization of special elements, it fails to adequately sanitize user input, allowing an attacker to inject malicious SQL code. The vulnerability is remotely exploitable and a proof-of-concept (PoC) has been publicly disclosed, increasing the risk of widespread exploitation. The CVSS score of 7.3 (High) reflects the ease of exploitation and the potential for complete compromise of confidentiality, integrity, and availability. The vendor has responded professionally, releasing version 2.7.0.0 which disables the vulnerable feature by default and updates documentation to warn users of the risks. However, the patch status is marked as UNKNOWN/UNPATCHED in the original data, indicating that while a fix exists, it may not be fully applied or recognized across all distributions.

Supply Chain & Package Security

This vulnerability affects the esapi-java-legacy package, which is a Java library used for security controls in web applications. As a Java package, it is typically distributed via Maven Central or included directly in project dependencies. Organizations using this library in their software supply chain are at risk. The public disclosure of the exploit means that attackers can easily integrate this into automated scanning tools. It is crucial to verify that all dependencies are updated to version 2.7.0.0 or later, and to monitor for any forks or alternative distributions that may not have applied the patch.

CVSS Breakdown & Threat Level

• CVSS Score: 7.3 (High)
• Attack Vector (AV): Network (N) – The attack can be launched remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required; the attack is straightforward.
• Privileges Required (PR): None (N) – No authentication is needed to exploit.
• User Interaction (UI): None (N) – The victim does not need to perform any action.
• Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) – Full database content could be exposed.
• Integrity (I): High (H) – Data can be modified or deleted.
• Availability (A): High (H) – The database or application could be rendered unavailable.

Threat Level: High. The combination of remote exploitability, low complexity, and public PoC makes this a priority for patching.

Deep Dive & Mechanics

The vulnerability lies in the Encoder.encodeForSQL method within the ESAPI Java Legacy library. This method is intended to encode special characters in user input to prevent SQL injection. However, due to improper neutralization, it fails to handle certain edge cases or encoding contexts, allowing an attacker to bypass the defense.

The core issue is that the encoding logic does not account for all possible SQL syntax variations or database-specific quirks. For example, it may not properly escape characters like single quotes (') in certain contexts, or it may double-encode input in a way that still allows injection. The public exploit demonstrates a technique where a crafted input string, when processed by encodeForSQL, still results in a valid SQL injection payload.

The attack is initiated remotely, typically through a web application that uses ESAPI to sanitize user input before constructing SQL queries. An attacker sends a specially crafted request containing malicious SQL code. The application passes this input to encodeForSQL, which fails to neutralize it properly, and the resulting string is concatenated into a SQL query, leading to injection.

Vulnerable vs. Patched Code

Vulnerable Code (pre-2.7.0.0):

// Example of vulnerable usage
String userInput = request.getParameter("username");
String safeInput = ESAPI.encoder().encodeForSQL(new MySQLCodec(), userInput);
String query = "SELECT * FROM users WHERE username = '" + safeInput + "'";
// The above may still be vulnerable if encodeForSQL does not properly handle all cases

Patched Code (2.7.0.0):

// The feature is disabled by default. Attempting to use it triggers a warning.
// Developers are advised to use parameterized queries instead.
// Example of secure approach:
String userInput = request.getParameter("username");
PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE username = ?");
stmt.setString(1, userInput);
ResultSet rs = stmt.executeQuery();

The patch disables the encodeForSQL method by default. Any call to it will log a warning and return the input unchanged, forcing developers to use proper parameterized queries. The documentation has also been updated to clearly state the risks.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A web application using ESAPI Java Legacy < 2.7.0.0.
• The application uses encodeForSQL to sanitize input before building SQL queries.

Exploit Steps:

1. Identify an input field that is processed by encodeForSQL.
2. Craft a payload that bypasses the encoding. For example, using double encoding or database-specific syntax.
3. Submit the payload. The application will construct a SQL query with the unsanitized input.
4. Observe the SQL injection success (e.g., error messages, data exfiltration).

Example Payload (Conceptual):

' OR '1'='1' -- 

If the encoder fails to escape the single quote, this will break out of the string and execute the OR condition.

Lab Setup:

• Use a local Java web application (e.g., a simple servlet) that includes ESAPI 2.6.0.0.
• Set up a MySQL database with a test table.
• Deploy the application and send crafted requests using Burp Suite or curl.

Blue Team (Detection & Defense)

Detection:

• Monitor for warnings in application logs: "WARNING: encodeForSQL is deprecated and disabled."
• Look for SQL errors in database logs that indicate injection attempts.
• Use WAF rules to block common SQL injection patterns.

Defense:

• Immediately upgrade to ESAPI 2.7.0.0 or later.
• Replace all uses of encodeForSQL with parameterized queries (PreparedStatement).
• If upgrade is not possible, implement additional input validation and use a WAF.

Indicators of Compromise (IOCs)

• Network: HTTP requests containing SQL injection patterns (e.g., ' OR, UNION SELECT, --).
• Logs: Application logs showing warnings about encodeForSQL being disabled.
• Database: Unexpected SQL errors, data exfiltration, or unauthorized queries.
• File: Presence of ESAPI jar files with version < 2.7.0.0 (e.g., esapi-2.6.0.0.jar).

Detection Engineering

YARA Rule

rule CVE_2025_5878_ESAPI_SQL_Injection {
    meta:
        description = "Detects ESAPI Java Legacy versions vulnerable to CVE-2025-5878"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-5878"
    strings:
        $esapi_jar = "esapi" nocase
        $version_string = /[0-9]+\.[0-9]+\.[0-9]+/
        $vuln_version = /2\.[0-6]\.[0-9]+/
    condition:
        $esapi_jar and $version_string and $vuln_version
}

Sigma Rule

title: CVE-2025-5878 ESAPI encodeForSQL Warning Detection
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects application log warnings indicating the use of deprecated encodeForSQL method.
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: java
detection:
    selection:
        message: "WARNING: encodeForSQL is deprecated and disabled."
    condition: selection
falsepositives:
    - Legitimate use of the method before upgrade
level: high

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2025-5878 ESAPI SQL Injection Attempt"; flow:to_server,established; content:"encodeForSQL"; nocase; content:"' OR"; distance:0; within:100; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Update to ESAPI Java Legacy version 2.7.0.0 or later. This disables the vulnerable feature by default.
2. Code Review: Search your codebase for any use of encodeForSQL and replace with parameterized queries (PreparedStatement).
3. Log Monitoring: Enable and monitor warnings about the deprecated method to detect any remaining usage.

Long-term Mitigation:

• Adopt a secure coding standard that prohibits dynamic SQL construction.
• Use an ORM (e.g., Hibernate) that inherently uses parameterized queries.
• Implement a Web Application Firewall (WAF) with SQL injection rules.
• Conduct regular security audits and dependency checks.

Workaround (if upgrade is not possible):

• Manually disable the encodeForSQL method by overriding the ESAPI configuration.
• Add additional input validation and escaping before calling encodeForSQL.

Valters IT