Description

Server-Side Request Forgery (SSRF) vulnerability in Apache InLong.  Any authenticated user (no admin role required) can cause the InLong Manager server to make outbound HTTP requests or TCP connections to arbitrary internal hosts and ports. This issue affects Apache InLong: from 2.0.0 before 2.4.0. Users are advised to upgrade to Apache InLong's 2.4.0 or cherry-pick [1] to solve it. [1]  https://github.com/apache/inlong/pull/12130 .

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-08-20T16:17:30.483Z",
  "pubdate": "2026-08-20T16:17:30.483Z",
  "executiveSummary": "An authenticated Server-Side Request Forgery (SSRF) vulnerability has been identified in Apache InLong. This security flaw allows any authenticated user, without requiring administrative privileges, to induce the InLong Manager server to initiate outbound HTTP requests or establish TCP connections to arbitrary internal hosts and ports. The vulnerability exposes internal network architectures and services that are normally protected from external access. Exploitation of this issue can lead to unauthorized information disclosure, internal service scanning, and potential interaction with vulnerable backend systems residing within the trusted internal network. Affected deployments include Apache InLong versions from 2.0.0 prior to 2.4.0. Mitigation requires upgrading to Apache InLong version 2.4.0 or applying the official patch provided in the reference repository.",
  "technicalDetails": "The vulnerability resides in the InLong Manager component of Apache InLong, affecting versions 2.0.0 through 2.3.9. The root cause stems from insufficient validation and sanitization of user-supplied input that dictates destination parameters for network requests initiated by the server. Because the application fails to restrict or validate target IP addresses, domains, and port numbers, it processes arbitrary outbound connection requests.\nExploitation requires authentication against the InLong Manager server, though no specific administrative roles or elevated privileges are mandated. An authenticated attacker can supply crafted parameters containing malicious internal URLs or IP addresses and ports to the vulnerable application functionality. Upon submission, the InLong Manager server processes the input and acts as a proxy, executing outbound HTTP requests or raw TCP connections on behalf of the attacker.\nThe attack flow proceeds as follows: First, the attacker authenticates to the InLong Manager interface. Second, the attacker crafts an HTTP request or API payload targeting the vulnerable function, substituting the intended destination parameter with an internal IP address, loopback address, or internal service port (e.g., cloud metadata services or internal databases). Third, the server parses the request and initiates the outbound connection from its privileged network position. Finally, the server may return response data, error messages, or connection status back to the attacker, facilitating internal network reconnaissance, port scanning, and potential secondary exploitation of non-public services."
}