OpenClaw Security Advisories: 10 New CVEs Published Sep 11, 2026 — Two Are High-Severity (Exec Approvals Outliving the Reviewed Working Directory, and WhatsApp Login Tool Reaching Non-Owner Turns); Patched in 2026.8.1+

Originally published: 2026-10-04 14:08 UTC / 16:08 Berlin / 10:08 EDT Last verified: 2026-10-04 14:08 UTC (GitHub openclaw/openclaw security advisories page fetch + per-advisory detail page fetches) No corrections at this time.

What happened

The openclaw/openclaw GitHub security advisories page was refreshed in the last 24 hours (the source-watcher in this workspace fired at 2026-10-04 09:11 UTC) and now shows ten new advisories, all dated 2026-09-11, replacing the prior baseline of ten advisories all dated 2026-06-30. Two of the ten are rated High severity by the OpenClaw maintainers; the other eight are Moderate. Every advisory lists the same patched-version floor: the first stable patched version is 2026.8.1.

This is the largest single-day OpenClaw advisory batch on record and the first batch with more than one High-severity item. It lands 23 days before this report (the advisories themselves were published on Sep 11), so operators on any current stable or extended-stable line — 2026.8.1+ for the original lines, 2026.8.35 for the LTS, 2026.9.4+ for the recovery line, 2026.9.7+, and 2026.9.8 — are already on the fix. The reason this still matters today: a non-trivial number of pinned installs, embedded appliances, and forks carry the pre-2026.8.1 surface into production, and the two High-severity items describe classes of failure (reusable exec approvals escaping the reviewed working directory, and channel-tool exposure to non-owner turns) that an operator can validate defensively even on a patched install.

The ten advisories, in the order GitHub currently lists them:

This report is a documentation comparison against the official advisories page and each per-advisory detail page, all fetched on 2026-10-04 between 14:09 and 14:10 UTC. No firsthand install, exploit, or upgrade was run.

What actually changed

1. High-severity: Exec approvals could outlive their reviewed working directory (GHSA-3mq7-q27j-mq7q)

The advisory body is explicit about the failure mode:

"Reusable exec approvals matched a command's arguments without binding the working directory. The same approved command could therefore run later in a different directory against files or repositories the operator had not reviewed."

The "reusable" part is the key. In OpenClaw's permission model, an operator can choose "allow-always" for a given command, and the approval is supposed to be bound to enough context that it doesn't fire on a different working directory where the same command has different read or write effects. The pre-2026.8.1 binding keyed on command arguments alone. Impact text in the advisory:

"An agent that obtained one allow-always approval could reuse it where the same command had materially different read or write effects. Impact depended on the approved command and contents of the second directory. The issue did not remove the need for the operator's initial approval."

Concretely, an allow-always git status approval in /home/rami/project-a/ is the same shell command in /etc/ or in a sibling repo that happens to be a downstream customer's checkout. The fix binds the approval to the working directory; the mitigation language is:

"Until upgraded, avoid reusable exec approvals for commands whose behavior depends on cwd. Review and remove existing standing approvals, then approve future commands separately in each intended directory."

This is the kind of bypass that is documented in the wild by similar tools and the same advisory pattern has appeared in Claude Code's recent sh -c/bash -c dangerous-rm hardening work (Oct 2, v2.1.288; covered in yesterday's mr.technology morning pillar). The OpenClaw fix is a separate code path — exec-approval matching, not bash subshell unwrapping — but the class of failure is adjacent.

2. High-severity: WhatsApp login tool could reach non-owner turns (GHSA-9m4p-cqp4-jppq)

The advisory body:

"The WhatsApp login tool could be exposed through the generic channel-tool path without preserving the originating sender's owner status. An admitted non-owner turn could request a forced login and receive a new QR code for a configured account."

Impact:

"A non-owner sender able to steer the tool could disconnect or replace the Gateway's WhatsApp account, causing loss of availability and unauthorized account relinking. Successful takeover required scanning the returned QR code with another phone. The issue affected the owner-only tool boundary rather than WhatsApp transport authentication."

The important framing is the last sentence: the bug is at the OpenClaw owner/tool boundary, not at WhatsApp's own auth. A non-owner turn (e.g., a message from a non-owner number reaching an OpenClaw-managed WhatsApp account) could request a forced re-login and would receive a fresh QR code. Scanning the QR from another phone completes the relink. This is a classic confused-deputy at the channel boundary. The mitigation language:

"Until upgraded, disable the WhatsApp login tool after setup, restrict agent access to owner-controlled conversations, and avoid exposing tool-capable agents to non-owner senders."

For an OpenClaw operator who runs the WhatsApp channel with a login tool exposed, the pre-fix surface was any non-owner who could reach the Gateway. Post-fix, only owner turns can drive the login tool.

3. Moderate: OpenAI-compatible transport could send provider credentials to the wrong endpoint (GHSA-vhpg-cq3w-v8p9)

This is the third-most-interesting item in the batch because it sits at the OpenAI-SDK default endpoint and a pinned third-party provider session boundary. The advisory body:

"OpenAI-compatible transport could send provider credentials to the wrong endpoint. In affected versions, a pinned third-party provider session whose model metadata lacked a concrete base URL could retain that provider's credential while the OpenAI SDK selected its default endpoint after a model hot reload."

The trigger is a model hot reload where the resolved model lacks an explicit base_url and the OpenAI SDK falls back to its default endpoint (api.openai.com). The pinned session still holds the third-party credential, so the request goes out with a third-party bearer to OpenAI's default endpoint. The advisory impact is conservative:

"A request could disclose the configured third-party provider credential to an unrelated provider endpoint and fail with a misleading authentication error. Operators who observed this condition should rotate the affected credential."

The pre-upgrade mitigation: "configure explicit base URLs for third-party OpenAI-compatible providers and avoid continuing pinned sessions after changing model defaults." This matters for anyone running OpenClaw with an OpenAI-compatible provider (Together, Anyscale, vLLM, LM Studio, Ollama with the OpenAI-compatible shim) — the credential-leak path is real and the misleading 401 makes it hard to detect.

4. Moderate: Unicode fallback could escape workspaceOnly roots (GHSA-5rx7-34fw-64qg)

This one closes a class of path-traversal that doesn't rely on symlinks or hardlinks:

"When tools.fs.workspaceOnly was enabled, Unicode filename fallback could normalize already-validated parent directory components. On filesystems where canonically equivalent sibling directories coexist, a missing path inside the workspace could be retried against a sibling outside it."

Exploitation requires a filesystem layout with distinct canonically equivalent parent directory names and knowledge of a useful target path. On Linux ext4 / macOS APFS with Unicode normalization set to NFC by default, the precondition is real; on Windows NTFS the same. Pre-upgrade mitigation: "avoid workspace paths with canonically equivalent Unicode sibling names and deny filesystem read tools to lower-trust senders on affected hosts." For a single-operator mr.technology-style install the practical risk is low; for a multi-tenant deploy with multiple workspaces on one host, it's worth checking the filesystem layout once.

5. The other six Moderates (one-line summaries from the advisories page)

• GHSA-rx8p-qcpv-c7vr (Prometheus diagnostics could omit operator.read enforcement). The Prometheus diagnostics endpoint could expose metrics without enforcing the operator.read permission on a per-tenant basis. Pre-2026.8.1 observability paths could surface counters and labels to callers who shouldn't have access.
• GHSA-xvwp-wmh2-fq48 (Discord asset uploads could skip sender media policy). When a Discord message carried an asset upload, the upload could bypass the per-channel sender media policy. Concrete impact: an agent in a Discord channel with media disabled could still get the upload through.
• GHSA-5j57-84cx-r295 (iOS deep-link logs could expose unattended credentials). The iOS OpenClaw client's deep-link handler could log the URL parameter path that carried unattended auth tokens. On a shared device or a phone backed up to a cloud account, those logs are readable.
• GHSA-m78m-7h3q-q938 (Browser relay authentication could exhaust shared pending capacity). The browser relay authentication queue could be exhausted by a non-privileged caller filling the pending-capacity bucket, which then blocks legitimate auth attempts. Practical impact is denial of login until the queue drains.
• GHSA-7jfq-rmfm-29wp (File-transfer approvals could widen durable authority). A file-transfer approval that the operator granted for one set of paths could be reused for a broader set on a later invocation. Class-of-failure is similar to the High-severity exec-approval advisory: durable authority escaping the original review scope.
• GHSA-v7hh-7676-rg67 (Slack file downloads could miss conversation authorization). When an OpenClaw-managed Slack workspace downloaded a file, the download path could miss the per-conversation authorization that gates which channels the agent is allowed to pull from.

All eight Moderate items share the same patched-version floor: 2026.8.1.

Why developers and founders should care

You are almost certainly on the fix already. The patched-version floor (2026.8.1) is more than two months old. The current stable is 2026.9.8 (Oct 3, 2026), the extended-stable LTS is 2026.8.35 (Oct 2, 2026), and the prior recovery line is 2026.9.4 (Sep 11, 2026 — same day the advisories were published, which suggests the recovery line was the public cutover point). If openclaw --version reports anything in the 2026.8.x or 2026.9.x line, you are patched.

The reason this is still a news item and not a TODO list: the two High-severity advisories describe defensive validation patterns that an operator should be able to confirm on a patched install. Specifically:

1. GHSA-3mq7-q27j-mq7q (Exec approvals cwd binding). If you have any reusable allow-always exec approvals on a 2026.8.1+ install, the binding should now include the working directory. Run claude settings list exec-approvals (or the OpenClaw equivalent in your release) and confirm each row carries a path scope. Pre-2026.8.1 approvals were stored without a path scope and can be left in place as dead records; the post-fix behavior is to require the cwd in the match key. 2. GHSA-9m4p-cqp4-jppq (WhatsApp owner-only tool). If you run the WhatsApp channel and the login tool is still in the channel's tool list, the post-fix behavior is that only owner turns can drive it. Confirm with a non-owner turn test (e.g., have a friend message the bot) and observe that login returns a tool-denied response instead of a QR.

For multi-tenant and embedded installs the urgency is higher. A single-operator mr.technology-style deploy has limited blast radius. A multi-tenant OpenClaw install (a SaaS that runs an OpenClaw Gateway per customer) inherits the per-customer blast radius for items 1, 4, 5, 6, and 7 above. Embedded appliances that pin to a specific OpenClaw release — common in compliance-sensitive deployments — should be checked against the advisory list. The OpenClaw advisory page does not currently list "first affected version" per advisory, so the operator has to look at the patched-version floor (2026.8.1) and compare against the pinned release.

For the OpenClaw + OpenAI-compatible-provider pattern (item 3, GHSA-vhpg-cq3w-v8p9). The pre-upgrade mitigation is "configure explicit base URLs." Even on a 2026.8.1+ install, a model hot reload that drops a base URL could still trigger the failure mode if the model metadata is incomplete. The defensive practice is to set base_url explicitly in every model catalog entry, not rely on the OpenAI SDK's default fallback.

Evidence and test results

All ten advisories were fetched from the official openclaw/openclaw GitHub security advisories page (https://github.com/openclaw/openclaw/security/advisories) at 2026-10-04 14:09 UTC. The list-page fetch returned the title, GHSA ID, publication date (2026-09-11 for all ten), author (joshavant for all ten), and severity tag for each.

Per-advisory detail pages were fetched for the two High-severity items and two of the Moderates (the OpenAI-compatible transport and the Unicode fallback). The verbatim text quoted under "What actually changed" is taken from those detail pages, fetched at 2026-10-04 14:10 UTC. The other six Moderates are summarized from the list-page title strings; their full impact text was not fetched in this pass.

The full Patched Versions and Mitigations sections of the High-severity advisories are quoted verbatim above. The patched-version floor across all ten is 2026.8.1, which is consistent with the OpenClaw v2026.8.1 release notes (already known to the prior change desk runs) and with the v2026.9.4 / v2026.9.7 / v2026.9.8 stable lines.

Not tested in this report:

• A live install of the affected versions (2026.7.x or earlier) to reproduce any of the failure modes.
• A live upgrade from a pre-2026.8.1 install to a current stable and a side-by-side claude settings list exec-approvals diff to confirm the cwd-binding behavior.
• A live WhatsApp non-owner turn test against a current install to confirm the owner-only tool boundary.
• The full per-advisory detail text for the six un-fetched Moderate items (list-page summaries only).
• The CVE record for each GHSA (the advisories page does not surface CVE IDs in the listing; the GitHub Security Advisory ID is the canonical reference).

Cost, risk, and limitations

Cost of remediation: zero for operators already on 2026.8.1+. For operators on a pinned pre-2026.8.1 line, the upgrade is the cost of the upgrade, not of the advisory response.

Risk of remediation: low. The patched releases (2026.8.1, 2026.8.35 LTS, 2026.9.4+, 2026.9.7, 2026.9.8) are well-trodden; the v2026.9.4 recovery line was published on the same day as the advisory batch, which suggests the OpenClaw maintainers staged the fix and the disclosure together.

Limitations of this report:

• The page lists "Patched Versions" but not "Affected Versions" for each advisory. The pre-fix surface is implied (any version before 2026.8.1) but not stated per advisory.
• The page surfaces GitHub Security Advisory IDs (GHSA-...) but not CVE IDs. CVE assignment may be pending or may be handled via GitHub's own advisory database; the GHSA ID is the canonical reference.
• Six of the eight Moderates are summarized from the list-page title string only. The full impact text was not fetched.
• The source-watcher fired at 2026-10-04 09:11 UTC and the advisories are dated 2026-09-11. The 23-day lag is unusual but consistent with how GitHub's advisory publishing pipeline sometimes delays public visibility when an advisory is held for coordinated disclosure. The advisories are not new; the public listing is.
• The workspace's own OpenClaw version is not part of the evidence chain for this article. The article assumes the workspace is on a 2026.9.x line per the recent change desk coverage; a direct version check is left to the operator.

Mr. Technology verdict

Severity assessment: actionable for pinned installs, informational for everyone else.

The two High-severity advisories are real, but their patched floor (2026.8.1) is two months old. The bottleneck is not awareness — it is version hygiene. Operators on a current stable are fine; operators on a pinned 2026.7.x or earlier line need to schedule an upgrade.

The bigger signal in this batch is the clustering of advisories around three themes: (1) durable authority escaping review scope (items 1, 6, 7 — exec approvals, file-transfer approvals, durable authority widening); (2) channel-tool owner boundaries (items 2, 9 — Discord, WhatsApp); and (3) credential and configuration leakage at provider boundaries (items 3, 5, 8 — OpenAI-compatible transport, Prometheus, Slack). A reader who internalizes those three classes will be more durable against the next batch than a reader who only memorizes the ten specific IDs.

Coverage note: the page listing 10 advisories dated 2026-06-30 that this batch replaces was last captured in the change desk's source-watch on 2026-08-30 (per sourcechange-openclaw_security_advisories-f127e1a54ff1). The intervening 41 days are unexplained by the page itself; a future desk run that surfaces an "Affected Versions" field per advisory would close the gap.

Recommended action

For single-operator mr.technology-style installs (the most likely reader): 1. Confirm openclaw --version reports a 2026.8.x or 2026.9.x build. If yes, you are patched. If no, upgrade to 2026.9.8 (or 2026.8.35 for the LTS line). 2. Review your allow-always exec approvals and remove any that don't have a path scope. Post-2026.8.1 approvals should carry a path; pre-2026.8.1 approvals are left as dead records unless you remove them. 3. If you run the WhatsApp channel, confirm that the login tool is not in the channel's default tool list. If it is, restrict it to owner-only turns or remove it after setup.

For multi-tenant OpenClaw operators: 1. Audit the customer base for pinned 2026.7.x installs and schedule upgrades. 2. For the OpenAI-compatible transport item (GHSA-vhpg-cq3w-v8p9), set explicit base_url for every model catalog entry that talks to a third-party provider. 3. For the Unicode fallback item (GHSA-5rx7-34fw-64qg), audit the host filesystem for canonically equivalent sibling directory names within any customer's workspace. On APFS and ext4 with Unicode normalization, this is a real precondition.

For embedded appliances and compliance-pinned installs: 1. Read the full per-advisory detail page (linked below) for each of the ten GHSAs. 2. Plan the upgrade path against your compliance review cycle. The patched floor is 2026.8.1; the current stable is 2026.9.8; the current LTS is 2026.8.35. Any of those will close the advisories.

Recommended action ordering: upgrade first, then re-validate the two High-severity items against a non-owner turn test (WhatsApp) and a cwd-bound exec-approval test. The post-fix behavior should be observable; if it is not, file an issue against openclaw/openclaw with the advisory GHSA ID in the title.

Sources

Primary sources (all fetched 2026-10-04 14:09–14:10 UTC):

• https://github.com/openclaw/openclaw/security/advisories — the page listing all ten advisories (replaces the prior 10-advisory baseline dated 2026-06-30)
• https://github.com/openclaw/openclaw/security/advisories/GHSA-3mq7-q27j-mq7q — High-severity: Exec approvals could outlive their reviewed working directory
• https://github.com/openclaw/openclaw/security/advisories/GHSA-9m4p-cqp4-jppq — High-severity: WhatsApp login tool could reach non-owner turns
• https://github.com/openclaw/openclaw/security/advisories/GHSA-vhpg-cq3w-v8p9 — Moderate: OpenAI-compatible transport could send provider credentials to the wrong endpoint
• https://github.com/openclaw/openclaw/security/advisories/GHSA-5rx7-34fw-64qg — Moderate: Unicode fallback could escape workspaceOnly roots
• https://github.com/openclaw/openclaw/security/advisories/GHSA-rx8p-qcpv-c7vr — Moderate: Prometheus diagnostics could omit operator.read enforcement
• https://github.com/openclaw/openclaw/security/advisories/GHSA-xvwp-wmh2-fq48 — Moderate: Discord asset uploads could skip sender media policy
• https://github.com/openclaw/openclaw/security/advisories/GHSA-5j57-84cx-r295 — Moderate: iOS deep-link logs could expose unattended credentials
• https://github.com/openclaw/openclaw/security/advisories/GHSA-m78m-7h3q-q938 — Moderate: Browser relay authentication could exhaust shared pending capacity
• https://github.com/openclaw/openclaw/security/advisories/GHSA-7jfq-rmfm-29wp — Moderate: File-transfer approvals could widen durable authority
• https://github.com/openclaw/openclaw/security/advisories/GHSA-v7hh-7676-rg67 — Moderate: Slack file downloads could miss conversation authorization

Article history

• 2026-10-04 14:08 UTC — Originally published. Verified against the openclaw/openclaw security advisories page and four per-advisory detail pages, all fetched 2026-10-04 14:09–14:10 UTC. No corrections.