GHSA-c29c-2q9c-pc86: OpenClaw Slack allowFrom bypass

Q: Is GHSA-c29c-2q9c-pc86 actively exploited?

No confirmed active exploitation of GHSA-c29c-2q9c-pc86 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-c29c-2q9c-pc86?

Upgrade OpenClaw to 2026.5.3 or later, the first patched version. Until patched, reconfigure allowFrom policies to reference stable Slack user IDs instead of display names — display name matching should not be relied on for authorization. As general hardening: keep channel and tool allowlists as narrow as possible, avoid sharing a single Gateway instance between mutually untrusted users, and disable the Slack allowFrom feature entirely if it isn't required. For detection, audit Slack workspace admin logs for display-name changes that coincide with new or unexpected agent access, and review Gateway access logs for identity matches that don't correlate with the expected Slack user ID.

Q: What systems are affected by GHSA-c29c-2q9c-pc86?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent gateways, chat-integrated AI agents.

Q: What is the CVSS score for GHSA-c29c-2q9c-pc86?

No CVSS score has been assigned yet.

CISO Take

OpenClaw's Slack allowFrom feature authorizes access to the AI agent gateway by matching a Slack user's display name instead of a stable, unique Slack user ID — and display names are mutable, so any Slack account holder can rename themselves to match an entry on the allowlist and inherit that identity's agent access. There's no CVSS score, no EPSS percentile, no CISA KEV listing, no public exploit, and no Nuclei template for this yet, and only 4 downstream dependents are tracked, so this isn't a mass-exploitation risk today — but auth bypass by spoofing (CWE-290) in an agentic gateway is exactly the class of bug that turns a single misconfigured allowlist into unauthorized tool invocation on someone else's behalf. Exposure depends entirely on whether the operator enabled the Slack allowFrom feature and shares that Gateway with mutually untrusted Slack users; single-tenant, trusted-workspace deployments are effectively unaffected. Patch to 2026.5.3, and until then switch allowlist entries from display names to stable Slack user IDs, keep channel/tool allowlists narrow, and avoid sharing one Gateway across users who don't fully trust each other.

Sources: GitHub Advisory ATLAS

What is the risk?

Severity is rated high by the advisory but lacks a CVSS vector, EPSS score, KEV listing, or known exploitation activity, so treat this as a real but not urgent risk. Exploitability is low-complexity once preconditions are met (attacker needs an existing Slack account in the same workspace and the allowFrom feature enabled and reachable) but the precondition itself limits blast radius to shared/multi-tenant Gateway deployments. Impact is significant where it applies: successful spoofing grants the attacker whatever agent access and tool permissions were scoped to the impersonated identity, which in an agentic system can mean data access or mutative tool calls, not just a passive read.

How does the attack unfold?

Initial Access

Attacker with an existing Slack account in the target workspace changes their display name to match an identity listed in the Gateway's allowFrom policy.

AML.T0073

Authorization Bypass

Attacker messages the OpenClaw Slack Gateway; the allowFrom check matches on the spoofed mutable display name and grants access intended for the impersonated identity.

AML.T0107

Impact

Attacker invokes the AI agent's tools and accesses data scoped to the impersonated identity, potentially exfiltrating information or triggering unauthorized privileged actions.

AML.T0053

Initial Access

Attacker with an existing Slack account in the target workspace changes their display name to match an identity listed in the Gateway's allowFrom policy.

AML.T0073

Authorization Bypass

Attacker messages the OpenClaw Slack Gateway; the allowFrom check matches on the spoofed mutable display name and grants access intended for the impersonated identity.

AML.T0107

Impact

Attacker invokes the AI agent's tools and accesses data scoped to the impersonated identity, potentially exfiltrating information or triggering unauthorized privileged actions.

AML.T0053

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenClaw	npm	<= 2026.5.3-1	`2026.5.3`
3 dependents 37% patched ~3d to patch Full package profile →
OpenClaw	pip	—	No patch
3 dependents 37% patched ~3d to patch Full package profile →

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

Upgrade OpenClaw to 2026.5.3 or later, the first patched version. Until patched, reconfigure allowFrom policies to reference stable Slack user IDs instead of display names — display name matching should not be relied on for authorization. As general hardening: keep channel and tool allowlists as narrow as possible, avoid sharing a single Gateway instance between mutually untrusted users, and disable the Slack allowFrom feature entirely if it isn't required. For detection, audit Slack workspace admin logs for display-name changes that coincide with new or unexpected agent access, and review Gateway access logs for identity matches that don't correlate with the expected Slack user ID.

How is it classified?

Auth Bypass Agent Plugin AML.T0053 - AI Agent Tool Invocation AML.T0073 - Impersonation AML.T0107 - Exploitation for Defense Evasion

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MANAGE-4.1 - Post-deployment monitoring for AI system risks including unauthorized access

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is GHSA-c29c-2q9c-pc86?

OpenClaw's Slack allowFrom feature authorizes access to the AI agent gateway by matching a Slack user's display name instead of a stable, unique Slack user ID — and display names are mutable, so any Slack account holder can rename themselves to match an entry on the allowlist and inherit that identity's agent access. There's no CVSS score, no EPSS percentile, no CISA KEV listing, no public exploit, and no Nuclei template for this yet, and only 4 downstream dependents are tracked, so this isn't a mass-exploitation risk today — but auth bypass by spoofing (CWE-290) in an agentic gateway is exactly the class of bug that turns a single misconfigured allowlist into unauthorized tool invocation on someone else's behalf. Exposure depends entirely on whether the operator enabled the Slack allowFrom feature and shares that Gateway with mutually untrusted Slack users; single-tenant, trusted-workspace deployments are effectively unaffected. Patch to 2026.5.3, and until then switch allowlist entries from display names to stable Slack user IDs, keep channel/tool allowlists narrow, and avoid sharing one Gateway across users who don't fully trust each other.

Is GHSA-c29c-2q9c-pc86 actively exploited?

No confirmed active exploitation of GHSA-c29c-2q9c-pc86 has been reported, but organizations should still patch proactively.

How to fix GHSA-c29c-2q9c-pc86?

Upgrade OpenClaw to 2026.5.3 or later, the first patched version. Until patched, reconfigure allowFrom policies to reference stable Slack user IDs instead of display names — display name matching should not be relied on for authorization. As general hardening: keep channel and tool allowlists as narrow as possible, avoid sharing a single Gateway instance between mutually untrusted users, and disable the Slack allowFrom feature entirely if it isn't required. For detection, audit Slack workspace admin logs for display-name changes that coincide with new or unexpected agent access, and review Gateway access logs for identity matches that don't correlate with the expected Slack user ID.

What systems are affected by GHSA-c29c-2q9c-pc86?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent gateways, chat-integrated AI agents.

What is the CVSS score for GHSA-c29c-2q9c-pc86?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI agent gatewayschat-integrated AI agents

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

AML.T0073 Impersonation

AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

### Summary Slack allowFrom could bind to mutable display names. In affected versions, a Slack account able to change display name metadata could match a policy entry through mutable display metadata. 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 receive agent access intended for another Slack identity. 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.3`. ### Mitigations use stable Slack user IDs in allowlists 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 attacker who already holds a low-privilege Slack account inside the same workspace as the OpenClaw Gateway — an insider, a compromised guest account, or a malicious contractor — renames their Slack display name to exactly match the display name of a user listed in the Gateway's allowFrom policy (e.g., a senior engineer or admin authorized to trigger agent actions). The attacker then messages the Gateway; because the policy check binds to the mutable display-name field rather than the stable Slack user ID, the Gateway treats the attacker as the impersonated identity and grants the associated agent access. The attacker can now invoke whatever tools and data access the agent grants that identity — reading internal data the agent can reach, triggering privileged agent actions, or using the agent as a pivot into other connected systems — all under a legitimate-looking identity, complicating incident attribution.

Weaknesses (CWE)

CWE-290 Authentication Bypass by Spoofing Primary

CWE-290 — Authentication Bypass by Spoofing: This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

Source: MITRE CWE corpus.