AI Threat Alert
OpenClaw's browser debug and export routes could reuse an already-open tab that was previously blocked by the SSRF policy, letting a caller inspect or exfiltrate content from private-network destinations the browser tool was never supposed to reach. This is a straightforward missing-authorization bug (CWE-862, CVSS 6.5) rather than a novel AI attack technique, but it sits directly inside OpenClaw's agentic browser tool — a component with 4 known downstream dependents and 425 other CVEs already logged against the package, so operators running OpenClaw with the debug/export feature exposed should treat this as part of a pattern, not an isolated slip. There is no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so exploitation likelihood is currently unconfirmed rather than low; the CVSS vector's AC:H and UI:R mean an attacker needs a caller who can reference an open tab plus some interaction, which narrows but does not eliminate the realistic path — a malicious skill or a lower-trust automation triggering the debug route. Patch to 2026.4.29 now; until then, close any blocked private-network tabs before using debug/export and restrict access to the debug routes to trusted operators only.
What is the risk?
Medium severity (CVSS 6.5) with a contained but real blast radius. Exploitability is moderate: the attack requires network access, high attack complexity, low privileges, and user interaction (AV:N/AC:H/PR:L/UI:R), meaning it is not trivially scriptable but is within reach of a malicious skill, a shared Gateway session, or an automation pipeline that can reference an existing tab handle. Impact is skewed toward confidentiality (C:H) with limited integrity impact (I:L) and no availability impact, consistent with an information-exposure flaw rather than a takeover. Exposure hinges entirely on deployment: OpenClaw's trusted-operator model limits this to environments where the debug/export feature is enabled, reachable, and where lower-trust input (a plugin, skill, or shared session) can reach that path — single-operator, locked-down deployments are largely unaffected.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| OpenClaw | npm | < 2026.4.29 | 2026.4.29 |
Do you use OpenClaw? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Patch to OpenClaw 2026.4.29 or later — this is the primary fix. Until patched: close any tabs that were previously blocked by the SSRF policy before using debug/export features, and restrict or disable the debug/export routes entirely if not actively needed. As general hardening, keep channel and tool allowlists narrow, avoid sharing a single Gateway between mutually untrusted users or automations, and audit who/what can reference existing browser tab handles. For detection, monitor debug/export route invocations for calls referencing tab IDs that were previously flagged by the network policy as blocked, and alert on export/debug activity originating from lower-trust callers (plugins, skills, non-founder sessions).
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-hcm3-8f6r-6xwg?
OpenClaw's browser debug and export routes could reuse an already-open tab that was previously blocked by the SSRF policy, letting a caller inspect or exfiltrate content from private-network destinations the browser tool was never supposed to reach. This is a straightforward missing-authorization bug (CWE-862, CVSS 6.5) rather than a novel AI attack technique, but it sits directly inside OpenClaw's agentic browser tool — a component with 4 known downstream dependents and 425 other CVEs already logged against the package, so operators running OpenClaw with the debug/export feature exposed should treat this as part of a pattern, not an isolated slip. There is no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so exploitation likelihood is currently unconfirmed rather than low; the CVSS vector's AC:H and UI:R mean an attacker needs a caller who can reference an open tab plus some interaction, which narrows but does not eliminate the realistic path — a malicious skill or a lower-trust automation triggering the debug route. Patch to 2026.4.29 now; until then, close any blocked private-network tabs before using debug/export and restrict access to the debug routes to trusted operators only.
Is GHSA-hcm3-8f6r-6xwg actively exploited?
No confirmed active exploitation of GHSA-hcm3-8f6r-6xwg has been reported, but organizations should still patch proactively.
How to fix GHSA-hcm3-8f6r-6xwg?
Patch to OpenClaw 2026.4.29 or later — this is the primary fix. Until patched: close any tabs that were previously blocked by the SSRF policy before using debug/export features, and restrict or disable the debug/export routes entirely if not actively needed. As general hardening, keep channel and tool allowlists narrow, avoid sharing a single Gateway between mutually untrusted users or automations, and audit who/what can reference existing browser tab handles. For detection, monitor debug/export route invocations for calls referencing tab IDs that were previously flagged by the network policy as blocked, and alert on export/debug activity originating from lower-trust callers (plugins, skills, non-founder sessions).
What systems are affected by GHSA-hcm3-8f6r-6xwg?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, browser automation / computer-use agents, AI agent tool integrations.
What is the CVSS score for GHSA-hcm3-8f6r-6xwg?
GHSA-hcm3-8f6r-6xwg has a CVSS v3.1 base score of 6.5 (MEDIUM).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0053 AI Agent Tool Invocation AML.T0086 Exfiltration via AI Agent Tool Invocation AML.T0107 Exploitation for Defense Evasion Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary Browser debug/export routes could reuse already-open blocked tabs. In affected versions, a caller that can reference an already-open browser tab could reuse blocked private-network tabs without reapplying the expected SSRF policy. This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed. ### Impact When the affected feature is enabled and reachable, this could export or inspect content from a tab that should have stayed behind the browser network policy. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path. ### Patched Versions The first stable patched version is `2026.4.29`. ### Mitigations close blocked tabs before debug/export use and restrict browser debug routes until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.
Exploitation Scenario
An attacker who can reference an already-open browser tab — for example, via a malicious or compromised skill, a shared Gateway session, or an automation with access to the debug/export API — waits for or triggers a tab that OpenClaw's SSRF policy had earlier blocked from reaching a private-network address (an internal admin console or a cloud metadata endpoint). Instead of opening a fresh navigation (which would be re-checked against the policy), the attacker calls the debug/export route against that existing blocked tab. Because reuse doesn't reapply the SSRF check, the route returns the tab's content, letting the attacker read or exfiltrate internal data the browser tool was never supposed to expose — all without needing to defeat the SSRF policy directly.
Weaknesses (CWE)
CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:L/A:N References
Timeline
Related Vulnerabilities
CVE-2026-33579 9.9 OpenClaw: scope bypass escalates low-priv to admin
Same package: openclaw CVE-2026-32922 9.9 OpenClaw: privilege escalation to RCE via token scope bypass
Same package: openclaw CVE-2026-53838 9.8 OpenClaw: approval scope bypass via reconnection state
Same package: openclaw CVE-2026-30741 9.8 OpenClaw: RCE via request-side prompt injection
Same package: openclaw CVE-2026-32038 9.8 OpenClaw: sandbox bypass enables container lateral movement
Same package: openclaw