Apache InLong CVE-2026-63044

Exploitation requires a valid authenticated session on Apache InLong Manager - any user account with login access qualifies; administrative role is explicitly not required. The InLong Manager API must be network-reachable from the attacker's position. No non-default configuration is specified as a prerequisite; the flaw exists in the default authenticated API surface. Exploitation is bounded by the authentication requirement: unauthenticated external attackers cannot directly exploit this without first obtaining valid credentials. The breadth of internal access achieved depends on what hosts and ports the InLong Manager server can reach from its network position - environments with strong egress controls between the Manager host and sensitive internal services will limit blast radius.

Without a published CVSS vector, risk must be inferred from the vulnerability class and conditions. SSRF with a low privilege requirement (authenticated user, no admin role) and network attack vector represents a realistic and accessible threat in any multi-user InLong deployment. The absence of a CVSS score from NVD and no current CISA KEV listing mean no official exploitation signal is available, and EPSS data is not provided in the source intelligence. However, CWE-918 SSRF vulnerabilities in data pipeline control planes carry well-understood real-world impact: internal service enumeration, cloud metadata credential theft (IMDSv1), and lateral movement precondition. The low bar for exploitation - any valid login - amplifies risk in environments where InLong user accounts are distributed across teams. The scope change to internal systems (the Manager reaching otherwise-inaccessible hosts) elevates practical severity beyond a simple information disclosure. The availability of a vendor patch (version 2.4.0) and upstream fix (PR #12130) since publication reduces urgency for patched deployments, but unpatched instances should be treated as a priority given the broad exploitability within the authenticated user population.

An authenticated InLong user - such as a data pipeline developer - submits a crafted API request to the InLong Manager with an internal URL as the target, for example the AWS instance metadata endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/) or an internal Elasticsearch management interface. The Manager constructs and dispatches the outbound request without validating the destination, then returns the response body to the caller, exposing IAM credentials or internal service data. No public exploit code is currently known, but the technique is well-understood for this vulnerability class and requires only standard HTTP tooling.