Which versions of OpenClaw are affected by EUVD-2026-36611?

OpenClaw's Slack authentication mechanism incorrectly binds access to mutable display names rather than stable user IDs, enabling attackers with Slack account access to impersonate other users and…. A patch is available.

How to fix or mitigate EUVD-2026-36611?

Within 24 hours: Document all OpenClaw deployments and current versions in your environment. Within 7 days: Implement Slack workspace policies restricting display name modifications for users with agent access, and evaluate upgrade path to OpenClaw version 2026.5.3. Within 30 days: Complete migration to patched version and deploy monitoring for suspicious display name changes that match allowFrom policy entries.

OpenClaw EUVD-2026-36611

Q: What is the CVSS score of EUVD-2026-36611?

EUVD-2026-36611 has a CVSS 4.0 base score of 8.6 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

| CVE-2026-53823 HIGH

Authentication Bypass by Spoofing (CWE-290)

2026-06-12 VulnCheck

GHSA-rqpg-f8j3-2gm3

Privilege Escalation Authentication Bypass Openclaw

8.6

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

8.6 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.1 HIGH

Network-reachable Slack integration, low complexity (edit a profile field), requires a Slack account so PR:L, no user interaction, high confidentiality/integrity from impersonated agent access, no availability impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jun 13, 2026 - 02:00 EUVD

Analysis Generated

Jun 12, 2026 - 22:31 vuln.today

DescriptionCVE.org

OpenClaw before 2026.5.3 contains a privilege escalation vulnerability in the allowFrom feature that binds to mutable Slack display names. Attackers with Slack account access can change display name metadata to match policy entries, potentially gaining unauthorized agent access intended for other identities.

AnalysisAI

Privilege escalation in OpenClaw before 2026.5.3 allows attackers with access to a Slack account to spoof identity by changing their mutable Slack display name to match an allowFrom policy entry, gaining agent access intended for another user. The root cause is authentication binding to a mutable identifier (CWE-290) rather than a stable Slack user ID. No public exploit identified at time of analysis, though an upstream advisory (GHSA-c29c-2q9c-pc86) and VulnCheck writeup describe the flaw in detail.

Technical ContextAI

OpenClaw's allowFrom access control feature enforces policy by matching the Slack display name attached to incoming requests against an allowlist. Slack display names are user-editable metadata, not stable identifiers - only the immutable Slack user ID (Uxxxxx) should be trusted for authorization decisions. This is a textbook CWE-290 (Authentication Bypass by Spoofing) issue: the policy decision point binds to data the principal controls. The affected product is openclaw:openclaw (per CPE) across all versions prior to 2026.5.3.

RemediationAI

Vendor-released patch: upgrade OpenClaw to 2026.5.3 or later per the GHSA-c29c-2q9c-pc86 advisory (https://github.com/openclaw/openclaw/security/advisories/GHSA-c29c-2q9c-pc86). If immediate upgrade is not possible, the primary compensating control is to rewrite allowFrom policy entries to reference immutable Slack user IDs (the Uxxxxxxx form) rather than display names where the implementation permits, or remove allowFrom rules and gate agent access behind a separate IdP-backed authentication path until the fix is deployed; both options shrink the impersonation surface but the display-name rewrite still depends on OpenClaw correctly parsing user IDs in the unpatched code path, so verify behavior against the advisory before relying on it. Additionally tighten Slack workspace controls - restrict display-name changes via Slack admin policy and audit recent display-name edits - which reduces but does not eliminate the bug since any authorized user can still match a policy entry.