GHSA-wv26-j37q-2g7p: OpenClaw exec approver can

Q: Is GHSA-wv26-j37q-2g7p actively exploited?

No confirmed active exploitation of GHSA-wv26-j37q-2g7p has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-wv26-j37q-2g7p?

1) Upgrade the `openclaw` npm package to `2026.5.12` or later, which fixes the shared-gate flaw. 2) Until patched, manually review all Slack-resolved plugin approvals for anomalies — specifically approvals coming from identities provisioned only as exec approvers. 3) Keep exec and plugin approval allowlists tightly scoped and non-overlapping. 4) Avoid sharing a single Gateway between mutually untrusted user populations. 5) Disable the Slack plugin-approval feature entirely if it isn't actively required. 6) As general hardening, keep channel/tool allowlists narrow and audit approval logs periodically for role-boundary violations.

Q: What systems are affected by GHSA-wv26-j37q-2g7p?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent tool governance / approval workflows, plugin/tool ecosystems.

Q: What is the CVSS score for GHSA-wv26-j37q-2g7p?

No CVSS score has been assigned yet.

CISO Take

OpenClaw's Slack-based approval workflow was supposed to keep two governance tiers separate — one Slack role approves risky exec (command) actions, a distinct role approves plugin actions — but both routed through the same exec approver gate, letting someone authorized for only one tier resolve approvals for the other. This matters because it defeats an intentional dual-control safeguard operators put in place specifically to segregate duties around agentic tool execution, not just a cosmetic access-control glitch. There's no CVSS score, no EPSS data, no public exploit or Nuclei template, and it isn't in CISA KEV, so this looks like a low-noise, disclosure-driven fix rather than something under active exploitation — but the downstream blast radius (4 dependents) and the fact OpenClaw's own third-party skill ecosystem has a documented malicious-plugin problem (see AIID #1368) raise the stakes of any approval-gate confusion. Patch to `2026.5.12` now; until then, manually review every Slack-resolved plugin approval and keep exec/plugin approver allowlists strictly separated and narrow.

Sources: GitHub Advisory CISA KEV ATLAS

What is the risk?

Medium risk in practice: exploitation requires the attacker to already hold a legitimate Slack identity provisioned as an exec approver, so this is a privilege-boundary failure between two trusted roles rather than an externally reachable bug — attack complexity for someone already in that position is low, since the flawed gate accepts their approval by default. Impact is scoped to the operator's intended approval segregation rather than full system takeover: it only matters where the feature is enabled and where exec-approver and plugin-approver populations are meant to be non-overlapping (e.g., mutually untrusted teams sharing one Gateway). No CVSS vector, EPSS score, KEV listing, or public PoC exists, so near-term opportunistic exploitation is unlikely; the real risk is quiet insider misuse or a compromised approver account being used to rubber-stamp plugin actions it was never meant to authorize.

How does the attack unfold?

Initial Access

Actor holds a legitimate Slack identity provisioned only as an exec approver, per the operator's intended role segregation.

AML.T0012

Authorization Bypass

Actor resolves a plugin approval request, which incorrectly routes through the same exec approver gate instead of a distinct plugin-approval check.

Plugin Action Execution

The approved plugin action (e.g., a ClawHub skill invocation) executes with the trust conferred by a valid-looking approval, despite the approver lacking that authority.

AML.T0053

Impact

The intended dual-control separation between exec and plugin approvals is defeated, allowing unauthorized plugin actions within the operator's OpenClaw environment.

Initial Access

Actor holds a legitimate Slack identity provisioned only as an exec approver, per the operator's intended role segregation.

AML.T0012

Authorization Bypass

Actor resolves a plugin approval request, which incorrectly routes through the same exec approver gate instead of a distinct plugin-approval check.

Plugin Action Execution

The approved plugin action (e.g., a ClawHub skill invocation) executes with the trust conferred by a valid-looking approval, despite the approver lacking that authority.

AML.T0053

Impact

The intended dual-control separation between exec and plugin approvals is defeated, allowing unauthorized plugin actions within the operator's OpenClaw environment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenClaw	npm	< 2026.5.12	`2026.5.12`
3 dependents 37% patched ~3d to patch Full package profile →

Do you use OpenClaw? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

1) Upgrade the openclaw npm package to 2026.5.12 or later, which fixes the shared-gate flaw. 2) Until patched, manually review all Slack-resolved plugin approvals for anomalies — specifically approvals coming from identities provisioned only as exec approvers. 3) Keep exec and plugin approval allowlists tightly scoped and non-overlapping. 4) Avoid sharing a single Gateway between mutually untrusted user populations. 5) Disable the Slack plugin-approval feature entirely if it isn't actively required. 6) As general hardening, keep channel/tool allowlists narrow and audit approval logs periodically for role-boundary violations.

How is it classified?

Auth Bypass Code Execution Agent Plugin AML.T0012 - Valid Accounts AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 14 - Human oversight

ISO 42001

A.9.2 - Human oversight of AI system operation

NIST AI RMF

GOVERN 1.5 - Accountability structures and access control for AI actors

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is GHSA-wv26-j37q-2g7p?

OpenClaw's Slack-based approval workflow was supposed to keep two governance tiers separate — one Slack role approves risky exec (command) actions, a distinct role approves plugin actions — but both routed through the same exec approver gate, letting someone authorized for only one tier resolve approvals for the other. This matters because it defeats an intentional dual-control safeguard operators put in place specifically to segregate duties around agentic tool execution, not just a cosmetic access-control glitch. There's no CVSS score, no EPSS data, no public exploit or Nuclei template, and it isn't in CISA KEV, so this looks like a low-noise, disclosure-driven fix rather than something under active exploitation — but the downstream blast radius (4 dependents) and the fact OpenClaw's own third-party skill ecosystem has a documented malicious-plugin problem (see AIID #1368) raise the stakes of any approval-gate confusion. Patch to `2026.5.12` now; until then, manually review every Slack-resolved plugin approval and keep exec/plugin approver allowlists strictly separated and narrow.

Is GHSA-wv26-j37q-2g7p actively exploited?

No confirmed active exploitation of GHSA-wv26-j37q-2g7p has been reported, but organizations should still patch proactively.

How to fix GHSA-wv26-j37q-2g7p?

1) Upgrade the `openclaw` npm package to `2026.5.12` or later, which fixes the shared-gate flaw. 2) Until patched, manually review all Slack-resolved plugin approvals for anomalies — specifically approvals coming from identities provisioned only as exec approvers. 3) Keep exec and plugin approval allowlists tightly scoped and non-overlapping. 4) Avoid sharing a single Gateway between mutually untrusted user populations. 5) Disable the Slack plugin-approval feature entirely if it isn't actively required. 6) As general hardening, keep channel/tool allowlists narrow and audit approval logs periodically for role-boundary violations.

What systems are affected by GHSA-wv26-j37q-2g7p?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent tool governance / approval workflows, plugin/tool ecosystems.

What is the CVSS score for GHSA-wv26-j37q-2g7p?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI agent tool governance / approval workflowsplugin/tool ecosystems

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 14

ISO 42001: A.9.2

NIST AI RMF: GOVERN 1.5

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

### Summary Slack plugin approvals used the exec approver gate for plugin actions. In affected versions, a Slack user authorized only for exec approvals could resolve a plugin approval through the exec approver gate. 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 approve a plugin action outside the operator's intended approval split. 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.5.12`. ### Mitigations keep approval allowlists aligned and review Slack approval actions manually 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 organization runs OpenClaw's Gateway with Slack-based dual-control approvals: security-sensitive exec (command execution) actions require sign-off from one group, while lower-trust plugin actions require sign-off from a separate group — intentionally, so no single role can authorize everything. A user (or compromised Slack account) holding only exec-approver rights discovers that plugin approval requests also resolve through the same exec approver gate. They approve a plugin action they were never authorized to sign off on — for example, greenlighting a ClawHub skill install or invocation, a category where independent researchers have already found roughly 17% of sampled skills to be malicious (AIID #1368). The plugin then executes with the trust conferred by a legitimate-looking approval, even though the intended segregation-of-duties control was bypassed, letting an under-privileged approver enable agent tool actions outside their granted authority.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[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.