OpenClaw EUVD-2026-87477

Exploitation requires all of the following: (1) the target fetch path must be one that uses the trusted-host DNS recheck code path; (2) the destination hostname must already be on OpenClaw's trusted-host allowlist; (3) the attacker must be able to make that allowed hostname resolve to an unspecified address (0.0.0.0 or ::), i.e., control or influence DNS for it; and (4) a service must actually be bound to loopback whose response is worth disclosing. Impact is confidentiality-only (data returned by the reachable internal service). Limiting factors: this is not exploitable against default configurations without DNS influence over an allowlisted host, exploitation is high-complexity (CVSS AC:H/AT:P), it is not automatable at scale, and it affects only OpenClaw deployments before 2026.8.1.

This is a genuine but conditional vulnerability that sits well below its headline number. The vendor CVSS 4.0 base score of 8.2 (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N) reflects network reach, no authentication, and high confidentiality impact, but two dampeners are baked into that very vector: AC:H and AT:P. Both encode the hard precondition that the attacker must be able to influence DNS resolution for an already-trusted/allowed hostname so it returns an unspecified address (0.0.0.0 or ::). That is a meaningful barrier, not a default-reachable condition, so the 8.2 rating reads as generous for a confidentiality-only SSRF whose payoff is entirely dependent on what loopback service happens to be reachable and what it returns. My independent CVSS 3.1 assessment lands at ~5.9 (Medium). On the exploitation-probability side, there is no EPSS score provided, the CVE is NOT in CISA KEV, and no public exploit code is referenced - so there is no public exploit identified at time of analysis and no evidence of active exploitation. SSVC-style reading: exploitation=none observed, automatable=no (requires per-target DNS influence over an allowlisted host, so it is not spray-and-pray), technical impact=partial (information disclosure only, no integrity/availability). Net: real and worth patching for OpenClaw operators, but a targeted/opportunistic issue rather than a mass-exploitation priority. No signals conflict; the main caveat is that vendor CVSS4 severity overstates practical risk relative to the described preconditions.

An attacker who can influence DNS for a hostname already on OpenClaw's trusted-host allowlist (e.g., via DNS cache poisoning, a controlled/compromised authoritative record, or a rebinding-style setup) makes that name resolve to 0.0.0.0 or ::. Because the trusted-host DNS recheck treats the unspecified address as valid, a guarded fetch is redirected to a service bound only to loopback, returning that internal service's response to the attacker. No public proof-of-concept is referenced; the network attack vector is offset by high complexity and the attack requirement of controlling DNS for an allowed host.