Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2024-55953

CVE-2024-55953: DataEase JDBC Connection SQLi Vulnerability

CVE-2024-55953 is an SQL injection flaw in DataEase that lets authenticated users read and deserialize arbitrary files via JDBC connections. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2024-55953 Overview

DataEase is an open source business analytics tool used to build dashboards and reports from a variety of data sources. CVE-2024-55953 allows authenticated users to read and deserialize arbitrary files through the background JDBC connection configuration. When DataEase constructs the JDBC connection string for MySQL and Redshift data sources, extra parameters supplied by the user are not properly filtered. Attackers can inject dangerous JDBC properties such as autoDeserialize or allowLoadLocalInfile to trigger file reads and Java deserialization gadgets. The issue is fixed in DataEase v1.18.27, and no workarounds are available.

Critical Impact

Authenticated users can leverage a JDBC parameter injection to read arbitrary files from the DataEase server and trigger deserialization of attacker-controlled data, leading to remote code execution.

Affected Products

  • DataEase (dataease:dataease) versions prior to v1.18.27
  • MySQL data source configuration (MysqlConfiguration.java)
  • PostgreSQL / Redshift data source configuration (PgConfiguration.java)

Discovery Timeline

  • 2024-12-18 - CVE-2024-55953 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-55953

Vulnerability Analysis

The vulnerability is a JDBC connection string injection in the DataEase backend. Authenticated users creating or editing a data source can supply free-form text in the extraParams field. That value is concatenated directly into the JDBC URL without adequate normalization. The pre-patch code checked for a blocklist of dangerous keywords against extraParams alone, but the check could be bypassed and did not cover the fully assembled URL. Once the injected JDBC URL is used to open a connection, MySQL Connector/J and the PostgreSQL driver honor properties such as autoDeserialize, queryInterceptors, statementInterceptors, and allowLoadLocalInfile, enabling file exfiltration and unsafe deserialization. This class of issue is tracked under CWE-89 in the advisory but functionally maps to Insecure Deserialization and Arbitrary File Read via JDBC attribute injection.

Root Cause

The root cause lies in MysqlConfiguration.getJdbc() and PgConfiguration.getJdbc(). The blocklist enforcement is performed against the raw extraParams input rather than the final JDBC URL. Attackers can encode, obfuscate, or split parameters so that the substring check fails while the resulting URL still contains dangerous properties like autoDeserialize=true.

Attack Vector

An attacker with authenticated access to the DataEase console configures a MySQL or Redshift data source pointing to a rogue database server they control. They inject JDBC properties into extraParams. When DataEase connects, the malicious server responds with crafted packets that trigger local file reads through allowLoadLocalInfile or serialized Java payloads deserialized by the client driver, yielding code execution on the DataEase host.

java
// Patched logic from MysqlConfiguration.java
// Source: https://github.com/dataease/dataease/commit/0db4872a52eccf6e83dd9359aa05db52dd580ec1
private List<String> illegalParameters = Arrays.asList(
    "autoDeserialize", "queryInterceptors", "statementInterceptors",
    "detectCustomCollations", "allowloadlocalinfile",
    "allowUrlInLocalInfile", "allowLoadLocalInfileInPath");

public String getJdbc() {
    String jdbcUrl = "";
    if (StringUtils.isEmpty(extraParams.trim())) {
        jdbcUrl = "jdbc:mysql://HOSTNAME:PORT/DATABASE"
            .replace("HOSTNAME", getHost().trim())
            .replace("PORT", getPort().toString().trim())
            .replace("DATABASE", getDataBase().trim());
    } else {
        jdbcUrl = "jdbc:mysql://HOSTNAME:PORT/DATABASE?EXTRA_PARAMS"
            .replace("HOSTNAME", getHost().trim())
            .replace("PORT", getPort().toString().trim())
            .replace("DATABASE", getDataBase().trim())
            .replace("EXTRA_PARAMS", getExtraParams().trim());
    }
    // Post-patch: check the fully assembled URL, not just extraParams
    for (String illegalParameter : getIllegalParameters()) {
        if (jdbcUrl.toLowerCase().contains(illegalParameter.toLowerCase())
            || URLDecoder.decode(jdbcUrl).contains(illegalParameter.toLowerCase())) {
            throw new RuntimeException("Illegal parameter: " + illegalParameter);
        }
    }
    return jdbcUrl;
}

Source: DataEase patch commit 0db4872. The fix moves the blocklist validation from the raw extraParams string to the final jdbcUrl, including URL-decoded content, so injected properties cannot slip through.

Detection Methods for CVE-2024-55953

Indicators of Compromise

  • Data source records in DataEase whose extraParams field contains autoDeserialize, queryInterceptors, statementInterceptors, detectCustomCollations, allowLoadLocalInfile, allowUrlInLocalInfile, or allowLoadLocalInfileInPath.
  • Outbound TCP connections from the DataEase server to unexpected MySQL (3306) or PostgreSQL/Redshift (5432) endpoints, especially over the public internet.
  • Java process activity spawning child processes (shells, curl, wget) shortly after a data source is tested or connected.

Detection Strategies

  • Inspect the DataEase database table storing data source definitions for JDBC URLs containing the illegal parameter names listed above, even after URL decoding.
  • Monitor DataEase application logs for RuntimeException: Illegal parameter entries, which indicate blocked exploitation attempts on patched instances.
  • Correlate authenticated DataEase administrative actions (data source create/update) with subsequent outbound database connections to untrusted hosts.

Monitoring Recommendations

  • Egress-filter the DataEase host so it can only reach approved database endpoints, and alert on deviations.
  • Enable EDR telemetry on the DataEase Java process to detect child-process creation and unexpected file reads following a data source test.
  • Review audit logs for accounts creating or modifying data sources, and validate that these actions match approved changes.

How to Mitigate CVE-2024-55953

Immediate Actions Required

  • Upgrade DataEase to v1.18.27 or later, which enforces the illegal parameter blocklist against the fully assembled JDBC URL.
  • Rotate credentials for any database or service account previously configured within DataEase, since arbitrary file read may have exposed secrets.
  • Audit all existing data source configurations and remove any that contain the illegal JDBC properties listed in the advisory.
  • Restrict DataEase administrative and data source management permissions to a minimal set of trusted users.

Patch Information

The fix is delivered in DataEase v1.18.27 via commit 0db4872a52eccf6e83dd9359aa05db52dd580ec1, which updates MysqlConfiguration.java and PgConfiguration.java to validate the final JDBC URL (including its URL-decoded form) against the illegal parameter list. Full details are in the GitHub Security Advisory GHSA-mrf3-9q84-rcmf and the DataEase patch commit.

Workarounds

  • No official workarounds exist per the vendor advisory; upgrading is the only supported remediation.
  • As a compensating control until patching, block outbound connections from the DataEase server to any database endpoint outside the approved allowlist.
  • Temporarily disable data source creation and editing for non-administrative users until the upgrade is completed.
bash
# Verify DataEase version and constrain outbound DB traffic as a compensating control
docker inspect --format '{{.Config.Image}}' dataease

# Example iptables allowlist limiting DataEase egress to approved DB hosts only
iptables -A OUTPUT -o eth0 -p tcp -d 10.0.10.20 --dport 3306 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -d 10.0.10.21 --dport 5432 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 3306 -j REJECT
iptables -A OUTPUT -o eth0 -p tcp --dport 5432 -j REJECT

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.