CVE-2025-27531: Apache InLong Deserialization of Untrusted Data Vulnerability

The vulnerability, as described by CVE-2025-27531, lies in the insufficient sanitization of JDBC connection strings within Apache InLong, specifically allowing an attacker to read arbitrary files by 'double writing' a parameter. The provided commit ebcd6d3230b73abdc41edb93619be2a26c9b8c97 directly addresses this.

The root cause is found in the org.apache.inlong.manager.pojo.util.MySQLSensitiveUrlUtils.filterSensitive method. Prior to the patch, this method used a single-pass loop to iterate over a list of sensitive JDBC parameters (like allowLoadLocalInfile, autoDeserialize) and remove them if they were set to true or yes. An attacker could bypass this by crafting a parameter such as allowLoadallowLoadLocalInfile=trueLocalInfile=true. The single-pass removal might, for example, remove allowLoadLocalInfile=true, leaving allowLoad=true or a malformed but still effective parameter, or simply not catch the intended parameter if the duplication confused the string replacement. The patch rectifies this by changing the logic to a while loop that repeatedly scans and removes sensitive parameters until the URL is clean. This ensures that 'double written' or otherwise obfuscated parameters are effectively neutralized.

The method org.apache.inlong.manager.pojo.sink.mysql.MySQLSinkDTO.filterSensitive is also identified as a key function. While its source code modification is not directly in this patch (it's a DTO method, likely calling the utility), the test file MySQLSinkDTOTest.java was updated with a specific test case for this method, demonstrating the 'double writing' attack (allowLoadallowLoadLocalInfile=trueLocalInfile=true) and asserting that it's now correctly handled. This indicates that MySQLSinkDTO.filterSensitive is a direct pathway through which the vulnerable JDBC strings were processed.

By successfully injecting a parameter like allowLoadLocalInfile=true into the JDBC connection string due to this sanitization bypass, an authenticated attacker could instruct the MySQL JDBC driver to load data from local files on the server where the InLong manager is running, leading to arbitrary file reads. The vulnerability title also mentions 'Deserialization of Untrusted Data', which could be a broader categorization or relate to other JDBC parameters (e.g., autoDeserialize=true) that could be similarly injected, though the primary exploit demonstrated and fixed is the file read via parameter injection.