CVE-2025-27522: Apache Inlong Auth Bypass Vulnerability

CVE-2025-27522 Overview

CVE-2025-27522 is a Deserialization of Untrusted Data vulnerability [CWE-502] in Apache InLong, affecting versions 1.13.0 through 2.1.0. The flaw is a secondary bypass of the earlier fix for CVE-2024-26579, which attempted to block dangerous JDBC parameters in MySQL connection URLs. An attacker can bypass the case-sensitive keyword filter by supplying mixed-case variants of sensitive parameters, restoring the pre-patch deserialization attack surface. Apache advises upgrading to Apache InLong 2.2.0 or applying the fix from pull request #11732.

Critical Impact
A network-based attacker with access to InLong Manager APIs can bypass sensitive-parameter filtering in MySQL JDBC URLs and trigger unsafe deserialization, leading to disclosure and tampering of data handled by the Manager service.

Affected Products

Apache InLong 1.13.0 through 2.1.0
Apache InLong Manager component (inlong-manager)
Deployments relying on the pre-2.2.0 CVE-2024-26579 patch

Discovery Timeline

2025-05-28 - CVE-2025-27522 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-27522

Vulnerability Analysis

Apache InLong is a one-stop integration framework for streaming data. The InLong Manager component accepts MySQL JDBC connection strings when users configure data sources and sinks. The original fix for CVE-2024-26579 introduced a blocklist in MySQLSensitiveUrlUtils.containSensitiveKey that rejected URLs containing dangerous parameters such as autoDeserialize=true or allowLoadLocalInfile=yes. This filter directly used String.contains, which performs a case-sensitive comparison.

An attacker can defeat the filter by submitting the same parameter with alternate capitalization, for example autoDeserialize=True or AUTODESERIALIZE=yes. Once the URL passes validation, the MySQL JDBC driver processes the parameter normally and deserializes attacker-controlled data returned by a rogue database server, reintroducing the original deserialization risk.

Root Cause

The root cause is improper input validation in the sensitive-parameter filter. Case-sensitive substring matching allowed known dangerous JDBC options to pass when supplied in non-lowercase form. Because the underlying MySQL driver treats these option names case-insensitively, filter and consumer disagreed on what constitutes a match.

Attack Vector

Exploitation requires network access to an InLong Manager endpoint that accepts JDBC URLs. An attacker submits a data source configuration pointing to a MySQL server they control, embedding a mixed-case sensitive parameter. When InLong Manager connects, the malicious server returns crafted payloads that trigger Java deserialization in the JDBC driver, resulting in information exposure and integrity impact within the Manager process.

java

// Security patch: switch to case-insensitive matching
public static String containSensitiveKey(String url) {
    for (String key : SENSITIVE_REPLACE_PARAM_MAP.keySet()) {
        if (StringUtils.containsIgnoreCase(url, key + InlongConstants.EQUAL + "true")
                || StringUtils.containsIgnoreCase(url, key + InlongConstants.EQUAL + "yes")) {
            return key;
        }
    }
}
// Source: https://github.com/apache/inlong/commit/86c893cfd8f7ba9ffce5d20abef6cd360f502fdf

The patch replaces String.contains with StringUtils.containsIgnoreCase, aligning the filter with the case-insensitive semantics of MySQL JDBC parameter parsing.

Detection Methods for CVE-2025-27522

Indicators of Compromise

InLong Manager audit logs containing JDBC URLs with mixed-case parameters such as autoDeserialize=True, AutoDeserialize=yes, or allowLoadLocalInfile=TRUE.
Outbound connections from InLong Manager hosts to unexpected MySQL endpoints on TCP 3306 or other non-standard database ports.
Unexpected class loading or ObjectInputStream activity within the inlong-manager JVM around the time of new data source registrations.

Detection Strategies

Inspect API request bodies to InLong Manager data source and sink endpoints for JDBC URLs and flag any occurrence of sensitive parameter names using case-insensitive regular expressions.
Correlate creation of new InLong data sources with subsequent outbound database connections to previously unseen external hosts.
Monitor the inlong-manager process for Java deserialization exceptions or unusual reflective class instantiation in application logs.

Monitoring Recommendations

Enable verbose logging on the InLong Manager API layer and forward events to a centralized analytics platform for URL parameter inspection.
Baseline expected downstream database destinations for each InLong deployment and alert on deviations.
Track InLong version strings across the estate to identify hosts still running 1.13.0 through 2.1.0.

How to Mitigate CVE-2025-27522

Immediate Actions Required

Upgrade Apache InLong to version 2.2.0 or later on all Manager nodes.
If upgrading is not immediately possible, cherry-pick the fix from Apache InLong PR #11732 and rebuild affected components.
Restrict network access to InLong Manager APIs to trusted operators and internal automation only.
Review recent data source and sink configurations for mixed-case JDBC parameters and remove any that appear illegitimate.

Patch Information

The fix is delivered in Apache InLong 2.2.0 and in upstream commit 86c893cfd8f7ba9ffce5d20abef6cd360f502fdf. It replaces case-sensitive substring checks in MySQLSensitiveUrlUtils with StringUtils.containsIgnoreCase, closing the case-variation bypass. Additional context is available in the Apache Mailing List advisory.

Workarounds

Place InLong Manager behind an authenticated reverse proxy that rejects JDBC URLs containing autoDeserialize, allowLoadLocalInfile, allowLocalInfile, or allowUrlInLocalInfile regardless of case.
Apply egress firewall rules limiting InLong Manager to approved database endpoints only.
Disable or tightly restrict who can create or modify MySQL data sources within InLong until the patch is deployed.

bash

# Example egress restriction: allow only approved MySQL targets
iptables -A OUTPUT -p tcp -m tcp --dport 3306 -d 10.20.30.40 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 3306 -j REJECT

# Verify installed Apache InLong version
grep -R "inlong.version" /opt/inlong/ | head -n 5