CVE-2024-55551: Exasol JDBC Driver RCE Vulnerability

CVE-2024-55551 Overview

CVE-2024-55551 affects the Exasol JDBC driver in versions prior to 24.2.1 released on 2024-12-10. Attackers can inject malicious parameters into the Java Database Connectivity (JDBC) Uniform Resource Locator (URL), which triggers Java Naming and Directory Interface (JNDI) injection when the driver processes the connection string. Successful exploitation can lead to remote code execution on the host running the JDBC client. The flaw is categorized under [CWE-471] (Modification of Assumed-Immutable Data) and is tracked with a network attack vector requiring user interaction.

Critical Impact

A crafted JDBC URL can force the Exasol driver to perform a JNDI lookup against an attacker-controlled endpoint, resulting in arbitrary Java code execution in the context of the connecting application.

Affected Products

• Exasol JDBC Driver versions before 24.2.1
• Applications embedding the vulnerable exasol:jdbc_driver component
• Data integration and analytics tools that accept user-supplied JDBC connection strings targeting Exasol

Discovery Timeline

• 2025-03-19 - CVE-2024-55551 published to the National Vulnerability Database (NVD)
• 2024-12-10 - Exasol releases JDBC driver version 24.2.1 containing the fix
• 2025-09-26 - Last updated in NVD database

Technical Details for CVE-2024-55551

Vulnerability Analysis

The Exasol JDBC driver parses connection URLs and accepts parameters that influence how the driver resolves and binds to backend services. When the driver processes a malicious JDBC URL, it invokes a JNDI lookup using attacker-controlled values. JNDI in Java can resolve references to remote object factories, and when the lookup targets an attacker-hosted Lightweight Directory Access Protocol (LDAP) or Remote Method Invocation (RMI) server, the Java Virtual Machine (JVM) can fetch and instantiate a remote class. This mirrors the exploitation pattern made widely known by Log4Shell, except the entry point here is the JDBC URL parser. The driver does not sufficiently validate or restrict the parameters used during connection establishment, allowing the JNDI subsystem to be invoked against untrusted endpoints. Public technical analysis of this class of attack was presented at Black Hat Europe 2024 in the briefing on Java Authentication and Authorization Service (JAAS) as a novel attack surface.

Root Cause

The driver treats JDBC URL parameters as trusted input and forwards values into JNDI resolution paths. Because JNDI lookups can return object references that trigger class loading, any parameter that reaches a Context.lookup() call becomes a code execution sink. The absence of allowlisting on protocol schemes and lookup targets is the underlying defect, consistent with [CWE-471].

Attack Vector

Exploitation requires that an application pass an attacker-influenced JDBC URL to the Exasol driver. This typically occurs in multi-tenant data tools, low-code platforms, business intelligence connectors, or administrative interfaces where users supply connection strings. The attacker hosts a malicious LDAP or RMI service and embeds a reference to it in the JDBC URL. When the driver connects, the JVM loads and executes the remote payload with the privileges of the host process. The attack complexity is elevated because the target application must pass the crafted URL to the driver, and user interaction is required. Refer to the GitHub Gist security resource and the Black Hat EU 2024 briefing for technical details on JNDI-based JDBC exploitation.

Detection Methods for CVE-2024-55551

Indicators of Compromise

• Outbound LDAP, LDAPS, RMI, or DNS lookups originating from Java processes that load the Exasol JDBC driver
• JDBC connection strings containing suspicious parameter values referencing external hosts or ldap://, rmi://, or iiop:// schemes
• Unexpected child processes spawned by Java application servers shortly after a database connection attempt
• Java class loading events sourced from remote URLs rather than the local classpath

Detection Strategies

• Inventory deployed Exasol JDBC driver versions and flag any instance below 24.2.1 as vulnerable
• Inspect application logs for JDBC URLs that include unusual parameters, encoded payloads, or references to external network endpoints
• Apply egress filtering rules that alert on LDAP, RMI, or IIOP traffic originating from application tiers that should only speak to internal databases

Monitoring Recommendations

• Enable JVM audit logging for JNDI lookups in applications that accept user-supplied connection strings
• Monitor DNS queries from application hosts for newly seen, low-reputation domains correlated with database connection events
• Alert on Java processes invoking shell, scripting, or download utilities such as bash, cmd.exe, powershell.exe, curl, or wget

How to Mitigate CVE-2024-55551

Immediate Actions Required

• Upgrade the Exasol JDBC driver to version 24.2.1 or later across all applications, ETL jobs, and analytics platforms
• Audit all interfaces that accept JDBC URLs from users or external systems and restrict them to a vetted allowlist
• Block outbound LDAP, RMI, and IIOP traffic from systems hosting Java applications that use the driver

Patch Information

Exasol resolved the issue in JDBC driver version 24.2.1, released on 2024-12-10. Distribution details and downloads are documented in the Exasol JDBC Driver Release Notes and the Exasol JDBC Driver Documentation. Rebuild and redeploy any application bundles that ship the driver as a dependency.

Workarounds

• Where immediate patching is not possible, set the JVM property com.sun.jndi.ldap.object.trustURLCodebase=false and the equivalent flag for RMI to prevent remote class loading
• Run Java applications on JDK versions that disable remote codebase loading by default and validate that no overrides re-enable it
• Sanitize and parse JDBC URLs before passing them to the driver, rejecting strings that contain JNDI-related parameters or external schemes
• Isolate database client hosts in network segments that cannot initiate outbound connections to untrusted destinations

# Configuration example: harden the JVM against JNDI-based remote class loading
java \
  -Dcom.sun.jndi.ldap.object.trustURLCodebase=false \
  -Dcom.sun.jndi.rmi.object.trustURLCodebase=false \
  -Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false \
  -jar application.jar