deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-jfv4-h8mc-jcp8
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-283: Unverified Ownership
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw: Process Safety - Unvalidated PID Kill via SIGKILL in Process Cleanup

Details:
## Summary

OpenClaw CLI process cleanup used system-wide process enumeration and pattern matching to terminate processes without verifying they were owned by the current OpenClaw process. On shared hosts, unrelated processes could be terminated if they matched the pattern.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `< 2026.2.14` (including the latest published version `2026.2.13`)
- Fixed: `2026.2.14` (planned next release)

## Details

The CLI runner cleanup helpers could kill processes matched by command-line patterns without validating process ownership.

## Fix

Process cleanup is now scoped to owned processes only by filtering to direct child PIDs of the current process (`ppid == process.pid`) before sending signals.

Hardening follow-ups:
- Prefer graceful termination for resume cleanup (`SIGTERM`, then `SIGKILL` fallback).
- Reduce false negatives from `ps` argv truncation by preferring wide output (`ps -axww`) with a fallback.
- Tighten command-line token matching to avoid substring matches.

## Fix Commit(s)

- 6084d13b956119e3cf95daaf9a1cae1670ea3557
- eb60e2e1b213740c3c587a7ba4dbf10da620ca66

## Release Process Note

This advisory is pre-set with patched version `2026.2.14`. After `2026.2.14` is published to npm, the remaining step should be to publish this advisory.

Thanks @aether-ai-agent for reporting.
GitHub Security Advisory: GHSA-7rcp-mxpq-72pj
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw Chutes manual OAuth state validation bypass can cause credential substitution

Details:
## Summary

The manual Chutes OAuth login flow could accept attacker-controlled callback input in a way that bypassed OAuth CSRF state validation, potentially resulting in credential substitution.

## Impact

If an attacker can convince a user to paste attacker-provided OAuth callback data during the manual login prompt, OpenClaw may exchange an attacker-obtained authorization code and persist tokens for the wrong Chutes account.

The automatic local callback flow is not affected (it validates state in the local HTTP callback handler).

## Affected Packages / Versions

- `openclaw` (npm): `<= 2026.2.13` when using the manual Chutes OAuth login flow.

## Fix

The manual flow now requires the full redirect URL (must include `code` and `state`), validates the returned `state` against the expected value, and rejects code-only pastes.

## Fix Commit(s)

- a99ad11a4107ba8eac58f54a3c1a8a0cf5686f47

Thanks @aether-ai-agent for reporting.
GitHub Security Advisory: GHSA-4564-pvr2-qq4h
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.6)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw: Prevent shell injection in macOS keychain credential write

Details:
## Summary
On macOS, the Claude CLI keychain credential refresh path constructed a shell command to write the updated JSON blob into Keychain via `security add-generic-password -w ...`. Because OAuth tokens are user-controlled data, this created an OS command injection risk.

The fix avoids invoking a shell by using `execFileSync("security", argv)` and passing the updated keychain payload as a literal argument.

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Platform: macOS only
- Affected versions: `<= 2026.2.13`

## Fix
- Patched version: `>= 2026.2.14` (next release)
- Fix PR: #15924
- Fix commits (merged to `main`):
  - `9dce3d8bf83f13c067bc3c32291643d2f1f10a06`
  - `66d7178f2d6f9d60abad35797f97f3e61389b70c`
  - `b[PII_REDACTED]64fb3586859f44d1dff5372b19caf`

Thanks @aether-ai-agent for reporting.
GitHub Security Advisory: GHSA-gq9c-wg68-gwj2
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2026.2.13
Patched in: 2026.2.13

Summary: OpenClaw has a path traversal in browser trace/download output paths may allow arbitrary file writes

Details:
## Summary

  OpenClaw’s browser control API accepted user-supplied output paths for trace/download files without consistently
  constraining writes to OpenClaw-managed temporary directories.

  ## Impact

  If an attacker can access the browser control API, they could attempt to write trace/download output files outside
  intended temp roots, depending on process filesystem permissions.

  ## Affected versions

  `openclaw` `< 2026.2.13`

  ## Fixed versions

  `openclaw` `>= 2026.2.13`

  ## Remediation

  Upgrade to `2026.2.13` or later.

  ## What changed

  The fix constrains output paths for:

  - `POST /trace/stop`
  - `POST /wait/download`
  - `POST /download`

  All three now enforce OpenClaw temp-root boundaries and reject traversal/escape paths.

  ## Credits

  Thanks to Adnan Jakati (@jackhax) of Praetorian for responsible disclosure.

  Fix shipped in PR #15652 and merged to `main` on February 13, 2026 (`7f0489e4731c8d965d78d6eac4a60312e46a9426`).

---

Fix commit 7f0489e4731c8d965d78d6eac4a60312e46a9426 confirmed on main and in v2026.2.14. Upgrade to `openclaw >= 2026.2.13`.
GitHub Security Advisory: GHSA-xwjm-j929-xq7c
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.7)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 2026.1.12, <= 2026.2.12
Patched in: 2026.2.13

Summary: OpenClaw has a Path Traversal in Browser Download Functionality

Details:
### Summary

OpenClaw browser download helpers accepted an unsanitized output path. When invoked via the browser control gateway routes, this allowed path traversal to write downloads outside the intended OpenClaw temp downloads directory.

This issue is not exposed via the AI agent tool schema (no `download` action). Exploitation requires authenticated CLI access or an authenticated gateway RPC token.

### Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: >=2026.1.12, <=2026.2.12
- Fixed: >=2026.2.13

### Details

Affected code: `src/browser/pw-tools-core.downloads.ts` (`waitForDownloadViaPlaywright`, `downloadViaPlaywright`).

Fixed entrypoints (as of 2026.2.13):
- Gateway browser control routes `/wait/download` and `/download` now restrict `path` to `DEFAULT_DOWNLOAD_DIR` via `resolvePathWithinRoot`.

### Fix Commit(s)

- 7f0489e4731c8d965d78d6eac4a60312e46a9426

### Mitigation

Upgrade to `openclaw` >=2026.2.13.

Thanks @locus-x64 for reporting.
GitHub Security Advisory: GHSA-v6c6-vqqg-w888
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-427: Uncontrolled Search Path Element
Vulnerable versions: >= 2026.1.5, < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw affected by potential code execution via unsafe hook module path handling in Gateway

Details:
## Summary

OpenClaw Gateway supports hook mappings with optional JavaScript/TypeScript transform modules. In affected versions, the gateway did not sufficiently constrain configured module paths before passing them to dynamic `import()`. Under some configurations, a user who can modify gateway configuration could cause the gateway process to load and execute an unintended local module.

## Impact

Potential code execution in the OpenClaw gateway Node.js process.

This requires access that can modify gateway configuration (for example via the gateway config endpoints). Treat such access as high privilege.

## Affected Packages / Versions

- npm package: `openclaw`
- Affected: `>= 2026.1.5` and `<= 2026.2.13`

## Patched Versions

- `>= 2026.2.14`

## Fix Commit(s)

- `a0361b8ba959e8506dc79d638b6e6a00d12887e4` (restrict hook transform module loading)
- `35c0e66ed057f1a9f7ad2515fdcef516bd6584ce` (harden hooks module loading)

## Mitigation

- Upgrade to `2026.2.14` or newer.
- Avoid exposing gateway configuration endpoints to untrusted networks.
- Review config for unsafe values:
  - `hooks.mappings[].transform.module`
  - `hooks.internal.handlers[].module`

Thanks @222n5 for reporting.
GitHub Security Advisory: GHSA-5xfq-5mr7-426q
Package: openclaw (NPM)
Severity: HIGH (CVSS 5.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2026.2.12
Patched in: 2026.2.12

Summary: OpenClaw's unsanitized session ID enables path traversal in transcript file operations

Details:
## Description

OpenClaw versions **<= 2026.2.9** construct transcript file paths using an unsanitized `sessionId` and also accept `sessionFile` paths without enforcing that they stay within the agent sessions directory.

A crafted `sessionId` and/or `sessionFile` (example: `../../etc/passwd`) can cause path traversal when the gateway performs transcript file read/write operations.

**Preconditions:** an attacker must be able to authenticate to the gateway (gateway token/password). By default the gateway binds to `loopback` (local-only); configurations that expose the gateway widen the attack surface.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `<= 2026.2.9`
- Fixed: `>= 2026.2.12`

## Fix

Fixed by validating session IDs (rejecting path separators / traversal sequences) and enforcing sessions-directory containment for session transcript file operations.

### Fix Commit(s)

- `4199f9889f0c307b77096a229b9e085b8d856c26`

### Additional Hardening

- `cab0abf52ac91e12ea7a0cf04fff315cf0c94d64`

## Mitigation

Upgrade to `openclaw >= 2026.2.12`.

Thanks @akhmittra for reporting.
GitHub Security Advisory: GHSA-w5c7-9qqw-6645
Package: openclaw (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 2026.2.13
Patched in: 2026.2.13

Summary: OpenClaw inter-session prompts could be treated as direct user instructions

Details:
## Summary

Inter-session messages sent via `sessions_send` could be interpreted as direct end-user instructions because they were persisted as `role: "user"` without provenance metadata.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.2.12` (i.e. `< 2026.2.13`)
- Fixed in: `2026.2.13` (patched versions `>= 2026.2.13`)

## Impact

A delegated or internal session could inject instructions into another session that appeared equivalent to externally-originated user input.

This is an instruction-provenance confusion issue (confused-deputy style), which can lead to unintended privileged behavior in workflows that trust `role: "user"` as a sole authority signal.

## Technical details

Before the fix, routed inter-session prompts were stored as regular user turns without a verifiable source marker.

As a result, downstream workers and transcript readers could not distinguish:
- External user input
- Internal inter-session routed input

## Fix

OpenClaw now carries explicit input provenance end-to-end for routed prompts.

Key changes:
- Added structured provenance model (`inputProvenance`) with `kind` values including `inter_session`.
- `sessions_send` and agent-to-agent steps now set inter-session provenance when invoking target runs.
- Provenance is persisted on user messages as `message.provenance.kind = "inter_session"` (role remains `user` for provider compatibility).
- Transcript readers and memory helpers were updated to respect provenance and avoid treating inter-session prompts as external user-originated input.
- Runtime context rebuilding now annotates inter-session turns with an explicit in-memory marker (`[Inter-session message]`) for clearer model-side disambiguation.
- Regression tests were added for transcript parsing, session tools flow, runner sanitization, and memory hook behavior.

## Fix Commit(s)

- `85409e401b6586f83954cb53552395d7aab04797`

## Workarounds

If immediate upgrade is not possible:
- Disable or restrict `sessions_send` in affected environments.
- Do not use role alone as an authority boundary; require provenance-aware checks in orchestration logic.

## Credit

Reported by @anbecker.

Thanks @anbecker for reporting.
GitHub Security Advisory: GHSA-jqpq-mgvm-f9r6
Package: openclaw (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-427: Uncontrolled Search Path Element, CWE-807: Reliance on Untrusted Inputs in a Security Decision
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw: Command hijacking via unsafe PATH handling (bootstrapping + node-host PATH overrides)

Details:
# Command hijacking via PATH handling

**Discovered:** 2026-02-04
**Reporter:** @akhmittra

## Summary

OpenClaw previously accepted untrusted PATH sources in limited situations. In affected versions, this could cause OpenClaw to resolve and execute an unintended binary ("command hijacking") when running host commands.

This issue primarily matters when OpenClaw is relying on allowlist/safe-bin protections and expects `PATH` to be trustworthy.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `< 2026.2.14`
- Patched: `>= 2026.2.14` (planned next release)

## What Is Required To Trigger This

### A) Node Host PATH override (remote command hijack)

An attacker needs all of the following:

- Authenticated/authorized access to an execution surface that can invoke node-host execution (for example, a compromised gateway or a caller that can issue `system.run`).
- A node host connected and exposing `system.run`.
- A configuration where allowlist/safe-bins are expected to restrict execution (this is not meaningful if full arbitrary exec is already allowed).
- The ability to pass request-scoped environment overrides (specifically `PATH`) into `system.run`.
- A way to place an attacker-controlled executable earlier in `PATH` (for example, a writable directory on the node host), with a name that matches an allowlisted/safe-bin command that OpenClaw will run.

Notes:

- OpenClaw deployments commonly require a gateway token/password (or equivalent transport authentication). This should not be treated as unauthenticated Internet RCE.
- This scenario typically depends on **non-standard / misconfigured deployments** (for example, granting untrusted parties access to invoke node-host execution or otherwise exposing a privileged execution surface beyond the intended trust boundary).

### B) Project-local PATH bootstrapping (local command hijack)

An attacker needs all of the following:

- The victim runs OpenClaw from within an attacker-controlled working directory (for example, cloning and running inside a malicious repository).
- That directory contains a `node_modules/.bin/openclaw` and additional attacker-controlled executables in the same directory.
- OpenClaw subsequently executes a command by name (resolved via `PATH`) that matches one of those attacker-controlled executables.

## Fix

- Project-local `node_modules/.bin` PATH bootstrapping is now **disabled by default**. If explicitly enabled, it is **append-only** (never prepended) via `OPENCLAW_ALLOW_PROJECT_LOCAL_BIN=1`.
- Node Host now ignores request-scoped `PATH` overrides.

## Fix Commit(s)

- 013e8f6b3be3333a229a066eef26a45fec47ffcc

Thanks @akhmittra for reporting.
GitHub Security Advisory: GHSA-rq6g-px6m-c248
Package: clawdbot (NPM)
Severity: HIGH (CVSS 9.8)
CWE: CWE-284: Improper Access Control, CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 2026.1.24-3
Patched in: unpatched

Summary: OpenClaw Google Chat shared-path webhook target ambiguity allowed cross-account policy-context misrouting

Details:
## Summary
When multiple Google Chat webhook targets are registered on the same HTTP path, and request verification succeeds for more than one target, inbound webhook events could be routed by first-match semantics. This can cause cross-account policy/context misrouting.

## Affected Packages / Versions
- npm: `openclaw` <= 2026.2.13
- npm: `clawdbot` <= 2026.1.24-3

## Details
Affected component: `extensions/googlechat/src/monitor.ts`.

Baseline behavior allowed multiple webhook targets per path and selected the first target that passed `verifyGoogleChatRequest(...)`. In shared-path deployments where multiple targets can verify successfully (for example, equivalent audience validation), inbound events could be processed under the wrong account context (wrong allowlist/session/policy).

## Fix
- Fix commit (merged to `main`): `61d59a802869177d9cef52204767cd83357ab79e`
- `openclaw` will be patched in the next planned release: `2026.2.14`.

`clawdbot` is a legacy/deprecated package name; no patched version is currently planned. Migrate to `openclaw` and upgrade to `openclaw >= 2026.2.14`.

## Workaround
Ensure each Google Chat webhook target uses a unique webhook path so routing is never ambiguous.

## Release Process Note
The advisory is pre-populated with the planned patched version. After the npm release is published, the remaining action should be to publish the advisory.

Thanks @vincentkoc for reporting.

---

Fix commit 61d59a802869177d9cef52204767cd83357ab79e confirmed on main and in v2026.2.14. Upgrade to `openclaw >= 2026.2.14`.
GitHub Security Advisory: GHSA-rq6g-px6m-c248
Package: openclaw (NPM)
Severity: HIGH (CVSS 9.8)
CWE: CWE-284: Improper Access Control, CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw Google Chat shared-path webhook target ambiguity allowed cross-account policy-context misrouting

Details:
## Summary
When multiple Google Chat webhook targets are registered on the same HTTP path, and request verification succeeds for more than one target, inbound webhook events could be routed by first-match semantics. This can cause cross-account policy/context misrouting.

## Affected Packages / Versions
- npm: `openclaw` <= 2026.2.13
- npm: `clawdbot` <= 2026.1.24-3

## Details
Affected component: `extensions/googlechat/src/monitor.ts`.

Baseline behavior allowed multiple webhook targets per path and selected the first target that passed `verifyGoogleChatRequest(...)`. In shared-path deployments where multiple targets can verify successfully (for example, equivalent audience validation), inbound events could be processed under the wrong account context (wrong allowlist/session/policy).

## Fix
- Fix commit (merged to `main`): `61d59a802869177d9cef52204767cd83357ab79e`
- `openclaw` will be patched in the next planned release: `2026.2.14`.

`clawdbot` is a legacy/deprecated package name; no patched version is currently planned. Migrate to `openclaw` and upgrade to `openclaw >= 2026.2.14`.

## Workaround
Ensure each Google Chat webhook target uses a unique webhook path so routing is never ambiguous.

## Release Process Note
The advisory is pre-populated with the planned patched version. After the npm release is published, the remaining action should be to publish the advisory.

Thanks @vincentkoc for reporting.

---

Fix commit 61d59a802869177d9cef52204767cd83357ab79e confirmed on main and in v2026.2.14. Upgrade to `openclaw >= 2026.2.14`.
GitHub Security Advisory: GHSA-pg2v-8xwh-qhcc
Package: openclaw (NPM)
Severity: MODERATE (CVSS 8.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw affected by SSRF in optional Tlon (Urbit) extension authentication

Details:
## Summary
The optional Tlon (Urbit) extension previously accepted a user-provided base URL for authentication and used it to construct an outbound HTTP request, enabling server-side request forgery (SSRF) in affected deployments.

## Impact
This only affects deployments that have installed and configured the Tlon (Urbit) extension, and where an attacker can influence the configured Urbit URL. Under those conditions, the gateway could be induced to make HTTP requests to attacker-chosen hosts (including internal addresses).

Deployments that do not use the Tlon extension, or where untrusted users cannot change the Urbit URL, are not impacted.

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.2.13`

## Fixed Versions
- `2026.2.14` (planned next release)

## Fix Commit(s)
- `bfa7d21e997baa8e3437657d59b1e296815cc1b1`

## Details
Urbit authentication now validates and normalizes the base URL and uses an SSRF guard that blocks private/internal hosts by default (opt-in: `channels.tlon.allowPrivateNetwork`).

## Release Process Note
This advisory is pre-populated with the planned patched version (`2026.2.14`). After `openclaw@2026.2.14` is published to npm, publish this advisory without further edits.

Thanks @p80n-sec for reporting.
GitHub Security Advisory: GHSA-c37p-4qqg-3p76
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw Twilio voice-call webhook auth bypass when ngrok loopback compatibility is enabled

Details:
## Summary

A Twilio webhook signature-verification bypass in the voice-call extension could allow unauthenticated webhook requests when a specific ngrok free-tier compatibility option is enabled.

## Impact

This issue is limited to configurations that explicitly enable and expose the voice-call webhook endpoint.

Not affected by default:
- The voice-call extension is optional and disabled by default.
- The bypass only applied when `tunnel.allowNgrokFreeTierLoopbackBypass` was explicitly enabled.
- Exploitation required the webhook to be reachable (typically via a public ngrok URL during development).

Worst case (when exposed and the option was enabled):
- An external attacker could send forged requests to the publicly reachable webhook endpoint that would be accepted without a valid `X-Twilio-Signature`.
- This could result in unauthorized webhook event handling (integrity) and request flooding (availability).

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.2.13` (latest published as of 2026-02-14)
- Patched versions: `>= 2026.2.14` (planned next release; pending publish)

## Fix

`allowNgrokFreeTierLoopbackBypass` no longer bypasses signature verification. It only enables trusting forwarded headers on loopback so the public ngrok URL can be reconstructed for correct signature validation.

Fix commit(s):
- ff11d8793b90c52f8d84dae3fbb99307da51b5c9

Thanks @p80n-sec for reporting.
GitHub Security Advisory: GHSA-mj5r-hh7j-4gxf
Package: clawdbot (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-284: Improper Access Control, CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: <= 2026.1.24-3
Patched in: unpatched

Summary: OpenClaw Telegram allowlist authorization accepted mutable usernames

Details:
## Summary
Telegram allowlist authorization could match on `@username` (mutable/recyclable) instead of immutable numeric sender IDs.

## Impact
Operators who treat Telegram allowlists as strict identity controls could unintentionally grant access if a username changes hands (identity rebinding/spoof risk). This can allow an unauthorized sender to interact with the bot in allowlist mode.

## Affected Packages / Versions
- npm `openclaw`: <= 2026.2.13
- npm `clawdbot`: <= 2026.1.24-3

## Fix
Telegram allowlist authorization now requires numeric Telegram sender IDs only. `@username` allowlist principals are rejected.

A security audit warning was added to flag legacy configs that still contain non-numeric Telegram allowlist entries.

`openclaw doctor --fix` now attempts to resolve `@username` allowFrom entries to numeric IDs (best-effort; requires a Telegram bot token).

## Fix Commit(s)
- e3b432e481a96b8fd41b91273818e514074e05c3
- 9e147f00b48e63e7be6964e0e2a97f[PII_REDACTED]

Thanks @vincentkoc for reporting.