Is there a patch available for EUVD-2026-36618?

Yes, a patch is available for EUVD-2026-36618. Update the affected software to the latest version immediately.

OpenClaw EUVD-2026-36618

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

EUVD-2026-36618 has a CVSS 4.0 base score of 6.0 (Medium). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/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-53830 MEDIUM

Insufficient Session Expiration (CWE-613)

2026-06-12 VulnCheck

GHSA-p68j-q8j9-jwf5

Authentication Bypass Openclaw

6.0

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

6.0 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/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

6.5 MEDIUM

PR:L reflects required prior possession of a webhook secret; VI:H captures full integrity compromise via unauthorized event injection; no confidentiality or availability impact applies.

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

4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/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:P/PR:L/UI:N/VC:N/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:43 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

1 npm packages depend on openclaw (1 direct, 0 indirect)

Ecosystem-wide dependent count for version 2026.4.22.

DescriptionCVE.org

OpenClaw before 2026.4.22 contains a webhook secret revocation bypass vulnerability allowing callers with old Slack and Zalo webhook secrets to remain active after secrets.reload. Attackers can exploit the stale-secret window to deliver webhook events after operator-expected secret revocation, potentially accepting previous credentials.

AnalysisAI

Webhook secret revocation bypass in OpenClaw before 2026.4.22 allows callers possessing previously-issued Slack and Zalo webhook secrets to continue submitting accepted events after an operator invokes the secrets.reload function. The stale-secret acceptance window undermines the integrity guarantees of secret rotation, enabling unauthorized webhook payload injection into what operators believe is a secured endpoint. No public exploit has been identified at time of analysis, and active exploitation has not been confirmed by CISA KEV; however, the integrity impact is rated high per the CVSS 4.0 vector.

Technical ContextAI

OpenClaw (CPE: cpe:2.3:a:openclaw:openclaw:*:*:*:*:*:*:*:*) is a webhook management platform integrating with Slack and Zalo messaging services. Webhook secrets function as HMAC-style authentication tokens that validate the legitimacy of incoming webhook payloads - they are the primary trust anchor for verifying that an event originates from an authorized source. The root cause maps to CWE-613 (Insufficient Session Expiration): the secrets.reload operation, which operators invoke to rotate credentials, fails to atomically propagate revocation to the validation layer. As a result, the old secret remains accepted for an undefined stale window post-rotation. This is a classic credential lifecycle management failure - the revocation signal and the enforcement boundary are not synchronized, creating a TOCTOU-adjacent condition in the secret validity check.

RemediationAI

Upgrade OpenClaw to version 2026.4.22 or later, which resolves the stale-secret acceptance window in the secrets.reload mechanism per the vendor advisory at https://github.com/openclaw/openclaw/security/advisories/GHSA-275c-xpvc-jgfw. If an immediate upgrade is not possible, operators should treat all previously issued Slack and Zalo webhook secrets as permanently compromised and generate entirely new secrets rather than relying on secrets.reload alone. As a compensating control, restrict network-level access to the webhook endpoint by allowlisting known Slack and Zalo source IP ranges, which limits the pool of callers who could exploit stale credentials; note that this may cause legitimate delivery failures if provider IP ranges change. Additionally, enable webhook payload audit logging and monitor for events bearing characteristics of previously rotated secrets (e.g., divergent signature patterns) to detect exploitation attempts during any residual acceptance window.