72 OpenClaw CVEs Landed in One Day — for Bugs Patched Back in July

2026-09-26 AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 26 September 2026, 72 CVE records for OpenClaw appeared in the National Vulnerability Database within a few minutes of each other. Every one was assigned by VulnCheck as CNA. Every one maps to a GitHub Security Advisory the OpenClaw project had already published on 11 September. And nearly all of them describe defects the project fixed in releases that shipped weeks earlier: 2026.7.1 on 13 July and 2026.8.1 on 31 August.

Nothing here is a zero-day. The interesting artifact is the gap — patched in July, advised in September, identified in the databases your scanner actually reads at the end of September. For two and a half months, a fleet running a pinned older OpenClaw was vulnerable to defects with fixes already in the wild and no identifier any vulnerability-management pipeline would notice.

What the batch actually contains

We pulled all 72 records from NVD and the CVE Program's own API rather than relying on aggregator summaries. The severity split, using the CVSS v4.0 scores in the records: 1 critical, 36 high, 30 medium, 5 low. The weakness distribution is the story:

CWE-863 (incorrect authorization) — 18 records. The single largest class.
CWE-862 (missing authorization) — 14 records. Combined with the above, 32 of 72 — a clear majority — are a permission check that was specified and not enforced.
CWE-200 (information exposure) — 6, CWE-400 (resource exhaustion) — 5, CWE-918 (SSRF) — 5, CWE-22 (path traversal) — 3.

Seventeen of the 72 descriptions turn on the word owner. That is the shape of this batch: OpenClaw documents an owner-versus-authorized-sender boundary across its chat commands, and a long list of command handlers simply did not consult it.

The ones that matter operationally

Four records deserve attention beyond the aggregate count.

CVE-2026-100596 (CVSS v4.0 8.7, GHSA-wwx7-573h-pqwc) is the highest-consequence authorization failure in the set. Before 2026.7.1, /mcp set and /mcp unset did not enforce the owner requirement, so an authorized non-owner sender in a connected channel could persist an arbitrary stdio MCP server command — which then executes with the OpenClaw process user's privileges the next time configuration loads. The advisory is explicit that installed and owner-configured MCP servers remain trusted integrations; the boundary that failed is authorization to write that configuration. Readers will recognise the pattern from CVE-2026-44995, the MCP stdio environment-variable RCE we covered in May. Same subsystem, same primitive: whoever controls the MCP process spec controls the host.

CVE-2026-100551 (CVSS v4.0 9.0, the only critical) is an iOS client flaw fixed in 2026.8.11. Native connections enforced the saved Gateway certificate fingerprint; the authenticated Terminal and session Dashboard WebViews did not. An attacker able to redirect the same host and port with a certificate iOS system trust accepts can serve a replacement Control UI, and opening the Terminal hands that page the injected Gateway token or password — an operator credential with host-capable tool access. A pin enforced in one transport and skipped in another is the classic split-path failure, and here the skipped path is the one that renders remote HTML.

CVE-2026-100597 (8.8) is a time-of-check-time-of-use race in OpenShell's local mirror filesystem operations. Remove, mkdir, and rename could land on a different target after the sandbox path-safety check passed. The record notes the part that matters: this does not require an operator to have granted host filesystem access outside the sandbox. A sandbox whose safety depends on winning a race is not a boundary, it is a probability.

CVE-2026-100567 (8.9) is DNS rebinding against remote Chrome DevTools Protocol endpoints. The Gateway validated one DNS resolution for the configured CDP hostname; the raw WebSocket and Playwright transports then resolved independently, discarding the pin. Attacker-controlled DNS for an approved hostname reaches loopback, link-local, and cloud metadata addresses. Check-then-use, again — the same class that hit GitLab's MCP integration earlier this month.

The lag is the finding

Reconstruct the timeline from the primary artifacts:

13 July 2026 — OpenClaw 2026.7.1 released; it is the fix for 20 of these CVEs.
31 August 2026 — 2026.8.1 released; it is the fix for 45 of them.
11 September 2026 — OpenClaw publishes 75 GitHub Security Advisories in a single sweep. None carried a CVE ID at publication; the repository's advisories still return cve_id: null through the GitHub API.
26 September 2026 — VulnCheck publishes 72 CVEs against those advisories.

A defender pinned to 2026.6.x had no identifier to match for 75 days after the first fix shipped. GitHub's Dependabot ecosystem would flag the advisories from 11 September; a CVE-keyed SCA tool or an internal risk register indexed on CVE ID saw nothing until yesterday. That is not VulnCheck's failure — enriching advisories that upstreams leave unidentified is precisely the CNA work it took on, and it is the same organisation that publicly counted how few Project Glasswing findings turned into confirmed CVEs. It is a structural gap: for fast-moving agent projects shipping weekly, the advisory and the identifier now arrive months apart, and most enterprise tooling only reacts to the second one.

Why an agent runtime produces this shape of bug

Thirty-two missing-or-wrong authorization checks in one codebase is not thirty-two independent mistakes. It is one architectural property expressed thirty-two times. OpenClaw exposes a large command surface — memory toggles, dreaming, activation policy, trajectory export, diagnostics, voice, MCP configuration — across a long list of channel integrations (Discord, Slack, Matrix, Teams, Feishu, LINE, QQBot, Signal, WhatsApp, Google Chat). Each handler independently decides whether the sender is the owner. There is no single choke point that answers the question once, so each new command is a fresh chance to forget.

The consequences are unevenly distributed. Several of the medium-severity records — Active Memory global toggles (CVE-2026-100591), /dreaming persistence (CVE-2026-100592), group /activation policy (CVE-2026-100593) — let a non-owner quietly change the agent's memory and attention behaviour. On their own they score 5.3. Chained with a content-injection path, they are a way to make an agent forget what it was told, or start reading traffic it was configured to ignore, without ever touching a shell. Meanwhile /export-trajectory (CVE-2026-100594, 7.1) and diagnostics export (CVE-2026-100595, 7.1) hand a non-owner the prompts, model messages, tool schemas, runtime events, and local path metadata of a session — reconnaissance for everything else in this list.

This is the governance problem in the tool-allowlisting research we covered earlier this month viewed from the vendor side. Allowlists only bind if the code path that consults them cannot be reached around, and a runtime with dozens of integrations has dozens of paths.

What to do

Upgrade to at least 2026.8.1 for the Gateway, and 2026.8.11 for the iOS client. Between them they close the overwhelming majority of the batch. Three records point higher — 2026.9.2 and 2026.9.3 — so 2026.9.3 or later is the clean target where you can take it.
Re-scan now, not at your next cycle. If your SCA is keyed on CVE identifiers, 72 findings for a package you already run became visible yesterday. Absence of alerts last week was an identifier gap, not a clean bill.
Audit who counts as an authorized non-owner sender. Almost every record in this batch requires low privileges — an account already permitted to talk to the agent in a channel. Enumerate those senders per integration and shrink the list; that is the precondition the majority of these CVEs depend on.
Treat MCP configuration as privileged state. Whether or not you are on a fixed build, a stdio MCP command spec is code execution with a configuration file's ergonomics. Restrict who can write it and alert on changes.
Check for hostname-based remote CDP endpoints. The advisory for CVE-2026-100567 recommends disabling them or restricting them to trusted, stable infrastructure — good advice independent of your version.

Sources: