CVE-2026-92569: Hippo4j SSRF Vulnerability

CVE-2026-92569 Overview

CVE-2026-92569 is a Server-Side Request Forgery (SSRF) vulnerability affecting Hippo4j through version 1.5.0. The flaw resides in four ThreadPoolController endpoints that fail to validate the clientAddress parameter before issuing outbound HTTP requests. Authenticated attackers can supply arbitrary hostnames and ports, causing the Hippo4j server to send GET requests to attacker-chosen destinations. This behavior enables access to internal network services and cloud provider metadata endpoints that are otherwise unreachable from the public internet. The vulnerability is tracked under CWE-918: Server-Side Request Forgery.

Critical Impact
Authenticated attackers can pivot from Hippo4j into internal networks and query cloud metadata services such as AWS IMDS, potentially exposing sensitive infrastructure data and credentials.

Affected Products

Hippo4j through version 1.5.0
Hippo4j server component (hippo4j-server)
ThreadPoolController endpoints in the hippo4j-console module

Discovery Timeline

2026-09-16 - CVE-2026-92569 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92569

Vulnerability Analysis

Hippo4j is a dynamic, observable thread pool framework for Java applications. The server component exposes REST endpoints under ThreadPoolController that accept a clientAddress parameter identifying the target client thread pool instance. The controller uses this parameter to construct outbound HTTP GET requests without validating that the address points to a legitimate registered client.

Because the endpoints require authentication, exploitation requires a valid session against the Hippo4j console. However, any authenticated user, including low-privilege operators, can reach the vulnerable endpoints. The VulnCheck advisory documents four affected controller methods.

Root Cause

The root cause is missing input validation on the clientAddress parameter in the ThreadPoolController. The controller trusts the caller-supplied host and port and concatenates them into a URL passed to an internal HTTP client. There is no allowlist enforcement, DNS resolution check, or comparison against the set of registered client addresses.

Attack Vector

An authenticated attacker sends an HTTP request to one of the four vulnerable ThreadPoolController endpoints, setting clientAddress to an internal hostname, IP address, or cloud metadata endpoint such as 169.254.169.254. The Hippo4j server issues an outbound GET request to that target. Response content may be reflected in the API response or inferred via timing and status codes. Attackers can enumerate internal services, reach admin interfaces bound to loopback, and query cloud instance metadata to harvest temporary credentials.

// Vulnerable request pattern (illustrative, no verified PoC published)
// GET /hippo4j/v1/cs/thread-pool/list?clientAddress=169.254.169.254:80
// Server issues: GET http://169.254.169.254:80/latest/meta-data/

Detection Methods for CVE-2026-92569

Indicators of Compromise

Outbound HTTP requests from the Hippo4j server process to RFC1918 addresses, loopback, or link-local ranges such as 169.254.169.254.
Access log entries on ThreadPoolController endpoints containing clientAddress values that do not match registered client instances.
Unexpected DNS resolutions initiated by the Hippo4j JVM for external or internal hostnames not tied to legitimate clients.
Authenticated console sessions issuing repeated requests with varying clientAddress values, indicating enumeration.

Detection Strategies

Parse Hippo4j access logs and alert on clientAddress query parameters resolving to private, loopback, or metadata IP ranges.
Correlate application-layer requests with egress network flows from the Hippo4j host to detect anomalous internal destinations.
Baseline the set of registered client addresses and flag any inbound request referencing an address outside that set.

Monitoring Recommendations

Forward Hippo4j server logs and host network telemetry to a centralized analytics platform for correlation across authentication events and outbound connections.
Monitor cloud metadata endpoint access from workloads running Hippo4j and alert on any request originating from the JVM process.
Track authentication events on the Hippo4j console and correlate low-privilege accounts with ThreadPoolController activity.

How to Mitigate CVE-2026-92569

Immediate Actions Required

Restrict network egress from Hippo4j servers to only the IP ranges and ports of legitimate registered clients.
Block the Hippo4j host from reaching cloud metadata endpoints such as 169.254.169.254, or enforce IMDSv2 with session tokens on AWS.
Limit access to the Hippo4j console to trusted administrators and remove unnecessary authenticated accounts.
Review recent access logs for suspicious clientAddress values pointing at internal or metadata addresses.

Patch Information

At the time of publication, no fixed release is identified in the NVD entry. Track GitHub Issue #1621 and the Hippo4j repository for a security release addressing the four vulnerable ThreadPoolController endpoints. Review the VulnCheck advisory for updated guidance.

Workarounds

Place Hippo4j behind an egress proxy that enforces an allowlist of registered client addresses and rejects requests to private, loopback, and link-local networks.
Apply a reverse proxy or WAF rule that validates the clientAddress parameter format and blocks requests referencing metadata IPs or internal ranges.
Enforce IMDSv2 on AWS instances hosting Hippo4j so metadata queries require a PUT-issued session token, defeating simple GET-based SSRF.
Tighten role-based access in GlobalSecurityConfig so only administrative roles can reach ThreadPoolController endpoints.

bash

# Example iptables egress restriction on the Hippo4j host
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -d 127.0.0.0/8 ! -o lo -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -m owner --uid-owner hippo4j -j REJECT