OpenClaw EUVD-2026-87484

Requires that the operator has enabled and configured a hostname-based remote Chrome DevTools Protocol (CDP) endpoint - the advisory's own mitigation is to disable this or restrict it to trusted, stable infrastructure, confirming it is a non-default, config-dependent deployment. The attacker must control an approved CDP hostname or its DNS answers and successfully execute a DNS-rebinding race (reflected in AC:H and AT:P) so the transport's later independent resolution lands on an internal address. Impact is further limited to whatever loopback/private/metadata services are actually reachable from the Gateway host, so a hardened network egress posture blunts it.

This is a genuine SSRF (CWE-918) driven by a check-then-use (TOCTOU) gap: the Gateway validates one DNS resolution for a remote CDP hostname, but the raw WebSocket and Playwright transports re-resolve DNS later and discard the pinning, enabling DNS rebinding to SSRF-denied targets (loopback, private, link-local, cloud metadata). The vendor CVSS 4.0 score of 8.9 is inflated by scope-change metrics (SC:H/SI:H) and VI:H that overstate the primary confidentiality-leak nature of SSRF; the vector's own AC:H, AT:P, and UI:P confirm this is NOT a trivial mass-exploit path. Realistic risk is materially lower than 8.9: exploitation requires the attacker to control an already-approved CDP hostname or its DNS answers AND win a DNS-rebinding timing race, AND the operator must have configured a hostname-based remote CDP endpoint (a non-default deployment choice the advisory explicitly tells you to disable as mitigation). No EPSS score, no CISA KEV listing, and no public exploit code are present in the input, so there is no evidence of active or widespread exploitation. Net: a real but conditional bug - patch-worthy for anyone running hostname-based remote CDP, but not an emergency for the typical deployment. Impact is bounded by 'services reachable from the Gateway host,' which the description states outright is deployment-dependent.

An operator configures OpenClaw to reach a remote Chrome DevTools Protocol endpoint by hostname. An attacker who controls that hostname's DNS answers passes the initial validation with a benign IP, then flips DNS so the transport's second, independent resolution points at 169.254.169.254 or a loopback service, causing the Gateway to connect there and relay/expose the response. No public proof-of-concept is identified in the input; success depends on the attacker controlling the approved hostname's DNS and winning the rebinding timing window (AC:H, AT:P).