deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-qrq5-wjgg-rvqw
Package: openclaw (NPM)
Severity: HIGH (CVSS 8.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 2026.1.20, < 2026.2.1
Patched in: 2026.2.1

Summary: OpenClaw has a Path Traversal in Plugin Installation

Details:
### Summary

OpenClaw's plugin installation path derivation could be abused by a malicious plugin `package.json` `name` to escape the intended extensions directory and write files to a parent directory.

### Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `>= 2026.1.20, < 2026.2.1`
- Fixed: `>= 2026.2.1`
- Latest published as of 2026-02-14: `2026.2.13` (not affected)

### Details

In affected versions, the plugin installer derives the on-disk install directory from the plugin manifest name without robust validation.

Example (POSIX / macOS / Linux):

- Manifest name: `@malicious/..`
- `unscopedPackageName("@malicious/..")` yields `..`
- The install directory becomes `path.join(extensionsDir, "..")`, which resolves to the parent of the extensions directory.

This can cause plugin files to be written into the OpenClaw state directory (default `~/.openclaw/`) rather than a subdirectory of `~/.openclaw/extensions/`.

Note: on Windows, affected versions also failed to sanitize backslashes (`\\`) in the derived directory name, which can enable deeper traversal via crafted `pluginId` strings.

### Impact

This issue requires a user/operator to install untrusted plugin content (for example via `openclaw plugins install`). In many deployments, plugin installation is an operator-only action and may be performed on a separate machine; that operational separation significantly reduces exposure for the primary gateway/runtime host.

On hosts where untrusted plugins are installed, this can lead to unintended file writes outside the extensions directory (potentially overwriting files under the OpenClaw state directory). On Windows, the traversal surface may extend further, within the privileges of the user running OpenClaw.

### Fix

Fixed in `openclaw` `2026.2.1` by validating plugin IDs and ensuring the resolved install directory remains within the configured extensions base directory.

### Fix Commit(s)

- d03eca8450dc493b198a88b105fd180895238e57

Thanks @logicx24 for reporting.
GitHub Security Advisory: GHSA-mqpw-46fh-299h
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.2)
CWE: CWE-269: Improper Privilege Management, CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.2.2
Patched in: 2026.2.2

Summary: OpenClaw authorization bypass: operator.write can resolve exec approvals via chat.send -> /approve

Details:
## Summary

### What this means (plain language)

If you give a client “chat/write” access to the gateway (`operator.write`) but you do not intend to let that client approve exec requests (`operator.approvals`), affected versions could still let that client approve/deny a pending exec approval by sending the `/approve` chat command.

This is mainly relevant for shared or multi-client setups where different tokens are intentionally scoped differently. Single-operator installs are typically less impacted.

### Technical summary

A gateway client authenticated with a device token scoped only to `operator.write` (without `operator.approvals`) could approve/deny pending exec approval requests by sending a chat message containing the built-in `/approve` command.

`exec.approval.resolve` is correctly scoped to `operator.approvals` for direct RPC calls, but the `/approve` command path invoked it via an internal privileged gateway client.

## Affected Packages / Versions

- `openclaw` (npm): `< 2026.2.2`

## Fix

- Fixed in `openclaw` `2026.2.2`.
- Fix commit(s): `efe2a464afcff55bb5a95b959e6bd9ec0fef086e`.
- Change: when `/approve` is invoked from gateway clients (webchat/internal channel), it now requires the requesting client to have `operator.approvals` (or `operator.admin`).

## Workarounds

- Upgrade to `openclaw >= 2026.2.2`.
- If you cannot upgrade: avoid issuing write-only device tokens to untrusted clients; disable text commands (`commands.text=false`) or restrict access to the webchat/control UI.

## References

- Fix: `src/auto-reply/reply/commands-approve.ts`
- Coverage: `src/auto-reply/reply/commands-approve.test.ts`

## Release Process Note

This advisory is kept in draft; once the fixed npm versions are available, it can be published without further edits.

Thanks @yueyueL for reporting.
GitHub Security Advisory: GHSA-7vwx-582j-j332
Package: openclaw (NPM)
Severity: MODERATE (CVSS 7.4)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data
Vulnerable versions: < 2026.2.1
Patched in: 2026.2.1

Summary: OpenClaw MS Teams inbound attachment downloader leaks bearer tokens to allowlisted suffix domains

Details:
## Summary

NOTE: This only affects deployments that enable the optional MS Teams extension (Teams channel). If you do not use MS Teams, you are not impacted.

When OpenClaw downloads inbound MS Teams attachments / inline images, it may retry a URL with an `Authorization: Bearer <token>` header after receiving `401` or `403`.

Because the default download allowlist uses suffix matching (and includes some multi-tenant suffix domains), a message that references an untrusted but allowlisted host could cause that bearer token to be sent to the wrong place.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Vulnerable: `<= 2026.1.30`
- Patched: `>= 2026.2.1`

## Fix

- Fix commit: `41cc5bcd4f1d434ad1bbdfa55b56f25025ecbf6b`
- Upgrade to `openclaw >= 2026.2.1`

## Workarounds

- If you do not need MS Teams, disable the MS Teams extension.
- If you must stay on an older version, ensure the auth host allowlist is strict (only Microsoft-owned endpoints that require auth) and avoid wildcard or broad suffix entries.

## Credits

Thanks @yueyueL for reporting.
GitHub Security Advisory: GHSA-33rq-m5x2-fvgf
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.3)
CWE: CWE-285: Improper Authorization
Vulnerable versions: >= 2026.1.29, < 2026.2.1
Patched in: 2026.2.1

Summary: OpenClaw Twitch allowFrom is not enforced in optional plugin, unauthorized chat users can trigger agent pipeline

Details:
### Summary

In the optional Twitch channel plugin (`extensions/twitch`), `allowFrom` is documented as a hard allowlist of Twitch user IDs, but it was not enforced as a hard gate. If `allowedRoles` is unset or empty, the access control path defaulted to allow, so any Twitch user who could mention the bot could reach the agent dispatch pipeline.

**Scope note:** This only affects deployments that installed and enabled the Twitch plugin. Core OpenClaw installs that do not install/enable the Twitch plugin are not impacted.

### Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `>= 2026.1.29, < 2026.2.1`
- Fixed: `>= 2026.2.1`

### Details

Affected component: Twitch plugin access control (`extensions/twitch/src/access-control.ts`).

Problematic logic in `checkTwitchAccessControl()`:

- When `allowFrom` was configured, the code returned `allowed: true` for members but did not return `allowed: false` for non-members, so execution fell through.
- If `allowedRoles` was unset or empty, the function returned `allowed: true` by default, even when `allowFrom` was configured.

### Proof of Concept (PoC)

1. Install and enable the Twitch plugin.
2. Configure an `allowFrom` list, but do not set `allowedRoles` (or set it to an empty list).
3. From a different Twitch account whose user ID is NOT in `allowFrom`, send a message that mentions the bot (for example `@<botname> hello`).
4. Observe the message is processed and can trigger agent dispatch/replies despite not being allowlisted.

### Impact

Authorization bypass for operators who relied on `allowFrom` to restrict who can invoke the bot in Twitch chat. Depending on configuration (tools, routing, model costs), this could lead to unintended actions/responses and resource or cost exhaustion.

### Fix Commit(s)

- `8c7901c984866a776eb59662dc9d8b028de4f0d0`

### Workaround

Upgrade to `openclaw >= 2026.2.1`.

Thanks @MegaManSec (https://joshua.hu) of [AISLE Research Team](https://aisle.com/) for reporting.
GitHub Security Advisory: GHSA-4rj2-gpmh-qq5x
Package: openclaw (NPM)
Severity: CRITICAL (CVSS 9.4)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 2026.2.2
Patched in: 2026.2.2

Summary: OpenClaw has an inbound allowlist policy bypass in voice-call extension (empty caller ID + suffix matching)

Details:
### Summary

An authentication bypass in the optional `voice-call` extension/plugin allowed unapproved or anonymous callers to reach the voice-call agent when inbound policy was set to `allowlist` or `pairing`.

Deployments that do not install/enable the `voice-call` extension are not affected.

### Affected Packages / Versions

- `openclaw` (npm): `<= 2026.2.1`
- Fixed in: `>= 2026.2.2`

### Details

In affected versions (for example `2026.2.1`), the inbound allowlist check in `extensions/voice-call/src/manager.ts` used suffix-based matching and accepted empty caller IDs after normalization.

This allowed two bypasses:

1. Missing/empty `from` values normalized to an empty string, which caused the allowlist predicate to evaluate as allowed.
2. Suffix-based matching meant any caller number whose digits ended with an allowlisted number would be accepted.

### Proof Of Concept

1. Configure the voice-call extension with `inboundPolicy: allowlist` and `allowFrom: ["[PII_REDACTED]"]`.
2. Place/trigger an inbound call with missing/empty caller ID (provider-dependent; for example anonymous/restricted caller). The call is accepted.
3. Place a call from a number whose E.164 digits end with `[PII_REDACTED]` (for example `[PII_REDACTED]1234`). The call is accepted.

### Impact

Only operators who install/enable the optional `voice-call` extension and use `inboundPolicy=allowlist` or `pairing` could have inbound access controls bypassed, potentially allowing unauthorized callers to reach auto-response and tool execution.

### Fix

The fix hardens inbound policy handling:

- Reject inbound calls when caller ID is missing.
- Require strict equality when comparing normalized caller IDs against the allowlist (no suffix/prefix matching).
- Add regression tests for missing caller ID, anonymous caller ID, and suffix-collision cases.

Fix commit(s):

- `f8dfd034f5d9235c5485f492a9e4ccc114e97fdb`

Thanks @simecek for reporting.
GitHub Security Advisory: GHSA-r5h9-vjqc-hq3r
Package: @openclaw/nextcloud-talk (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: <= 2026.2.2
Patched in: 2026.2.6

Summary: Nextcloud Talk allowlist bypass via actor.name display name spoofing

Details:
## Summary

In affected versions of the optional Nextcloud Talk plugin (installed separately; not bundled with the core OpenClaw install), an untrusted webhook field (`actor.name`, display name) could be treated as an allowlist identifier. An attacker could change their Nextcloud display name to match an allowlisted user ID and bypass DM or room allowlists.

## Details

Nextcloud Talk webhook payloads provide a stable sender identifier (`actor.id`) and a mutable display name (`actor.name`). In affected versions, the plugin’s allowlist matching accepted equality on the display name, which is attacker-controlled.

## Affected Packages / Versions

- Package: `@openclaw/nextcloud-talk` (npm)
- Affected: `<= 2026.2.2`
- Fixed: `>= 2026.2.6`

Note: This advisory applies to the optional Nextcloud Talk plugin package. Core `openclaw` is not impacted unless you installed and use `@openclaw/nextcloud-talk`.

## Fix Commit(s)

- [6b4b6049b47c3329a[PII_REDACTED][PII_REDACTED]92d](https://github.com/openclaw/openclaw/commit/6b4b6049b47c3329a[PII_REDACTED][PII_REDACTED]92d)

## Timeline

- Introduced: [660f87278c9f292061e097441e0b10c20d62b31b](https://github.com/openclaw/openclaw/commit/660f87278c9f292061e097441e0b10c20d62b31b) (2026-01-20)
- Fixed in repo: [6b4b6049b47c3329a[PII_REDACTED][PII_REDACTED]92d](https://github.com/openclaw/openclaw/commit/6b4b6049b47c3329a[PII_REDACTED][PII_REDACTED]92d) (2026-02-04 UTC)
- First fixed tag containing the change: [v2026.2.3](https://github.com/openclaw/openclaw/releases/tag/v2026.2.3)
- First fixed npm release of `@openclaw/nextcloud-talk`: `2026.2.6` (published 2026-02-07 UTC)

## Mitigation

Upgrade `@openclaw/nextcloud-talk` to `>= 2026.2.6`.

## Release Process Note

The patched version range is set to the first npm release that contains the fix. Once you are ready, you can publish this advisory without additional version edits.

Thanks @MegaManSec (https://joshua.hu) of [AISLE Research Team](https://aisle.com/) for reporting.
GitHub Security Advisory: GHSA-fhvm-j76f-qmjv
Package: openclaw (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-285: Improper Authorization, CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 2026.2.1
Patched in: 2026.2.1

Summary: OpenClaw has a potential access-group authorization bypass if channel type lookup fails

Details:
## Summary

When Telegram webhook mode is enabled without a configured webhook secret, OpenClaw may accept unauthenticated HTTP POST requests at the Telegram webhook endpoint and trust attacker-controlled update JSON. This can allow forged Telegram updates that spoof `message.from.id` / `chat.id`, potentially bypassing sender allowlists and executing privileged bot commands.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `<= 2026.1.30`
- Patched: `>= 2026.2.1`

## Impact

An attacker who can reach the webhook endpoint can forge Telegram updates and impersonate allowlisted/paired senders by spoofing fields in the webhook payload (for example `message.from.id`). Impact depends on enabled commands/tools and the deployment’s network exposure.

## Mitigations / Workarounds

- Configure a strong `channels.telegram.webhookSecret` and ensure your reverse proxy forwards the `X-Telegram-Bot-Api-Secret-Token` header unchanged.

## Fix Commit(s)

- ca92597e1f9593236ad86810b66633144b69314d (config validation: `webhookUrl` requires `webhookSecret`)

Defense-in-depth / supporting fixes:

- 5643a934799dc523ec2ef18c007e1aa2c386b670 (default webhook listener bind host to loopback)
- 3cbcba10cf30c2ffb898f0d8c7dfb929f15f8930 (bound webhook request body size/time)
- 633fe8b9c17f02fcc68ecdb5ec212a5ace932f09 (runtime guard: reject webhook startup when secret is missing/empty)

## Release Process Note

`patched_versions` is set to the first fixed release (`2026.2.1`).

Thanks @yueyueL for reporting.
GitHub Security Advisory: GHSA-rmxw-jxxx-4cpc
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-287: Improper Authentication, CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: >= 2026.1.14-1, < 2026.2.2
Patched in: 2026.2.2

Summary: OpenClaw has a Matrix allowlist bypass via displayName and cross-homeserver localpart matching

Details:
### Summary

OpenClaw Matrix DM allowlist matching could be bypassed in certain configurations.

Matrix support ships as an optional plugin (not bundled with the core install), so this only affects deployments that have installed and enabled the Matrix plugin.

### Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `>= 2026.1.14-1, < 2026.2.2`
- Patched: `>= 2026.2.2`

### Details

In affected versions, DM allowlist decisions could be made by exact-matching `channels.matrix.dm.allowFrom` entries against multiple sender-derived candidates, including:

- The sender display name (attacker-controlled and non-unique)
- The sender MXID localpart with the homeserver discarded, so `@alice:evil.example` and `@alice:trusted.example` both match `alice`

If an operator configured `channels.matrix.dm.allowFrom` with display names or bare localparts (for example, `"Alice"` or `"alice"`), a remote Matrix user may be able to impersonate an allowed identity for allowlist purposes and reach the routing/agent pipeline.

### Impact

Matrix DM allowlist identity confusion. The practical impact depends on your Matrix channel policies and what capabilities are enabled downstream.

### Mitigation

- Upgrade to `openclaw >= 2026.2.2`.
- Ensure Matrix allowlists contain only full Matrix user IDs (MXIDs) like `@user:server` (or `*`). Do not use display names or bare localparts.

### Fix Commit(s)

- `8f3bfbd1c4fb967a2ddb5b4b9a[PII_REDACTED]4bcf`

### Release Process Note

The patched version is already published to npm; the advisory can be published once you're ready.

Thanks @MegaManSec (https://joshua.hu) of [AISLE Research Team](https://aisle.com/) for reporting.
GitHub Security Advisory: GHSA-pchc-86f6-8758
Package: @openclaw/bluebubbles (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.2.13
Patched in: 2026.2.13

Summary: OpenClaw BlueBubbles webhook auth bypass via loopback proxy trust

Details:
### Summary

In affected versions, the optional BlueBubbles iMessage channel plugin could accept webhook requests as authenticated based only on the TCP peer address being loopback (`127.0.0.1`, `::1`, `::ffff:127.0.0.1`) even when the configured webhook secret was missing or incorrect. This does not affect the default iMessage integration unless BlueBubbles is installed and enabled.

### Affected Packages / Versions

- npm: `openclaw` `< 2026.2.13`
- npm: `@openclaw/bluebubbles` `< 2026.2.13`

### Details

If a deployment exposes the BlueBubbles webhook endpoint through a same-host reverse proxy (or an attacker can reach loopback via SSRF), an unauthenticated party may be able to inject inbound webhook events into the agent pipeline.

### Fix Commit(s)

- f836c385ffc746cb954e8ee409f99d079bfdcd2f
- 743f4b28495cdeb0d5bf76f6ebf4af01f6a02e5a (defense-in-depth)

### Mitigations

- Set a non-empty BlueBubbles webhook password.
- Avoid deployments where a public-facing reverse proxy forwards to a loopback-bound Gateway without strong upstream authentication.

Thanks @MegaManSec (https://joshua.hu) of [AISLE Research Team](https://aisle.com/) for reporting.
GitHub Security Advisory: GHSA-pchc-86f6-8758
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.2.13
Patched in: 2026.2.13

Summary: OpenClaw BlueBubbles webhook auth bypass via loopback proxy trust

Details:
### Summary

In affected versions, the optional BlueBubbles iMessage channel plugin could accept webhook requests as authenticated based only on the TCP peer address being loopback (`127.0.0.1`, `::1`, `::ffff:127.0.0.1`) even when the configured webhook secret was missing or incorrect. This does not affect the default iMessage integration unless BlueBubbles is installed and enabled.

### Affected Packages / Versions

- npm: `openclaw` `< 2026.2.13`
- npm: `@openclaw/bluebubbles` `< 2026.2.13`

### Details

If a deployment exposes the BlueBubbles webhook endpoint through a same-host reverse proxy (or an attacker can reach loopback via SSRF), an unauthenticated party may be able to inject inbound webhook events into the agent pipeline.

### Fix Commit(s)

- f836c385ffc746cb954e8ee409f99d079bfdcd2f
- 743f4b28495cdeb0d5bf76f6ebf4af01f6a02e5a (defense-in-depth)

### Mitigations

- Set a non-empty BlueBubbles webhook password.
- Avoid deployments where a public-facing reverse proxy forwards to a loopback-bound Gateway without strong upstream authentication.

Thanks @MegaManSec (https://joshua.hu) of [AISLE Research Team](https://aisle.com/) for reporting.
GitHub Security Advisory: GHSA-3m3q-x3gj-f79x
Package: @clawdbot/voice-call (NPM)
Severity: HIGH (CVSS 5.9)
CWE: CWE-287: Improper Authentication, CWE-290: Authentication Bypass by Spoofing, CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: <= 2026.1.24
Patched in: unpatched

Summary: OpenClaw optional voice-call plugin: webhook verification may be bypassed behind certain proxy configurations

Details:
## Affected Packages / Versions

This issue affects the optional voice-call plugin only. It is not enabled by default; it only applies to installations where the plugin is installed and enabled.

- Package: `@openclaw/voice-call`
- Vulnerable versions: `< 2026.2.3`
- Patched versions: `>= 2026.2.3`

Legacy package name (if you are still using it):

- Package: `@clawdbot/voice-call`
- Vulnerable versions: `<= 2026.1.24`
- Patched versions: none published under this package name; migrate to `@openclaw/voice-call`

## Summary

In certain reverse-proxy / forwarding setups, webhook verification can be bypassed if untrusted forwarded headers are accepted.

## Impact

An external party may be able to send voice-call webhook requests that are accepted as valid, which can result in spoofed webhook events being processed.

## Root Cause

Some deployments implicitly trusted forwarded headers (for example `Forwarded` / `X-Forwarded-*`) when determining request properties used during webhook verification. If those headers are not overwritten by a trusted proxy, a client can supply them directly and influence verification.

## Resolution

Ignore forwarded headers by default unless explicitly trusted and allowlisted in configuration. Keep any loopback-only development bypass restricted to local development only. Upgrade to a patched version.

If you cannot upgrade immediately, strip `Forwarded` and `X-Forwarded-*` headers at the edge so clients cannot supply them directly.

## Fix Commit(s)

- `a749db9820eb6d6224032a5a34223d286d2dcc2f`

## Credits

Thanks `@0x5t` for reporting.
GitHub Security Advisory: GHSA-3m3q-x3gj-f79x
Package: @openclaw/voice-call (NPM)
Severity: HIGH (CVSS 5.9)
CWE: CWE-287: Improper Authentication, CWE-290: Authentication Bypass by Spoofing, CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 2026.2.3
Patched in: 2026.2.3

Summary: OpenClaw optional voice-call plugin: webhook verification may be bypassed behind certain proxy configurations

Details:
## Affected Packages / Versions

This issue affects the optional voice-call plugin only. It is not enabled by default; it only applies to installations where the plugin is installed and enabled.

- Package: `@openclaw/voice-call`
- Vulnerable versions: `< 2026.2.3`
- Patched versions: `>= 2026.2.3`

Legacy package name (if you are still using it):

- Package: `@clawdbot/voice-call`
- Vulnerable versions: `<= 2026.1.24`
- Patched versions: none published under this package name; migrate to `@openclaw/voice-call`

## Summary

In certain reverse-proxy / forwarding setups, webhook verification can be bypassed if untrusted forwarded headers are accepted.

## Impact

An external party may be able to send voice-call webhook requests that are accepted as valid, which can result in spoofed webhook events being processed.

## Root Cause

Some deployments implicitly trusted forwarded headers (for example `Forwarded` / `X-Forwarded-*`) when determining request properties used during webhook verification. If those headers are not overwritten by a trusted proxy, a client can supply them directly and influence verification.

## Resolution

Ignore forwarded headers by default unless explicitly trusted and allowlisted in configuration. Keep any loopback-only development bypass restricted to local development only. Upgrade to a patched version.

If you cannot upgrade immediately, strip `Forwarded` and `X-Forwarded-*` headers at the edge so clients cannot supply them directly.

## Fix Commit(s)

- `a749db9820eb6d6224032a5a34223d286d2dcc2f`

## Credits

Thanks `@0x5t` for reporting.