News

OpenClaw's 2026 security timeline: May disclosures, June advisories, July CVE records

July 18, 20268 min readUpdated September 13, 2026By OpenClawBlog Team

An OpenClaw security alert can look newer than it is. A GHSA page can describe a fix that shipped earlier, while a CVE page may appear later in a different database. Put those dates together carelessly and one disclosure cluster starts to look like several unrelated incidents.

The short answer

The project records opened for this report show two concentrated OpenClaw advisory dates: May 28 and June 30. The July records are a separate publication layer. On July 17, the GitHub Advisory Database search results displayed sixteen OpenClaw-labeled entries. The individual pages opened for this article label those entries unreviewed, list no package, and leave affected and patched versions unknown. They also point back to GHSA records published on June 30.

That supports a careful conclusion: May and June contain the project-level disclosures; July adds CVE records and external indexing around some of the same issues. The pages do not establish a July breach, a single OpenClaw security crisis, or exploitation in the wild.

DatePublic recordWhat it establishes
May 28OpenClaw repository GHSA pagesA concentrated group of feature-specific reports covering nodes, exec approvals, channel authorization, message actions, and environment handling.
June 30OpenClaw repository GHSA pagesFurther reports covering browser navigation, setup-mode plugin loading, exec glob matching, and device-pairing roles.
July 17GitHub Advisory Database and NVD-linked entriesCVE records were published or indexed for OpenClaw-related descriptions. The opened records do not replace the project advisories' version boundaries.

May 28 was a batch, not one vulnerability with many names

The May pages describe different controls and different prerequisites. They should be read as a group of narrowly scoped disclosures, not as one defect repeated across the product.

The most direct authority problem concerned revocation. GHSA-q99w-vh6v-q3v7 says that a surviving pairing-scoped device session could restore node-token authority after the token had been revoked. The record limits the issue to a device that already had a legitimate pairing and session foothold. It explicitly says the issue does not allow unauthenticated device creation. The first stable patched version listed is 2026.5.26.

Two other May records concern the integrity of an approval decision. GHSA-xww8-gqvh-92x9 describes an exec approval interface that could display a shortened command while the full command remained executable. An approver could therefore decide from incomplete text. The advisory lists versions before 2026.5.18 as affected and says the issue does not make exec available to unauthenticated users. GHSA-mhq8-78pj-5j79 covers a different approval gap: shell expansion on a paired POSIX node could change the arguments after a safe-bin decision. That record also points to 2026.5.18 as the first stable patched version.

Authorization and credential routing appeared in the same May batch. GHSA-q7q8-3mgw-q67r says a message-read action could skip the channel allowlist used by normal delivery, exposing messages from a channel not intended for the caller. Its first stable patch is 2026.5.19. GHSA-grc3-2j34-p6gm describes model-controlled action metadata selecting a loopback URL to which Gateway credentials could be forwarded. That record lists 2026.5.2 as patched.

The common thread is not that every installation was exposed. Each advisory names a feature, a configuration, or a caller that must be present. The repository's security policy makes the same boundary explicit: OpenClaw treats authenticated Gateway operators as trusted, and reports normally need a reproducible bypass of an auth, policy, approval, sandbox, or tool boundary.

June 30 moved the same work into browser, plugin, and pairing paths

The June records broadened the surfaces under review without changing the basic pattern.

GHSA-2x93-h3hg-2xfp concerns browser snapshot routes that could miss SSRF checks after navigation. The affected range begins at 2026.4.14 and ends before 2026.5.26; the advisory lists 2026.5.26 as patched. The important detail is the post-navigation check. Validating the first requested destination does not prove that the final browser destination remains inside policy.

GHSA-rh6r-vvfc-86jq says setup-mode discovery could load an untrusted workspace plugin and let it execute or persist actions beyond the caller's intended authorization. Versions before 2026.5.22 are listed as affected. GHSA-34mr-7r3m-gfg7 describes traversal bypasses in exec allowlist glob matching and lists 2026.5.18 as patched.

The fourth example is a role-management check. GHSA-8v95-qqcm-qp9h covers device.pair.approve and lists versions from 2026.1.20 through before 2026.5.27 as affected. Its first stable patched version is 2026.5.27.

These June pages all say the same thing in slightly different language: practical impact depends on whether the feature is enabled and whether a lower-trust input can reach it. A severity label alone cannot answer that deployment question.

July added CVE labels, not a new technical layer

The July 17 database entries are useful, but they need a different reading from the repository advisories. The page for CVE-2026-62227 labels the item Moderate and Unreviewed, says no package is listed, leaves affected and patched versions unknown, and references the official browser-snapshot advisory GHSA-2x93-h3hg-2xfp. The official GHSA page is dated June 30.

The same pattern appears in the pages for CVE-2026-62229 and CVE-2026-62218. Their descriptions refer to the June 30 advisories for exec allowlist traversal and device-pair approval. Both database pages say that NVD published the entries on July 17 and that they were published to the GitHub Advisory Database the same day.

Editorial inference: the safest timeline is therefore May disclosure, June follow-up disclosure, then July CVE publication or indexing. Counting the GHSA and CVE pages as separate bugs would inflate the record unless a page proves that they describe different defects. The unreviewed status does not show that a record is false. It does mean the database page is not the right source for inventing a package version or a new affected range.

What an operator could establish

Someone reviewing an OpenClaw installation in this period would need four facts before deciding whether an alert applies:

  1. Package and version. Record the exact openclaw version and package source. Use the patched floor on the relevant GHSA page, not the CVE number alone.
  2. Feature exposure. Check whether the named path is active: paired nodes, exec approvals, message-read actions, model action forwarding, browser snapshots, setup mode, or device-pair approval.
  3. Caller preconditions. Determine whether an authenticated operator, paired device, configured input path, lower-trust channel, or model-controlled action can reach that path. The advisories repeatedly make this conditional.
  4. Recovery state. If an older version was used during token revocation or device changes, follow the advisory's cleanup guidance. For the pairing-session issue, that includes restarting the Gateway and removing or re-pairing the affected device.

A patch is a version decision, not proof that the active Gateway has loaded the patched code. Keep the installed version, enabled features, and the relevant advisory together in the maintenance record. If the database entry has unknown package fields, return to the linked GHSA rather than filling the gap with a guess.

Failure paths and limits

  • A version match by itself does not prove exposure. The feature and reachability conditions still matter.
  • A patched version does not prove that a service, plugin, paired client, or node was actually updated.
  • A public advisory does not establish that the defect was exploited or that customer data was lost.
  • Several pages can describe one defect at different points in the disclosure and cataloging process. Map the references before counting incidents.
  • This report stops at the July 17 records available before the requested July 18 publication date. It does not turn later repository activity into part of the May–July timeline.

The public record is substantial enough to justify patching and feature review. It is not evidence for a larger story than the pages themselves support.

Sources

All sources were accessed on 2026-09-13. The repository advisories below provide the publication dates shown in the article. The security-policy page and database search page did not expose a separate publication date.

Reference Trail

Sources and further reading

  1. GitHub Advisory Database search resultsgithub.com
  2. GHSA-q99w-vh6v-q3v7github.com
  3. GHSA-xww8-gqvh-92x9github.com
  4. GHSA-mhq8-78pj-5j79github.com
  5. GHSA-q7q8-3mgw-q67rgithub.com
Back to ArchiveMore: NewsNext: OpenClaw v2026.7.2-beta.3: Safer channel operation, delivery notes