CVE-2026-45005: Openclaw Auth Bypass Vulnerability

CVE-2026-45005 Overview

CVE-2026-45005 affects OpenClaw versions before 2026.4.23. The flaw resides in the webhook route authentication layer, where resolved secrets backed by SecretRef values are cached in memory. When operators rotate a secret and reload configuration, the cached value remains valid until the gateway or plugin process restarts. Attackers holding previously valid webhook route secrets can continue authenticating requests and invoking configured webhook task flows. The weakness is classified under CWE-672: Operation on a Resource after Expiration or Release.

Critical Impact

Rotated webhook secrets remain valid in cache, allowing attackers with stolen credentials to continue invoking webhook task flows until the OpenClaw gateway or plugin is restarted.

Affected Products

• OpenClaw (Node.js distribution) versions prior to 2026.4.23
• OpenClaw webhooks extension (extensions/webhooks)
• Deployments using SecretRef-backed webhook route secrets

Discovery Timeline

• 2026-05-11 - CVE-2026-45005 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-45005

Vulnerability Analysis

The vulnerability stems from an in-memory cache that holds resolved webhook route secrets for the lifetime of the request handler. In the affected extensions/webhooks/src/http.ts module, a WeakMap<TaskFlowWebhookTarget, Promise<string | undefined>> named secretByTarget stores the first resolved secret for each target. Subsequent requests reuse the cached promise rather than re-resolving the underlying SecretRef.

When administrators rotate a compromised secret in the secret store and trigger a configuration reload, the cache is not invalidated. The new secret is never consulted because the route handler short-circuits on the cached value. As a result, an attacker holding a previously valid token can continue invoking webhook task flows and authenticate requests as if rotation never occurred.

Exploitation requires high privileges (PR:H) because the attacker must already possess a valid webhook secret. However, the integrity impact is high (VI:H) since attackers can invoke arbitrary configured task flows, including state-changing operations exposed through webhook routes.

Root Cause

The root cause is improper cache invalidation on credential rotation. The secret resolution logic treated SecretRef lookups as immutable for the lifetime of the process. Configuration reloads updated route metadata but did not clear the per-target secret cache, leaving stale credentials authoritative until restart.

Attack Vector

An attacker with a previously valid webhook secret sends an HTTP request to the OpenClaw webhook endpoint. The route handler validates the supplied secret against the cached value rather than the rotated value in the secret store. The request is authenticated, and the configured task flow executes. The vector is network-accessible (AV:N) and requires no user interaction (UI:N).

// Patched code from extensions/webhooks/src/http.ts
// fix(webhooks): reload route secrets per request (#70727)
   targetsByPath: Map<string, TaskFlowWebhookTarget[]>;
   inFlightLimiter?: WebhookInFlightLimiter;
 }): (req: IncomingMessage, res: ServerResponse) => Promise<boolean> {
-  const secretByTarget = new WeakMap<TaskFlowWebhookTarget, Promise<string | undefined>>();
   const rateLimiter = createFixedWindowRateLimiter({
     windowMs: WEBHOOK_RATE_LIMIT_DEFAULTS.windowMs,
     maxRequests: WEBHOOK_RATE_LIMIT_DEFAULTS.maxRequests,

Source: OpenClaw GitHub commit 36c4a37 — the patch removes the per-target WeakMap cache so each request re-resolves the SecretRef.

Detection Methods for CVE-2026-45005

Indicators of Compromise

• Successful webhook authentications using secret values that were marked rotated or revoked in the secret store audit log.
• Webhook task flow invocations originating from source IPs not seen since before the most recent secret rotation event.
• Discrepancies between secret store getSecret audit events and OpenClaw webhook authentication counts after a reload.

Detection Strategies

• Correlate secret rotation timestamps in the backing secret store with subsequent successful webhook authentications in OpenClaw access logs.
• Alert when any webhook request authenticates with a credential hash that does not match the current value in the secret store.
• Hunt for long-lived webhook client sessions that span across known configuration reload events without a corresponding process restart.

Monitoring Recommendations

• Forward OpenClaw gateway and extensions/webhooks logs to a centralized SIEM and parse authentication outcomes per route.
• Enable audit logging on the upstream secret store (e.g., Vault, Kubernetes Secrets) and join those events with webhook request logs.
• Monitor process uptime for the OpenClaw gateway and plugin host; flag rotations that occur without a subsequent restart within the operator-defined window.

How to Mitigate CVE-2026-45005

Immediate Actions Required

• Upgrade OpenClaw to version 2026.4.23 or later, which removes the secretByTarget cache and re-resolves secrets per request.
• Restart the OpenClaw gateway and any plugin processes immediately after rotating any webhook route secret, even on patched builds, to ensure no stale state remains.
• Rotate all webhook route secrets that were previously rotated on vulnerable versions, as prior rotations may not have taken effect.

Patch Information

The fix is delivered in commit 36c4a372a0ad5dca8bfc0d93f7aab9c2f2de66fa and documented in the OpenClaw GHSA-q8ff-7ffm-m3r9 advisory. The patch removes the per-target WeakMap cache so each incoming request re-resolves the SecretRef. See the VulnCheck advisory for additional context.

Workarounds

• Restart the OpenClaw gateway and plugin processes after every webhook secret rotation to forcibly clear the in-memory cache.
• Restrict network access to webhook endpoints using upstream allowlists so that stolen secrets cannot be replayed from unauthorized networks.
• Treat webhook secrets as short-lived and pair rotation with explicit revocation checks at an upstream proxy where feasible.

# Restart OpenClaw after rotating a webhook SecretRef (Kubernetes example)
kubectl rollout restart deployment/openclaw-gateway -n openclaw
kubectl rollout status deployment/openclaw-gateway -n openclaw

# Verify the running version is patched
kubectl exec -n openclaw deploy/openclaw-gateway -- \
  node -e "console.log(require('./package.json').version)"
# Expect: 2026.4.23 or later