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

CVE-2024-26579: Apache InLong Auth Bypass Vulnerability

CVE-2024-26579 is an authentication bypass flaw in Apache InLong caused by deserialization of untrusted data. Attackers can exploit this using malicious parameters to bypass authentication controls in versions 1.7.0 through 1.11.0. This article covers technical details, affected versions, impact assessment, and mitigation strategies.

Updated:

CVE-2024-26579 Overview

CVE-2024-26579 is a deserialization of untrusted data vulnerability in Apache InLong, a one-stop integration framework for massive data. The flaw affects Apache InLong versions 1.7.0 through 1.11.0 and is tracked under [CWE-502]. Attackers can bypass existing protections by supplying malicious parameters that trigger unsafe deserialization on the server. The issue is remotely exploitable over the network without authentication or user interaction. The Apache InLong project addressed the vulnerability in release 1.12.0 through pull requests #9694 and #9707.

Critical Impact

Unauthenticated remote attackers can craft malicious serialized payloads that bypass parameter filters, potentially leading to arbitrary code execution and full compromise of the Apache InLong instance.

Affected Products

  • Apache InLong 1.7.0 through 1.11.0
  • Deployments using vulnerable JDBC connection parameter handling in InLong
  • Downstream platforms that embed or depend on Apache InLong components in the affected range

Discovery Timeline

  • 2024-05-08 - CVE-2024-26579 published to the National Vulnerability Database
  • 2025-03-28 - Last updated in NVD database

Technical Details for CVE-2024-26579

Vulnerability Analysis

The vulnerability stems from improper handling of untrusted input during object deserialization within Apache InLong. An attacker can craft malicious parameters that bypass the project's existing validation logic and reach a deserialization sink. Once the crafted data is deserialized, attacker-controlled objects can be instantiated within the InLong process. This class of flaw, classified as [CWE-502] Deserialization of Untrusted Data, frequently enables remote code execution when exploitable gadget chains are present in the classpath. The advisory notes that prior mitigations could be bypassed using malicious parameters, indicating a filter or denylist evasion. Successful exploitation impacts confidentiality, integrity, and availability of the InLong service and any data it processes.

Root Cause

The root cause is unsafe deserialization combined with an insufficient parameter filter. The fixes in pull requests #9694 and #9707 tighten validation of JDBC and related connection parameters to prevent attacker-controlled values from reaching deserialization logic.

Attack Vector

The attack vector is network-based and requires no privileges or user interaction. An attacker submits crafted parameters to an exposed InLong endpoint that accepts connection or configuration data. The malicious parameters evade the existing filter and cause the server to deserialize attacker-controlled content, which can trigger gadget chains in the JVM classpath.

No verified public proof-of-concept code is available for CVE-2024-26579.
Refer to the Apache InLong patches in pull requests #9694 and #9707
for authoritative details on the affected parameter parsing and
deserialization paths.

Detection Methods for CVE-2024-26579

Indicators of Compromise

  • Unexpected child processes spawned by the Apache InLong JVM, such as shells, curl, wget, or bash invocations.
  • Outbound network connections from InLong hosts to unfamiliar IP addresses shortly after receiving HTTP requests with serialized payloads.
  • HTTP requests to InLong management or configuration endpoints containing JDBC URLs with suspicious properties or base64-encoded blobs.
  • New or modified files under InLong working directories that do not correspond to scheduled jobs.

Detection Strategies

  • Inspect HTTP traffic destined for Apache InLong APIs for serialized Java markers such as rO0AB, aced0005, or unusual JDBC URL parameters.
  • Hunt for process lineage anomalies where the Java process running InLong spawns interactive shells or scripting interpreters.
  • Correlate authentication, configuration changes, and outbound network telemetry with deserialization stack traces in InLong logs.
  • Apply [CWE-502] focused rules to API gateways and web application firewalls protecting InLong endpoints.

Monitoring Recommendations

  • Enable verbose logging on InLong manager and dataproxy components and forward logs to a centralized analytics platform.
  • Monitor for Java exceptions referencing ObjectInputStream, readObject, or gadget-related classes such as CommonsCollections or Rome.
  • Track version metadata of deployed InLong instances and alert when hosts run versions between 1.7.0 and 1.11.0.
  • Baseline normal API parameter shapes and alert on outliers in length, encoding, or property names.

How to Mitigate CVE-2024-26579

Immediate Actions Required

  • Upgrade Apache InLong to version 1.12.0 or later on all production, staging, and development environments.
  • If immediate upgrade is not possible, cherry-pick the fixes from pull requests #9694 and #9707 and rebuild from source.
  • Restrict network access to InLong management endpoints so they are reachable only from trusted administrative networks.
  • Audit recent InLong logs and host telemetry for signs of exploitation prior to patching.

Patch Information

The Apache InLong project resolved CVE-2024-26579 in release 1.12.0. The fixes harden parameter validation to prevent malicious values from reaching deserialization code paths. See the GitHub Security Advisory GHSA-fgh3-pwmp-3qw3 and the Apache mailing list discussion for advisory details, plus the OpenWall oss-security post for additional context.

Workarounds

  • Block or sanitize inbound requests containing serialized Java markers or unexpected JDBC connection properties at an upstream WAF or reverse proxy.
  • Run the InLong service under a least-privilege account that cannot execute arbitrary system binaries or write to sensitive paths.
  • Enforce strict allowlists for JDBC drivers and connection properties accepted by InLong configuration APIs.
  • Apply egress filtering on InLong hosts to limit reachable destinations if a deserialization payload achieves code execution.
bash
# Verify the installed Apache InLong version and upgrade if vulnerable
grep -R "inlong.version" /opt/inlong/ 2>/dev/null

# Example: replace a vulnerable binary distribution with 1.12.0
systemctl stop inlong-manager inlong-dataproxy
tar -xzf apache-inlong-1.12.0-bin.tar.gz -C /opt/
ln -sfn /opt/apache-inlong-1.12.0 /opt/inlong
systemctl start inlong-manager inlong-dataproxy

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.