Inlong CVE-2025-27531

This vulnerability represents a genuine critical risk that merits immediate patching: (1) CVSS 9.8 with AV:N/AC:L/PR:N reflects network accessibility and low attack complexity, though the PR:N (no privileges required) designation appears inconsistent with the description stating 'authenticated attacker'—this suggests either CVSS severity inflation or the description understates that authentication is a weaker control than claimed; (2) Deserialization vulnerabilities are historically among the most exploitable classes (CWE-502 consistently ranks in top 25 weaknesses) with well-established exploitation techniques; (3) The arbitrary file read capability directly impacts confidentiality (C:H); (4) No KEV/CISA listing or public POC is indicated in the provided data, but absence of evidence is not evidence of absence given the recency (2025); (5) EPSS data not provided, but deserialization flaws typically score 80%+ exploitation probability. The contradiction between 'authenticated' requirement and CVSS PR:N scoring slightly lowers confidence, but the vulnerability should still be treated as critical due to the arbitrary file read scope and deserialization attack vector maturity.

An authenticated user with access to Apache InLong's parameter configuration interface (e.g., ingestion pipeline setup) crafts a malicious serialized Java object embedding a gadget chain that, when deserialized, executes arbitrary code or file read operations. The attacker leverages the 'double writing' technique—manipulating the param field twice or encoding it in a way that bypasses first-pass validation—to inject a payload targeting sensitive files (/etc/passwd, application config files, database credentials). Upon parameter submission, InLong deserializes the untrusted object without validation, triggering the gadget chain that exfiltrates file contents back to the attacker. The network-accessible nature of InLong APIs means an attacker could potentially enumerate services to identify exposed instances, reducing the practical barrier despite the 'authenticated' requirement. No public POC is indicated, but deserialization exploitation is well-tooled in the Java ecosystem (ysoserial, etc.), making practical exploitation highly likely once the vulnerability becomes widely known.