deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-g34w-4xqq-h79m
Package: clawdbot (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-284: Improper Access Control, CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw iMessage group allowlist authorization inherited DM pairing-store identities

Details:
## Summary
Under iMessage `groupPolicy=allowlist`, group authorization could be satisfied by sender identities coming from the DM pairing store, broadening DM trust into group contexts.

## Details
Affected component: `src/imessage/monitor/monitor-provider.ts`.

Vulnerable logic derived `effectiveGroupAllowFrom` using both the static group allowlist and DM pairing-store identities (`storeAllowFrom`). This allowed a sender approved via DM pairing to satisfy group authorization in groups even if the sender/chat was not explicitly present in `groupAllowFrom`.

This weakens boundary separation between DM pairing and group allowlist authorization.

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

## Fix Commit(s)
- `openclaw/openclaw@872079d42fe105ece2900a1dd6ab321b92da2d59`
- `openclaw/openclaw@90d1e9cd71419168b2faa54a759b124a3eacfae7`

Thanks @vincentkoc for reporting.
GitHub Security Advisory: GHSA-g34w-4xqq-h79m
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-284: Improper Access Control, CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw iMessage group allowlist authorization inherited DM pairing-store identities

Details:
## Summary
Under iMessage `groupPolicy=allowlist`, group authorization could be satisfied by sender identities coming from the DM pairing store, broadening DM trust into group contexts.

## Details
Affected component: `src/imessage/monitor/monitor-provider.ts`.

Vulnerable logic derived `effectiveGroupAllowFrom` using both the static group allowlist and DM pairing-store identities (`storeAllowFrom`). This allowed a sender approved via DM pairing to satisfy group authorization in groups even if the sender/chat was not explicitly present in `groupAllowFrom`.

This weakens boundary separation between DM pairing and group allowlist authorization.

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

## Fix Commit(s)
- `openclaw/openclaw@872079d42fe105ece2900a1dd6ab321b92da2d59`
- `openclaw/openclaw@90d1e9cd71419168b2faa54a759b124a3eacfae7`

Thanks @vincentkoc for reporting.
GitHub Security Advisory: GHSA-pv58-549p-qh99
Package: openclaw (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw allows unauthenticated discovery TXT records to steer routing and TLS pinning

Details:
## Summary

Discovery beacons (Bonjour/mDNS and DNS-SD) include TXT records such as `lanHost`, `tailnetDns`, `gatewayPort`, and `gatewayTlsSha256`. TXT records are unauthenticated.

Prior to the fix, some clients treated TXT values as authoritative routing/pinning inputs:

- iOS and macOS: used TXT-provided host hints (`lanHost`/`tailnetDns`) and ports (`gatewayPort`) to build the connection URL.
- iOS and Android: allowed the discovery-provided TLS fingerprint (`gatewayTlsSha256`) to override a previously stored TLS pin.

On a shared/untrusted LAN, an attacker could advertise a rogue `_openclaw-gw._tcp` service. This could cause a client to connect to an attacker-controlled endpoint and/or accept an attacker certificate, potentially exfiltrating Gateway credentials (`auth.token` / `auth.password`) during connection.

## Distribution / Exposure

The iOS and Android apps are currently alpha/not broadly shipped (no public App Store / Play Store release). Practical impact is primarily limited to developers/testers running those builds, plus any other shipped clients relying on discovery on a shared/untrusted LAN.

CVSS can still be used for the technical (base) severity of the bug; limited distribution primarily affects environmental risk.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `<= 2026.2.13` (latest published on npm as of 2026-02-14)
- Patched: planned for `>= 2026.2.14` (not yet published at time of writing)

## Fix

- Clients now prefer the resolved service endpoint (SRV + A/AAAA) over TXT-provided routing hints.
- Discovery-provided fingerprints no longer override stored TLS pins.
- iOS/Android: first-time TLS pins require explicit user confirmation (fingerprint shown; no silent TOFU).
- iOS/Android: discovery-based direct connects are TLS-only.
- Android: hostname verification is no longer globally disabled (only bypassed when pinning).

## Fix Commit(s)

- d583782ee322a6faa1fe87ae52455e0d349de586

## Credits

Thanks @simecek for reporting.
GitHub Security Advisory: GHSA-chm2-m3w2-wcxm
Package: clawdbot (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-290: Authentication Bypass by Spoofing, CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.1.24-3
Patched in: unpatched

Summary: OpenClaw Google Chat spoofing access with allowlist authorized mutable email principal despite sender-ID mismatch

Details:
### Summary
Google Chat allowlisting supports matching by sender email in addition to immutable sender resource name (`users/<id>`). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.

### Affected Packages / Versions
(As of 2026-02-14; based on latest published npm versions)
- `openclaw` (npm): `<= 2026.2.13`
- `clawdbot` (npm): `<= 2026.1.24-3`

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

The `allowFrom` checks accept:
- Immutable sender id (`users/<id>`)
- Raw email (`alice@example.com`) for usability

Historically, `users/<email>` was also treated as an email allowlist entry. This is now deprecated because it looks like an immutable ID but is actually a mutable principal.

### Security Triage (2026-02-14)
Severity: **Low**

Rationale:
- Requests are authenticated as coming from Google Chat (token verification), so this is not a generic unauthenticated spoofing vector.
- A realistic exploit generally requires **Google Workspace / IdP administrative control** over identity lifecycle (e.g. reassigning an email address to a different underlying account) to obtain the same email with a different `users/<id>`.
- With that level of access, the attacker typically has broader compromise paths.

We still treat it as a valid defense-in-depth report because accepting mutable principals in authorization decisions can increase risk in chained-failure scenarios.

### Remediation / Behavior Changes
Goal: preserve usability while reducing footguns.
- Raw email allowlists remain supported.
- `users/<email>` is deprecated and treated as a **user id**, not as an email allowlist.
- Documentation recommends `users/<id>` when strict immutable binding is required.

### Fix Commit(s)
- `c8424bf29a921e25663b29f308640b3d91a49432` (PR #16243)

Thanks @vincentkoc for reporting.
GitHub Security Advisory: GHSA-chm2-m3w2-wcxm
Package: openclaw (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-290: Authentication Bypass by Spoofing, CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw Google Chat spoofing access with allowlist authorized mutable email principal despite sender-ID mismatch

Details:
### Summary
Google Chat allowlisting supports matching by sender email in addition to immutable sender resource name (`users/<id>`). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.

### Affected Packages / Versions
(As of 2026-02-14; based on latest published npm versions)
- `openclaw` (npm): `<= 2026.2.13`
- `clawdbot` (npm): `<= 2026.1.24-3`

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

The `allowFrom` checks accept:
- Immutable sender id (`users/<id>`)
- Raw email (`alice@example.com`) for usability

Historically, `users/<email>` was also treated as an email allowlist entry. This is now deprecated because it looks like an immutable ID but is actually a mutable principal.

### Security Triage (2026-02-14)
Severity: **Low**

Rationale:
- Requests are authenticated as coming from Google Chat (token verification), so this is not a generic unauthenticated spoofing vector.
- A realistic exploit generally requires **Google Workspace / IdP administrative control** over identity lifecycle (e.g. reassigning an email address to a different underlying account) to obtain the same email with a different `users/<id>`.
- With that level of access, the attacker typically has broader compromise paths.

We still treat it as a valid defense-in-depth report because accepting mutable principals in authorization decisions can increase risk in chained-failure scenarios.

### Remediation / Behavior Changes
Goal: preserve usability while reducing footguns.
- Raw email allowlists remain supported.
- `users/<email>` is deprecated and treated as a **user id**, not as an email allowlist.
- Documentation recommends `users/<id>` when strict immutable binding is required.

### Fix Commit(s)
- `c8424bf29a921e25663b29f308640b3d91a49432` (PR #16243)

Thanks @vincentkoc for reporting.
GitHub Security Advisory: GHSA-8mh7-phf8-xgfm
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw skills.status could leak secrets to operator.read clients

Details:
### Summary

`skills.status` could disclose secrets to `operator.read` clients by returning raw resolved config values in `configChecks` for skill `requires.config` paths.

### Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `<= 2026.2.13`
- Patched: `2026.2.14`

### Details

The gateway method `skills.status` returned a requirements report that included `configChecks[].value` (the resolved value for each `requires.config` entry). If a skill required a broad config subtree (for example `channels.discord`), the report could include secrets such as Discord bot tokens.

`skills.status` is callable with `operator.read`, so read-scoped clients could obtain secrets without `operator.admin` / `config.*` access.

### Fix

- Stop including raw resolved config values in requirement checks (return only `{ path, satisfied }`).
- Narrow the Discord skill requirement to the token key.

Fix commit(s):

- d3428053d95eefbe10ecf04f92218ffcba55ae5a
- ebc68861a61067fc37f9298bded3eec9de0ba783

### Mitigation

Rotate any Discord tokens that may have been exposed to read-scoped clients.

Thanks @simecek for reporting.

---

Fix commits d3428053d95eefbe10ecf04f92218ffcba55ae5a and ebc68861a61067fc37f9298bded3eec9de0ba783 confirmed on main and in v2026.2.14. Upgrade to `openclaw >= 2026.2.14`.
GitHub Security Advisory: GHSA-h3f9-mjwj-w476
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.2)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw Node host system.run rawCommand/command mismatch can bypass allowlist/approvals

Details:
## Summary

A mismatch between `rawCommand` and `command[]` in the node host `system.run` handler could cause allowlist/approval evaluation to be performed on one command while executing a different argv.

## Affected Configurations

This only impacts deployments that:

- Use the node host / companion node execution path (`system.run` on a node).
- Enable allowlist-based exec policy (`security=allowlist`) with approval prompting driven by allowlist misses (for example `ask=on-miss`).
- Allow an attacker to invoke `system.run`.

Default/non-node configurations are not affected.

## Impact

In affected configurations, an attacker who can invoke `system.run` can bypass allowlist enforcement and approval prompts by supplying an allowlisted `rawCommand` while providing a different `command[]` argv for execution.

## Affected Packages / Versions

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

## Fix

Enforce `rawCommand`/`command[]` consistency (gateway fail-fast + node host validation).

## Fix Commit(s)

- cb3290fca[PII_REDACTED]8f161d9776266b90ab891

## Release Process Note

This advisory pre-sets the patched version to the planned next release (`2026.2.14`). Once `openclaw@2026.2.14` is published to npm, the advisory can be published without further edits.

Thanks @christos-eth for reporting.
GitHub Security Advisory: GHSA-jrvc-8ff5-2f9f
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw has a SSRF guard bypass via full-form IPv4-mapped IPv6 (loopback / metadata reachable)

Details:
### Summary

OpenClaw's SSRF protection could be bypassed using full-form IPv4-mapped IPv6 literals such as `0:0:0:0:0:ffff:7f00:1` (which is `127.0.0.1`). This could allow requests that should be blocked (loopback / private network / link-local metadata) to pass the SSRF guard.

- Vulnerable component: SSRF guard (`src/infra/net/ssrf.ts`)
- Issue type: SSRF protection bypass

### Affected Packages / Versions

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

### Details

The SSRF guard's IP classification did not consistently detect private IPv4 addresses when they were embedded in IPv6 using full-form IPv4-mapped IPv6 notation. As a result, inputs like `0:0:0:0:0:ffff:7f00:1` could bypass loopback/private network blocking.

### Fix Commit(s)

- `c0c0e0f9aecb913e738742f73e091f2f72d39a19`

### Release Process Note

This advisory is kept in draft state with the patched version set to the planned next release. Once `openclaw@2026.2.14` is published to npm, the only remaining step should be to publish this advisory.

Thanks @yueyueL for reporting.
GitHub Security Advisory: GHSA-g6q9-8fvw-f7rf
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.6)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw Gateway tool allowed unrestricted gatewayUrl override

Details:
## Summary
The Gateway tool accepted a tool-supplied `gatewayUrl` without sufficient restrictions, which could cause the OpenClaw host to attempt outbound WebSocket connections to user-specified targets.

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

## What Is Needed To Trigger This
This requires the ability to invoke tools that accept `gatewayUrl` overrides (directly or indirectly). In typical setups this is limited to authenticated operators, trusted automation, or environments where tool calls are exposed to non-operators.

In other words, this is not a drive-by issue for arbitrary internet users unless a deployment explicitly allows untrusted users to trigger these tool calls.

## Details
Some tool call paths allowed `gatewayUrl` overrides to flow into the Gateway WebSocket client without validation or allowlisting. This meant the host could be instructed to attempt connections to non-gateway endpoints (for example, localhost services, private network addresses, or cloud metadata IPs).

## Impact
In the common case, this results in an outbound connection attempt from the OpenClaw host (and corresponding errors/timeouts). In environments where the tool caller can observe the results, this can also be used for limited network reachability probing. If the target speaks WebSocket and is reachable, further interaction may be possible.

## Fix
Tool-supplied `gatewayUrl` overrides are now restricted to loopback (on the configured gateway port) or the configured `gateway.remote.url`. Disallowed protocols, credentials, query/hash, and non-root paths are rejected.

## Fix Commit(s)
- c5406e1d2434be2ef6eb4d26d8f1798d718713f4

## Release Process Note
`patched_versions` is set to the planned next release. Once the npm release is published, the advisory can be published without further edits.

Thanks @p80n-sec for reporting.
GitHub Security Advisory: GHSA-8jpq-5h99-ff5r
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.14
Patched in: 2026.2.14

Summary: OpenClaw has a local file disclosure via sendMediaFeishu in Feishu extension

Details:
### Summary
The Feishu extension previously allowed `sendMediaFeishu` to treat attacker-controlled `mediaUrl` values as local filesystem paths and read them directly.

### Affected versions
- `< 2026.2.14`

### Patched versions
- `>= 2026.2.14`

### Impact
If an attacker can influence tool calls (directly or via prompt injection), they may be able to exfiltrate local files by supplying paths such as `/etc/passwd` as `mediaUrl`.

### Remediation
Upgrade to OpenClaw `2026.2.14` or newer.

### Notes
The fix removes direct local file reads from this path and routes media loading through hardened helpers that enforce local-root restrictions.

---

Fix commit 5b4121d60 confirmed on main and in v2026.2.14. Upgrade to `openclaw >= 2026.2.14`.
GitHub Security Advisory: GHSA-7q2j-c4q5-rm27
Package: openclaw (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-451: User Interface (UI) Misrepresentation of Critical Information
Vulnerable versions: >= 2026.2.6-0, < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw macOS deep link confirmation truncation can conceal executed agent message

Details:
### Summary
OpenClaw macOS desktop client registers the `openclaw://` URL scheme. For `openclaw://agent` deep links without an unattended `key`, the app shows a confirmation dialog that previously displayed only the first 240 characters of the message, but executed the full message after the user clicked "Run".

At the time of writing, the OpenClaw macOS desktop client is still in beta.

An attacker could pad the message with whitespace to push a malicious payload outside the visible preview, increasing the chance a user approves a different message than the one that is actually executed.

### Impact
If a user runs the deep link, the agent may perform actions that can lead to arbitrary command execution depending on the user's configured tool approvals/allowlists. This is a social-engineering mediated vulnerability: the confirmation prompt could be made to misrepresent the executed message.

## Affected Versions
- OpenClaw macOS desktop client versions >= 2026.2.6 and <= 2026.2.13.

## Fixed Versions
- 2026.2.14.

### Mitigations
- Do not approve unexpected "Run OpenClaw agent?" prompts triggered while browsing untrusted sites.
- Use unattended deep links only with a valid `key` for trusted personal automations.

### Resolution
Unkeyed deep links now enforce a strict message length limit for confirmation and ignore delivery/routing knobs (`deliver`, `to`, `channel`) unless a valid unattended `key` is provided.

Fix commit: 28d9dd7a772501ccc3f71457b4adfee79084fe6f

---

Fix commit 28d9dd7a772501ccc3f71457b4adfee79084fe6f confirmed on main and in v2026.2.14. Upgrade to `openclaw >= 2026.2.14`.
GitHub Security Advisory: GHSA-4hg8-92x6-h2f3
Package: openclaw (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: < 2026.2.14
Patched in: 2026.2.14

Summary: OpenClaw is Missing Webhook Authentication in Telnyx Provider Allows Unauthenticated Requests

Details:
## Summary

In affected versions, OpenClaw's optional `@openclaw/voice-call` plugin Telnyx webhook handler could accept unsigned inbound webhook requests when `telnyx.publicKey` was not configured, allowing unauthenticated callers to forge Telnyx events.

This only impacts deployments where the Voice Call plugin is installed, enabled, and the webhook endpoint is reachable from the attacker (for example, publicly exposed via a tunnel/proxy).

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected: `<= 2026.2.13`
- Fixed: `>= 2026.2.14` (planned)

## Details

Telnyx webhooks are expected to be authenticated via Ed25519 signature verification.

In affected versions, `TelnyxProvider.verifyWebhook()` could effectively fail open when no Telnyx public key was configured, allowing arbitrary HTTP POST requests to the voice-call webhook endpoint to be treated as legitimate Telnyx events.

## Fix

The fix makes Telnyx webhook verification fail closed by default and requires `telnyx.publicKey` (or `TELNYX_PUBLIC_KEY`) to be configured.

A signature verification bypass exists only for local development via `skipSignatureVerification: true`, which is off by default, emits a loud startup warning, and should not be used in production.

This requirement is documented in the Voice Call plugin docs.

## Fix Commit(s)

- `29b587e73cbdc941caec573facd16e87d52f007b`
- `f47584fec` (centralized verification helper + stronger tests)

## Workarounds

- Configure `plugins.entries.voice-call.config.telnyx.publicKey` (or `TELNYX_PUBLIC_KEY`) to enable signature verification.
- Only for local development: set `skipSignatureVerification: true`.

Thanks @p80n-sec for reporting.
GitHub Security Advisory: GHSA-236c-vhj4-gfxg
Package: ua-parser-js (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-829: Inclusion of Functionality from Untrusted Control Sphere, CWE-912: Hidden Functionality
Vulnerable versions: = 1.0.0
Patched in: 1.0.1

Summary: Duplicate Advisory: Embedded malware in ua-parser-js

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-pjwm-rvh2-c87w. This link is maintained to preserve external references.

### Original Description
A vulnerability was found in ua-parser-js 0.7.29/0.8.0/1.0.0. It has been rated as critical. This issue affects the crypto mining component which introduces a backdoor. Upgrading to version 0.7.30, 0.8.1 and 1.0.1 is able to address this issue. It is recommended to upgrade the affected component.
GitHub Security Advisory: GHSA-236c-vhj4-gfxg
Package: ua-parser-js (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-829: Inclusion of Functionality from Untrusted Control Sphere, CWE-912: Hidden Functionality
Vulnerable versions: = 0.8.0
Patched in: 0.8.1

Summary: Duplicate Advisory: Embedded malware in ua-parser-js

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-pjwm-rvh2-c87w. This link is maintained to preserve external references.

### Original Description
A vulnerability was found in ua-parser-js 0.7.29/0.8.0/1.0.0. It has been rated as critical. This issue affects the crypto mining component which introduces a backdoor. Upgrading to version 0.7.30, 0.8.1 and 1.0.1 is able to address this issue. It is recommended to upgrade the affected component.
GitHub Security Advisory: GHSA-236c-vhj4-gfxg
Package: ua-parser-js (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-829: Inclusion of Functionality from Untrusted Control Sphere, CWE-912: Hidden Functionality
Vulnerable versions: = 0.7.29
Patched in: 0.7.30

Summary: Duplicate Advisory: Embedded malware in ua-parser-js

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-pjwm-rvh2-c87w. This link is maintained to preserve external references.

### Original Description
A vulnerability was found in ua-parser-js 0.7.29/0.8.0/1.0.0. It has been rated as critical. This issue affects the crypto mining component which introduces a backdoor. Upgrading to version 0.7.30, 0.8.1 and 1.0.1 is able to address this issue. It is recommended to upgrade the affected component.