AI Threat Alert
GHSA-w8wf-3qvj-6xqf: OpenClaw Feishu: authz bypass skips account disablement
GHSA-w8wf-3qvj-6xqf HIGHA high-severity authorization flaw (CVSS 8.1) in OpenClaw's Feishu (Lark) integration lets a lower-trust caller or a configured input path invoke permission-gated actions that should have been blocked by per-account disablement, effectively bypassing a policy control rather than requiring credential theft. There's no public exploit or scanner template yet and it isn't in CISA KEV, but the vulnerability class — incorrect authorization (CWE-863) inside an AI agent's tool-permission layer — is exactly the kind of gap that undermines least-privilege assumptions in agent gateways shared across teams. Blast radius is currently modest (3 known downstream dependents), but any deployment sharing one OpenClaw Gateway between mutually untrusted users or channels with the Feishu feature enabled is exposed. Upgrade to 2026.6.9 immediately; until then, disable the Feishu permission-tool feature or restrict it to trusted operators and keep channel/tool allowlists narrow. Audit logs for any Feishu-tool actions performed by accounts that were supposed to be disabled, since that's the concrete signature of exploitation.
What is the risk?
CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) reflects a network-exploitable, low-complexity flaw requiring only low privileges and no user interaction, with high confidentiality and integrity impact but no availability impact. Exploitability is currently theoretical — no EPSS score, no public exploit, no Nuclei template, not in CISA KEV — but the low attack complexity and lack of required user interaction mean weaponization would be straightforward once the specific bypass path is understood. Real-world risk is highly configuration-dependent: it only matters if the affected Feishu permission-tool feature is enabled and reachable by a lower-trust caller, which is common in shared-Gateway deployments (e.g., a single OpenClaw instance serving multiple teams or external-facing channels).
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| OpenClaw | npm | < 2026.6.9-beta.1 | 2026.6.9 |
Do you use OpenClaw? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade @openclaw/feishu to 2026.6.9 or later, where the authorization check has been patched (see commit d4f11d3). If immediate patching isn't possible, disable the affected Feishu permission-tool feature entirely, or restrict it to trusted operators only. Do not share one Gateway instance between mutually untrusted users while this feature is enabled. Tighten channel and tool allowlists to minimize which callers can reach the affected path. For detection, review OpenClaw/Feishu tool-invocation logs for actions performed by accounts flagged as disabled, and alert on any policy-check bypass indicators once patched logging is in place.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-w8wf-3qvj-6xqf?
A high-severity authorization flaw (CVSS 8.1) in OpenClaw's Feishu (Lark) integration lets a lower-trust caller or a configured input path invoke permission-gated actions that should have been blocked by per-account disablement, effectively bypassing a policy control rather than requiring credential theft. There's no public exploit or scanner template yet and it isn't in CISA KEV, but the vulnerability class — incorrect authorization (CWE-863) inside an AI agent's tool-permission layer — is exactly the kind of gap that undermines least-privilege assumptions in agent gateways shared across teams. Blast radius is currently modest (3 known downstream dependents), but any deployment sharing one OpenClaw Gateway between mutually untrusted users or channels with the Feishu feature enabled is exposed. Upgrade to 2026.6.9 immediately; until then, disable the Feishu permission-tool feature or restrict it to trusted operators and keep channel/tool allowlists narrow. Audit logs for any Feishu-tool actions performed by accounts that were supposed to be disabled, since that's the concrete signature of exploitation.
Is GHSA-w8wf-3qvj-6xqf actively exploited?
No confirmed active exploitation of GHSA-w8wf-3qvj-6xqf has been reported, but organizations should still patch proactively.
How to fix GHSA-w8wf-3qvj-6xqf?
Upgrade @openclaw/feishu to 2026.6.9 or later, where the authorization check has been patched (see commit d4f11d3). If immediate patching isn't possible, disable the affected Feishu permission-tool feature entirely, or restrict it to trusted operators only. Do not share one Gateway instance between mutually untrusted users while this feature is enabled. Tighten channel and tool allowlists to minimize which callers can reach the affected path. For detection, review OpenClaw/Feishu tool-invocation logs for actions performed by accounts flagged as disabled, and alert on any policy-check bypass indicators once patched logging is in place.
What systems are affected by GHSA-w8wf-3qvj-6xqf?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent gateways, plugin/tool integrations.
What is the CVSS score for GHSA-w8wf-3qvj-6xqf?
GHSA-w8wf-3qvj-6xqf has a CVSS v3.1 base score of 8.1 (HIGH).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0053 AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary Feishu permission tools could ignore per-account disablement. In affected versions, a lower-trust caller or configured input path could perform actions that should have required a stronger authorization or policy check. 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 perform actions that should have required a stronger authorization or policy check. 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.6.9`. ### Mitigations Upgrade to a patched OpenClaw release when one is listed. Before upgrading, restrict the affected feature to trusted operators or disable it when it is not needed. 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 a shared OpenClaw Gateway with the Feishu integration enabled, serving multiple teams with mixed trust levels. An administrator disables Feishu permissions for a specific lower-trust account (e.g., a contractor or a lower-privilege bot integration) expecting that control to be enforced. Due to the incorrect authorization check, that account — or a configured input path reachable by it — can still invoke Feishu permission tools, performing actions like sending messages, reading channel data, or triggering workflows that should have required elevated approval. Because the exploit needs only low privileges and no user interaction, an attacker who has already obtained low-tier access to the Gateway (e.g., via a compromised low-trust plugin or account) can escalate their effective reach within the Feishu integration without needing to steal higher-privileged credentials.
Weaknesses (CWE)
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.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/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-32038 9.8 OpenClaw: sandbox bypass enables container lateral movement
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