GHSA-4m3v-q747-pc6h: OpenClaw slash token

Q: Is GHSA-4m3v-q747-pc6h actively exploited?

No confirmed active exploitation of GHSA-4m3v-q747-pc6h has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-4m3v-q747-pc6h?

1) Upgrade to OpenClaw `2026.4.24` or later, where the patch closes the revocation lag. 2) Until patched, manually restart or refresh the Mattermost monitor immediately after any token rotation instead of relying on its normal refresh cycle. 3) Keep channel and tool allowlists narrow so even a stale token has minimal reachable capability. 4) Avoid sharing a single Gateway between mutually untrusted users. 5) Disable the Mattermost slash feature entirely if it isn't actively needed. 6) Detection: alert on slash command activity that occurs shortly after a token revocation/rotation event in your identity or Gateway audit logs, which would indicate the old token is still being honored.

Q: What systems are affected by GHSA-4m3v-q747-pc6h?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, chatops/messaging integrations.

Q: What is the CVSS score for GHSA-4m3v-q747-pc6h?

No CVSS score has been assigned yet.

CISO Take

This flaw lives in OpenClaw's Mattermost Gateway integration: when an operator revokes or rotates a slash command token, the change only takes effect after the background monitor refreshes, so a caller still holding the old token can keep triggering slash-command-driven agent actions during that window. The practical exposure is narrow — it only bites if a lower-trust or already-compromised token holder exists and the Mattermost slash feature is enabled and reachable, and there's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template, so this is not actively exploited or trivially weaponizable. It still matters operationally because token revocation is exactly the containment step a security team takes after suspecting compromise, and a stale-acceptance gap quietly undermines that response for an AI agent Gateway with 4 downstream dependents. Upgrade to `2026.4.24`; until then, manually restart or refresh the Mattermost monitor immediately after every token rotation and keep channel/tool allowlists narrow. For detection, audit slash command invocations occurring in the minutes right after a token revocation event for signs the old credential is still being honored.

Sources: GitHub Advisory ATLAS

What is the risk?

Medium severity as rated by the advisory, with no CVSS vector, no EPSS score, and no CISA KEV listing — there is no evidence of active exploitation or a public PoC/scanner template. Exploitability is constrained: an attacker needs to already possess a slash token that is in the process of being revoked (implying a prior compromise or insider misuse), and the exposure window is limited to the time before the Mattermost monitor refreshes. The blast radius is modest (4 downstream dependents), but the failure mode directly weakens an incident-response control (token revocation), which is a meaningful trust issue for any deployment relying on fast credential rotation to contain a breach.

How does the attack unfold?

Initial Access

Attacker obtains a valid Mattermost slash token for the OpenClaw Gateway, e.g. via leak, insider misuse, or prior compromise.

AML.T0012

Containment Attempt

Defenders detect the misuse and revoke/rotate the token, expecting the Gateway to immediately stop honoring it.

Stale Token Abuse

Because the monitor hasn't refreshed, the attacker keeps sending slash commands that the Gateway still accepts, invoking agent tool behavior.

AML.T0053

Impact

Attacker retains unauthorized command execution and potential data/tool access during what should have been a closed incident-response window.

AML.T0050

Initial Access

Attacker obtains a valid Mattermost slash token for the OpenClaw Gateway, e.g. via leak, insider misuse, or prior compromise.

AML.T0012

Containment Attempt

Defenders detect the misuse and revoke/rotate the token, expecting the Gateway to immediately stop honoring it.

Stale Token Abuse

Because the monitor hasn't refreshed, the attacker keeps sending slash commands that the Gateway still accepts, invoking agent tool behavior.

AML.T0053

Impact

Attacker retains unauthorized command execution and potential data/tool access during what should have been a closed incident-response window.

AML.T0050

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenClaw	npm	<= 2026.4.23	`2026.4.24`
4 dependents 41% 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

Trivial

What should I do?

1 step

1) Upgrade to OpenClaw 2026.4.24 or later, where the patch closes the revocation lag. 2) Until patched, manually restart or refresh the Mattermost monitor immediately after any token rotation instead of relying on its normal refresh cycle. 3) Keep channel and tool allowlists narrow so even a stale token has minimal reachable capability. 4) Avoid sharing a single Gateway between mutually untrusted users. 5) Disable the Mattermost slash feature entirely if it isn't actively needed. 6) Detection: alert on slash command activity that occurs shortly after a token revocation/rotation event in your identity or Gateway audit logs, which would indicate the old token is still being honored.

How is it classified?

Auth Bypass Agent Plugin AML.T0012 - Valid Accounts AML.T0053 - AI Agent Tool Invocation AML.T0091.000 - Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.2 - AI system operation and monitoring

NIST AI RMF

MANAGE 4.1 - AI risks and benefits are monitored and managed on an ongoing basis

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is GHSA-4m3v-q747-pc6h?

This flaw lives in OpenClaw's Mattermost Gateway integration: when an operator revokes or rotates a slash command token, the change only takes effect after the background monitor refreshes, so a caller still holding the old token can keep triggering slash-command-driven agent actions during that window. The practical exposure is narrow — it only bites if a lower-trust or already-compromised token holder exists and the Mattermost slash feature is enabled and reachable, and there's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template, so this is not actively exploited or trivially weaponizable. It still matters operationally because token revocation is exactly the containment step a security team takes after suspecting compromise, and a stale-acceptance gap quietly undermines that response for an AI agent Gateway with 4 downstream dependents. Upgrade to `2026.4.24`; until then, manually restart or refresh the Mattermost monitor immediately after every token rotation and keep channel/tool allowlists narrow. For detection, audit slash command invocations occurring in the minutes right after a token revocation event for signs the old credential is still being honored.

Is GHSA-4m3v-q747-pc6h actively exploited?

No confirmed active exploitation of GHSA-4m3v-q747-pc6h has been reported, but organizations should still patch proactively.

How to fix GHSA-4m3v-q747-pc6h?

1) Upgrade to OpenClaw `2026.4.24` or later, where the patch closes the revocation lag. 2) Until patched, manually restart or refresh the Mattermost monitor immediately after any token rotation instead of relying on its normal refresh cycle. 3) Keep channel and tool allowlists narrow so even a stale token has minimal reachable capability. 4) Avoid sharing a single Gateway between mutually untrusted users. 5) Disable the Mattermost slash feature entirely if it isn't actively needed. 6) Detection: alert on slash command activity that occurs shortly after a token revocation/rotation event in your identity or Gateway audit logs, which would indicate the old token is still being honored.

What systems are affected by GHSA-4m3v-q747-pc6h?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, chatops/messaging integrations.

What is the CVSS score for GHSA-4m3v-q747-pc6h?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworkschatops/messaging integrations

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0053 AI Agent Tool Invocation

AML.T0091.000 Application Access Token

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.2

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

### Summary Mattermost slash token revocation could lag until monitor refresh. In affected versions, a caller with an old Mattermost slash token during the refresh window could continue accepting the old token until the monitor refreshed. 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 invoke slash command behavior briefly after token revocation. 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.4.24`. ### Mitigations restart or refresh the Mattermost monitor after token rotation 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

A Mattermost slash token used to drive an OpenClaw agent leaks or is misused by an insider. The security team detects the anomaly and rotates/revokes the token as their containment step, expecting immediate effect. Because the Gateway's monitor hasn't refreshed yet, the attacker's old token continues to be accepted for a short window, letting them keep issuing slash commands that invoke agent tool actions — undermining the revocation the defenders believed had already cut off access, and potentially extending unauthorized command execution or data access during the incident response itself.

Weaknesses (CWE)

CWE-613 Insufficient Session Expiration Primary

CWE-613 — Insufficient Session Expiration: According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."