VULNpocalypse
HighVulnerabilityPatch available

Endor Labs reports OpenClaw apply_patch path traversal, fixed in 2026.2.14

Endor Labs reports a path traversal in OpenClaw apply_patch; the project advisory lists a fix in 2026.2.14, so upgrade openclaw.

Published
Fixed in
openclaw >= 2026.2.14 (per the OpenClaw GitHub advisories for the apply_patch, Gateway tool and Telnyx issues)
Exploitation
No. The sources report no in-the-wild exploitation; Endor Labs says it validated proof-of-concept exploits in its own testing.

Live scores

CVE-2026-26322
EPSS
0.004
low predicted chance of attack
VEDAS
0.878
likely exploited
On CISA KEV
Not listed
Detection rule
No public rule yet

Live scores

CVE-2026-26319
EPSS
0.003
low predicted chance of attack
VEDAS
0.814
likely exploited
On CISA KEV
Not listed
Detection rule
No public rule yet

Live scores

CVE-2026-26329
EPSS
0.005
low predicted chance of attack
VEDAS
0.804
likely exploited
On CISA KEV
Not listed
Detection rule
No public rule yet

What happened

According to Endor Labs, its AI SAST engine flagged seven vulnerabilities in OpenClaw, and the vendor’s researcher says each was validated with a working exploit. Endor Labs says the seventh finding is a path traversal in the apply_patch tool (GHSA-r5fq-947m-xm57) that allowed file writes and deletes outside the workspace. It rates the issue high severity (CVSS 8.8). These are Endor Labs’ claims; the OpenClaw project’s own GitHub advisory for the same issue is the primary source for affected and fixed versions.

According to the OpenClaw GitHub advisory, versions up to 2026.2.13 are affected when apply_patch is enabled and the agent runs without filesystem sandbox containment. The advisory says paths such as ../../... or absolute paths could escape the working directory, and that the practical impact depends on the deployment and on who can trigger tool execution. The advisory lists no CVE for this issue. It credits a reporter with the handle p80n-sec.

Endor Labs also claims the server-side bug is only reachable through the LLM, and that the model’s safety behaviour was the only runtime control in the non-sandboxed path. It says that in its testing 9 of 10 bypass strategies failed. It says one succeeded: injecting fabricated function_call and function_call_output history into the /v1/responses API input. Endor Labs notes that LLM results are non-deterministic and that repeated runs may differ. It says exploitation needs only a valid API Bearer token and apply_patch enabled, which it states is the default. The OpenClaw advisory does not describe the guardrail bypass.

Endor Labs’ companion post covers the other six findings. Its summary table lists:

  • Gateway Tool SSRF, CVE-2026-26322, High (CVSS 7.6).
  • Missing Telnyx webhook authentication, CVE-2026-26319, High (CVSS 7.5).
  • Path traversal in browser upload, CVE-2026-26329, High, no CVSS assigned.
  • An Urbit authentication SSRF, an Image tool SSRF and a Twilio webhook authentication bypass, each listed with no CVE ID.

For the Gateway tool SSRF and the Telnyx issue, the project’s advisories (Gateway, Telnyx) list the same affected range (<= 2026.2.13) and patched range (>= 2026.2.14). The Telnyx advisory marks the fixed version as planned.

Not confirmed in the sources: any exploitation outside Endor Labs’ testing, how reliably the guardrail bypass reproduces, and fixed versions for the browser upload, Urbit, Image tool and Twilio findings.

Am I affected?

You may be affected if you run the openclaw npm package at version 2026.2.13 or earlier.

  • apply_patch path traversal: per the OpenClaw advisory, this applies when apply_patch is enabled and the agent runs without sandbox containment. Endor Labs says non-sandboxed mode is the default when running openclaw gateway run natively outside Docker. It says Docker deployments with sandboxRoot configured blocked the traversal at the server layer in its testing.
  • Gateway tool SSRF: the advisory says this requires the ability to invoke tools that accept gatewayUrl overrides. It says this is typically limited to authenticated operators, trusted automation, or setups that expose tool calls to non-operators. It describes it as not a drive-by issue for arbitrary internet users unless a deployment allows untrusted users to trigger these tool calls.
  • Telnyx webhook: the advisory says this only affects deployments where the Voice Call plugin is installed and enabled, telnyx.publicKey is not configured, and the webhook endpoint is reachable by the caller.

What to do now

  1. Upgrade openclaw to 2026.2.14 or later, the patched range in the project advisories.
  2. If you do not need apply_patch, keep tools.exec.applyPatch.enabled disabled, as the advisory suggests.
  3. Check that tools.exec.applyPatch.workspaceOnly is at its default of true. The advisory notes that setting it to false opts out of workspace containment and can re-enable writes and deletes outside the workspace.
  4. Restrict who can trigger tool execution and which tools are allowlisted, per the advisory workarounds.
  5. If you use the Voice Call plugin, configure plugins.entries.voice-call.config.telnyx.publicKey (or TELNYX_PUBLIC_KEY) so signatures are verified. The advisory says skipSignatureVerification: true is for local development only.
  6. Do not rely on model refusals as a security boundary. This is Endor Labs’ stated conclusion, based on its testing, not a finding from the project advisory.

Sources