OpenClaw CVE-2026-53839

Exploitation requires an authenticated low-privilege account within the OpenClaw application (PR:L per CVSS 4.0 vector). The AT:P metric confirms specific attack prerequisites beyond network access: the attacker must control or register a hostname that is a syntactic prefix of a hostname on OpenClaw's trusted retry endpoint list, and that hostname must be resolvable and reachable from the OpenClaw service. The retry mechanism must be active and triggered during the attack window. Exploitation is limited by the need for attacker-controlled infrastructure with a specifically crafted hostname, and by the requirement for prior authentication. Deployments where retry endpoint functionality is disabled, or where egress traffic is restricted by firewall policy to only explicitly approved IP ranges, substantially reduce exploitation feasibility.

The CVSS 4.0 score of 6.0 reflects meaningful but constrained risk. AV:N indicates the attack path is over the network, but PR:L confirms that some authenticated foothold within the system is a prerequisite - unauthenticated exploitation is not supported by the available data. The AT:P (Attack Requirements: Present) metric is significant: the attacker must satisfy specific conditions beyond simply being on the network, most critically controlling or registering a hostname that shares a prefix with a trusted hostname. The confidentiality impact is rated high (VC:H) because authentication material - potentially including session tokens, API keys, or credentials - can be fully exposed. There is no integrity or availability impact. No EPSS score was provided, and the vulnerability does not appear in CISA KEV, so there is currently no confirmed active exploitation. The combination of PR:L and AT:P meaningfully suppresses the realistic threat surface compared to a fully unauthenticated, low-complexity attack. This is a genuine security issue for deployments that use the retry endpoint feature, but the absence of KEV listing and public exploit code suggest it has not been widely abused.

An authenticated attacker registers or obtains control of a hostname that is a prefix match for a trusted endpoint - for example, if 'auth.internal.corp' is on the trusted list, the attacker controls 'auth.internal.corp.attacker.net'. When OpenClaw's retry logic fires for a failed request, it evaluates the crafted hostname against the prefix-based check, which returns a match; authentication material (tokens, credentials) is then forwarded to the attacker's server. No public proof-of-concept code has been identified at time of analysis.