deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-v8jm-5vwx-cfxm
Package: dompurify (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.5.3, <= 2.5.8
Patched in: unpatched

Summary: DOMPurify contains a Cross-site Scripting vulnerability

Details:
DOMPurify 3.1.3 through 3.2.6 and 2.5.3 through 2.5.8 contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting missing textarea rawtext element validation in the SAFE_FOR_XML regex. Attackers can include closing rawtext tags like </textarea> in attribute values to break out of rawtext contexts and execute JavaScript when sanitized output is placed inside rawtext elements. The 3.x branch was fixed in 3.2.7; the 2.x branch was never patched.
GitHub Security Advisory: GHSA-v8jm-5vwx-cfxm
Package: dompurify (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 3.1.3, < 3.2.7
Patched in: 3.2.7

Summary: DOMPurify contains a Cross-site Scripting vulnerability

Details:
DOMPurify 3.1.3 through 3.2.6 and 2.5.3 through 2.5.8 contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting missing textarea rawtext element validation in the SAFE_FOR_XML regex. Attackers can include closing rawtext tags like </textarea> in attribute values to break out of rawtext contexts and execute JavaScript when sanitized output is placed inside rawtext elements. The 3.x branch was fixed in 3.2.7; the 2.x branch was never patched.
GitHub Security Advisory: GHSA-7gmj-h9xc-mcxc
Package: mailparser (NPM)
Severity: LOW (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 3.9.3
Patched in: 3.9.3

Summary: mailparser vulnerable to Cross-site Scripting

Details:
Versions of the package mailparser before 3.9.3 are vulnerable to Cross-site Scripting (XSS) via the textToHtml() function due to the improper sanitisation of URLs in the email content. An attacker can execute arbitrary scripts in victim browsers by adding extra quote  " to the URL with embedded malicious JavaScript code.
GitHub Security Advisory: GHSA-vpq2-c234-7xj6
Package: @tootallnate/once (NPM)
Severity: LOW (CVSS 3.3)
CWE: CWE-705: Incorrect Control Flow Scoping
Vulnerable versions: < 3.0.1
Patched in: 3.0.1

Summary: @tootallnate/once vulnerable to Incorrect Control Flow Scoping

Details:
Versions of the package @tootallnate/once before 3.0.1 are vulnerable to Incorrect Control Flow Scoping in promise resolving when AbortSignal option is used. The Promise remains in a permanently pending state after the signal is aborted, causing any await or .then() usage to hang indefinitely. This can cause a control-flow leak that can lead to stalled requests, blocked workers, or degraded application availability.
GitHub Security Advisory: GHSA-wc8c-qw6v-h7f6
Package: @hono/node-server (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 1.19.10
Patched in: 1.19.10

Summary: @hono/node-server has authorization bypass for protected static paths via encoded slashes in Serve Static Middleware

Details:
## Summary

When using @hono/node-server's static file serving together with route-based middleware protections (e.g. protecting `/admin/*`), inconsistent URL decoding can allow protected static resources to be accessed without authorization.

In particular, paths containing encoded slashes (`%2F`) may be evaluated differently by routing/middleware matching versus static file path resolution, enabling a bypass where middleware does not run but the static file is still served.

## Details

The routing layer and the node-server static handler normalize request paths differently. The router preserves `%2F` as a literal string when matching routes, while the static handler decodes `%2F` into `/` before resolving the filesystem path.

Example request:

- `/admin%2Fsecret.html`

This may:
- fail to match middleware intended for `/admin/*`, but
- still be resolved by the static handler as `/admin/secret.html` under the configured static root.

This does not allow access outside the configured static root and is not a path traversal vulnerability.

## Impact

An unauthenticated attacker could bypass route-based authorization protections for protected static resources by supplying paths containing encoded slashes.

Applications relying solely on route-based middleware to protect static subpaths under the same static root may have exposed those resources.
GitHub Security Advisory: GHSA-5pq2-9x2x-5p6w
Package: hono (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting'), CWE-1113: Inappropriate Comment Style
Vulnerable versions: < 4.12.4
Patched in: 4.12.4

Summary: Hono Vulnerable to Cookie Attribute Injection via Unsanitized domain and path in setCookie()

Details:
## Summary

The `setCookie()` utility did not validate semicolons (`;`), carriage returns (`\r`), or newline characters (`\n`) in the `domain` and `path` options when constructing the `Set-Cookie` header.

Because cookie attributes are delimited by semicolons, this could allow injection of additional cookie attributes if untrusted input was passed into these fields.

## Details

`setCookie()` builds the `Set-Cookie` header by concatenating option values. While the cookie value itself is URL-encoded, the `domain` and `path` options were previously interpolated without rejecting unsafe characters.

Including `;`, `\r`, or `\n` in these fields could result in unintended additional attributes (such as `SameSite`, `Secure`, `Domain`, or `Path`) being appended to the cookie header.

Modern runtimes prevent full header injection via CRLF, so this issue is limited to attribute-level manipulation within a single `Set-Cookie` header.

The issue has been fixed by rejecting these characters in the `domain` and `path` options.

## Impact

An attacker may be able to manipulate cookie attributes if an application passes user-controlled input directly into the `domain` or `path` options of `setCookie()`.

This could affect cookie scoping or security attributes depending on browser behavior. Exploitation requires application-level misuse of cookie options.
GitHub Security Advisory: GHSA-p6xx-57qc-3wxr
Package: hono (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: < 4.12.4
Patched in: 4.12.4

Summary: Hono Vulnerable to SSE Control Field Injection via CR/LF in writeSSE()

Details:
## Summary

When using `streamSSE()` in Streaming Helper, the `event`, `id`, and `retry` fields were not validated for carriage return (`\r`) or newline (`\n`) characters.

Because the SSE protocol uses line breaks as field delimiters, this could allow injection of additional SSE fields within the same event frame if untrusted input was passed into these fields.

## Details

The SSE helper builds event frames by joining lines with `\n`. While multi-line `data:` fields are handled according to the SSE specification, the `event`, `id`, and `retry` fields previously allowed raw values without rejecting embedded CR/LF characters.

Including CR/LF in these control fields could allow unintended additional fields (such as `data:`, `id:`, or `retry:`) to be injected into the event stream.

The issue has been fixed by rejecting CR/LF characters in these fields.

## Impact

An attacker could manipulate the structure of SSE event frames if an application passed user-controlled input directly into `event`, `id`, or `retry`.

Depending on application behavior, this could result in injected SSE fields or altered event stream handling. Applications that render `e.data` in an unsafe manner (for example, using `innerHTML`) could potentially expose themselves to client-side script injection.

This issue affects applications that rely on the SSE helper to enforce protocol-level constraints.
GitHub Security Advisory: GHSA-q5qw-h33p-qvwr
Package: hono (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-177: Improper Handling of URL Encoding (Hex Encoding)
Vulnerable versions: < 4.12.4
Patched in: 4.12.4

Summary: Hono vulnerable to arbitrary file access via serveStatic vulnerability 

Details:
## Summary

When using `serveStatic` together with route-based middleware protections (e.g. `app.use('/admin/*', ...)`), inconsistent URL decoding allowed protected static resources to be accessed without authorization.

The router used `decodeURI`, while `serveStatic` used `decodeURIComponent`. This mismatch allowed paths containing encoded slashes (`%2F`) to bypass middleware protections while still resolving to the intended filesystem path.


## Details

The routing layer preserved `%2F` as a literal string, while `serveStatic` decoded it into `/` before resolving the file path.

Example:

Request: `/admin%2Fsecret.html`

- Router sees: `/admin%2Fsecret.html` → does not match `/admin/*`
- Static handler resolves: `/admin/secret.html`

As a result, static files under the configured static root could be served without triggering route-based protections.

This only affects applications that both:

- Protect subpaths using route-based middleware, and
- Serve files from the same static root using `serveStatic`.

This does **not** allow access outside the static root and is **not** a path traversal vulnerability.


## Impact

An unauthenticated attacker could bypass route-based authorization for protected static resources by supplying paths containing encoded slashes.

Applications relying solely on route-based middleware to protect static subpaths may have exposed those resources.
GitHub Security Advisory: GHSA-jwf4-8wf4-jf2m
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.2.22
Patched in: 2026.2.22

Summary: OpenClaw: BlueBubbles (optional plugin) pairing/allowlist mismatch when allowFrom is empty

Details:
### Summary
BlueBubbles is an optional OpenClaw channel plugin. A configuration-sensitive access-control mismatch allowed DM senders to be treated as authorized when `dmPolicy` was `pairing` or `allowlist` and `allowFrom` was empty/unset.

### Severity Rationale (Medium)
Severity is set to **medium** because:
- this affects an optional plugin, not core messaging surfaces;
- many deployments use owner-controlled/private BlueBubbles identities with limited external reachability;
- practical exploitability depends on an untrusted sender being able to reach that specific BlueBubbles account identifier.

In typical personal/self-hosted BlueBubbles setups, the mapped Apple identity is single-owner and not broadly reachable, so this is usually low practical risk.

Risk is higher in deployments where the identifier is publicly reachable and/or agent tool permissions are broad.

### Technical Details
1. BlueBubbles DM policy defaults to `pairing` (`dmPolicy ?? "pairing"`).
2. Effective allowlist can be empty (`effectiveAllowFrom`).
3. DM/reaction authorization called `isAllowedBlueBubblesSender(...)`.
4. That delegated to shared `isAllowedParsedChatSender(...)`, which previously returned `true` for empty allowlists.
5. Result: unknown senders could bypass intended pairing/allowlist gating when `allowFrom` was empty.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Vulnerable versions: `<= 2026.2.21-2`
- Planned fixed version: `2026.2.22`

### Fix
The shared parsed-chat allowlist helper now fails closed on empty allowlists, restoring expected BlueBubbles DM gating behavior. BlueBubbles inbound gating was also refactored to use one shared DM/group decision helper for both message and reaction paths to reduce future drift.

### Fix Commit(s)
- `9632b9bcf032c5f2280c3103961fde912ab1f920`
- `2ba6de7eaad812e5e8603018e14e54e96bdd57dd`
- `51c0893673de8e5cea64e64351dbfa4680ba0dec`
- `4540790cb62412676f7b61cfc6e47443f84a251e`

OpenClaw thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-3jx4-q2m7-r496
Package: openclaw (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: <= 2026.2.24
Patched in: 2026.2.25

Summary: OpenClaw: Hardlink alias checks could bypass workspace-only file boundaries in specific configurations

Details:
### Summary
In certain workspace-restricted configurations, OpenClaw could follow hardlink aliases inside the workspace that reference files outside the workspace boundary.

By default, `tools.fs.workspaceOnly` is off. This primarily affects deployments that intentionally enable workspace-only filesystem restrictions (and workspace-only `apply_patch` checks).

### Impact
- Confidentiality: out-of-workspace files could be read through in-workspace hardlink aliases.
- Integrity: out-of-workspace files could be modified through in-workspace hardlink aliases.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published version at triage time: `2026.2.24`
- Affected range: `<= 2026.2.24`
- Planned patched version: `2026.2.25`

### Fix Commit(s)
- `04d91d0319b82fd4de91ed05e9fc5219ff2ab64e` (main)

### Remediation
OpenClaw now rejects hardlinked final-file aliases during workspace boundary validation for:
- workspace-only path checks (`read` / `write` / `edit`)
- workspace-only `apply_patch` read/write paths
- sandbox mount-root path-safety checks

Regression tests were added for `apply_patch`, workspace fs tools, and sandbox fs bridge hardlink alias escapes.

OpenClaw thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-q6qf-4p5j-r25g
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-284: Improper Access Control
Vulnerable versions: < 2026.2.23
Patched in: 2026.2.23

Summary: OpenClaw's image tool bypasses tools.fs.workspaceOnly on sandbox mount paths and exfiltrates out-of-workspace images

Details:
### Summary
In OpenClaw, the sandboxed `image` tool did not honor `tools.fs.workspaceOnly=true` for mounted paths resolved by the sandbox FS bridge. This allowed reading out-of-workspace mounted images (for example `/agent/*`) and forwarding those bytes to vision model providers.

### Impact
Sandbox boundary bypass with confidentiality impact. In affected versions, `read`/`write`/`edit` respected workspace-only guardrails, but `image` could still load mounted out-of-workspace files and exfiltrate them via model requests.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected versions: `<= 2026.2.22-2`
- Patched versions: `>= 2026.2.23` (released)
- Latest published npm at triage time: `2026.2.22-2`

### Technical Details
`workspaceOnly` was enforced in sandbox file tools and `apply_patch`, but not propagated/enforced for `image` sandbox path resolution. The fix threads `workspaceOnly` into image-tool construction and asserts sandbox-root containment before loading media bytes.

### Fix Commit(s)
- `dd9d9c1c609dcb4579f9e57bd7b5c879d0146b53`

OpenClaw thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-4rqq-w8v4-7p47
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 2026.2.22
Patched in: 2026.2.22

Summary: OpenClaw has incomplete IPv4 special-use SSRF blocking in web fetch guard

Details:
### Summary
`isPrivateIpv4()` in bundled SSRF guard code missed several IPv4 special-use/non-global ranges, so `web_fetch` could allow targets that should be blocked by SSRF policy.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published affected version: `2026.2.21-2` (published 2026-02-21)
- Structured vulnerable range: `<= 2026.2.21-2`
- Planned patched version (pre-set): `>= 2026.2.22`

### Impact
Low severity. Exploitation requires network reachability to the relevant special-use ranges and a request path that reaches `web_fetch` URL fetching.

### Technical Details
Affected releases used narrow IPv4 private-range checks that omitted multiple RFC special-use/non-global ranges. This allowed requests such as `http://198.18.0.1/...` through SSRF validation in affected releases. Follow-up hardening consolidates local-host/tailnet range checks so gateway/browser/tailnet paths share one canonical IP classification flow.

### Fix Commit(s)
- `71bd15bb4294d3d1b54386064d69cd0f5f731bd8`
- `44dfbd23df453e51b71ef79a148c28c53e89168c`
- `333fbb[PII_REDACTED]6dd514290adfd5f727caa6d9`
- `f14ebd743cfc73f667fae80af70043d0ab1f88bd`

OpenClaw thanks @princeeismond-dot for reporting.
GitHub Security Advisory: GHSA-9mph-4f7v-fmvh
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: < 2026.2.22
Patched in: 2026.2.22

Summary: OpenClaw has agent avatar symlink traversal in gateway session metadata

Details:
## Summary
A crafted local avatar path could follow a symlink outside the agent workspace and return arbitrary file contents as a base64 `data:` URL in gateway responses.

## Impact
- Confidentiality impact: local file read in the gateway process context.
- Exfiltration path: `agents.list` can return the resulting `avatarUrl` payload.

## Affected Components
- `src/gateway/session-utils.ts` (`resolveIdentityAvatarUrl`)

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Introduced: `v2026.1.21`
- Affected published versions: `<= 2026.2.21-2`
- Planned patched version: `2026.2.22`

## Remediation
- Resolve workspace and avatar paths with `realpath` and enforce realpath containment.
- Open files with `O_NOFOLLOW` when available.
- Compare pre-open and opened file identity (`dev`/`ino`) to block swap races.
- Add regression tests for outside-workspace symlink rejection and in-workspace symlink allowance.

## Fix Commit(s)
- `3d[PII_REDACTED]954237d09e4d957df5cb844d5e77`

OpenClaw thanks @aether-ai-agent for reporting.
GitHub Security Advisory: GHSA-f6h3-846h-2r8w
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 2026.2.22
Patched in: 2026.2.22

Summary: OpenClaw's elevated allowFrom accepted broader identity signals than specified within sender-scoped authorization

Details:
### Summary
In certain elevated-mode configurations, `tools.elevated.allowFrom` accepted broader identity signals than intended. The fix tightens matching to sender-scoped identity by default and makes mutable metadata matching explicit.

### Context
OpenClaw is commonly used in 1:1 chats or trusted group chats. In that intended model, this issue is best treated as authorization hardening / defense-in-depth for elevated sender approval.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published npm version at triage: `2026.2.21-2`
- Affected versions: `<= 2026.2.21-2`
- Planned patched version (pre-set for publish-ready advisory): `2026.2.22`

### Details
Elevated sender authorization now matches sender-scoped identity values only by default (`SenderId`, `From`, `SenderE164`) and no longer considers recipient routing fields such as `ctx.To`.

Mutable sender metadata (`SenderName`, `SenderUsername`, `SenderTag`) now requires explicit allowlist prefixes (`name:`, `username:`, `tag:`). Explicit identity prefixes are also supported (`id:`, `from:`, `e164:`).

### Fix Commit(s)
- `6817c0ec7b4fa830123d4f5c340f075a4bd04ee2`

### Release Process Note
The advisory `patched_versions` is pre-set to the planned next release (`2026.2.22`). Once npm `openclaw@2026.2.22` is published, this advisory can be published without additional content edits.

OpenClaw thanks @jiseoung for reporting.
GitHub Security Advisory: GHSA-vjp8-wprm-2jw9
Package: openclaw (NPM)
Severity: LOW (CVSS 3.7)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 2026.2.25
Patched in: 2026.2.26

Summary: OpenClaw has cross-account DM pairing authorization bypass via unscoped pairing store access

Details:
### Summary
OpenClaw had account-scope gaps in pairing-store access for DM pairing policy, which could let a pairing approval from one account authorize the same sender on another account in multi-account setups.

### Impact
This is an authorization-boundary weakness in multi-account channel deployments. A sender approved in one account could be accepted in another account before explicit approval there.

### Affected Packages / Versions
- Package: `openclaw` (npm)
- Latest published version affected: `2026.2.25`
- Vulnerable range: `<= 2026.2.25`
- Patched version (planned next release): `>= 2026.2.26`

### Fix
OpenClaw now enforces account-scoped pairing reads/writes consistently across core and extension message channels, with stricter runtime/SDK helpers and shared policy wiring to prevent cross-account pairing bleed.

### Fix Commit(s)
- `a0c5e28f3bf0cc0cd9311f9e9ec2ca0352550dcf`
- `bce643a0bd145d3e9cb55400af33bd1b85baeb02`

### Release Process Note
`patched_versions` is pre-set to the planned next release (`2026.2.26`). After npm publish of that version, this advisory is ready to publish without further content edits.

OpenClaw thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-8cp7-rp8r-mg77
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 2026.1.20, < 2026.2.19
Patched in: 2026.2.19

Summary: OpenClaw has SSRF guard bypass via IPv6 transition over ISATAP

Details:
## Summary
OpenClaw's SSRF hostname/IP guard did not detect ISATAP embedded IPv4 addresses (`...:5efe:w.x.y.z`). A crafted URL containing an ISATAP IPv6 literal could embed a private IPv4 target (for example loopback) and bypass private-address filtering in URL-fetching paths.

## Severity Assessment
Rated **medium**: the bug weakens SSRF protections in URL fetch flows, but impact depends on reaching a URL-fetching path with attacker-controlled input and is generally constrained to internal network access attempts.

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected: `>=2026.1.20 <=2026.2.17`
- Latest published at patch time: `2026.2.17`
- Patched release: `2026.2.19`

## Security Policy Context
Per `SECURITY.md`, OpenClaw's web/gateway surface is intended for local use by default, public internet exposure is out-of-scope, and prompt-injection reports are out-of-scope for bounty handling. This advisory tracks a core SSRF-guard bypass in fetch protections.

## Impact
This can permit SSRF-style access attempts to internal/private network targets through URL ingestion/fetch paths that rely on shared hostname/IP blocking.

## Fix
- Added RFC 5214 ISATAP embedded-IPv4 detection to the shared SSRF classifier.
- Centralized hostname/IP blocking through `isBlockedHostnameOrIp` and routed relevant validators to that shared path.
- Added regression tests for ISATAP private vs public embedded IPv4 handling.

## Fix Commit(s)
- `d51929ecb52fe65e90bf36795f4247feb29eb8aa`

OpenClaw thanks @zpbrent for reporting.