CVE-2026-92569 in Hippo4j
Summary
by MITRE • 09/17/2026
Hippo4j through 1.5.0 contains a server-side request forgery vulnerability in four ThreadPoolController endpoints that fail to validate the clientAddress parameter. Authenticated attackers can supply arbitrary hostnames and ports to trigger outbound GET requests to internal networks and cloud metadata services.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in Hippo4j versions up to 1.5.0 represents a critical server-side request forgery flaw located within the ThreadPoolController module. This component is responsible for managing thread pool configurations, but it contains four specific endpoints that exhibit insufficient input validation regarding the clientAddress parameter. The core technical failure lies in the application's logic which accepts user-supplied values for this parameter and subsequently uses them to construct outbound HTTP GET requests without performing adequate sanitization or allowlisting of target hosts. This design oversight allows an attacker who has successfully authenticated to the application to manipulate these parameters, effectively turning the server into a proxy that can initiate connections to arbitrary destinations on behalf of the backend system.
From an operational perspective, this vulnerability enables authenticated attackers to perform network reconnaissance and data exfiltration against internal infrastructure. By supplying malicious hostnames and port numbers in the clientAddress field, adversaries can trigger outbound requests directed at private IP ranges commonly used within corporate networks or cloud environments. A primary target for such attacks is cloud metadata services, which are often accessible via non-routable addresses like 169.254.169.254 on AWS or similar endpoints in other cloud providers. Successful exploitation allows attackers to retrieve sensitive instance metadata, including temporary security credentials and configuration details, thereby compromising the integrity of the entire cloud environment. This capability significantly expands the attack surface beyond simple application-level issues into broader network compromise scenarios.
This vulnerability aligns with CWE-918, which defines Server-Side Request Forgery (SSRF), specifically falling under subcategories related to blind SSRF where the server makes requests based on user input without proper validation of the destination. In terms of offensive security frameworks, this exploit maps directly to MITRE ATT&CK technique T1557, known as Adversary-in-the-Middle or Lateral Tool Transfer when used for internal pivoting, and more specifically T1098 which covers Account Manipulation if credentials are stolen via metadata access. The lack of egress filtering and destination validation is a common pattern in microservices architectures that expose administrative APIs without strict network segmentation controls.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The most effective solution is to upgrade Hippo4j to version 1.5.1 or later, where the developers have implemented proper input validation for the clientAddress parameter. For environments that cannot immediately patch, administrators should enforce strict network egress policies using firewalls or cloud security groups to block outbound connections from application servers to internal IP ranges and known metadata service endpoints. Additionally, implementing a whitelist approach for any external services required by the thread pool management functionality can prevent arbitrary destination resolution. It is also critical to ensure that authentication mechanisms are robustly enforced on these administrative endpoints to limit exposure to unauthenticated users, although this vulnerability specifically requires valid credentials to exploit.