deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-h3x4-hc5v-v2gm
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-40: Path Traversal: 'UNCsharename' (Windows UNC Share)
Vulnerable versions: < 2026.3.22
Patched in: 2026.3.22

Summary: OpenClaw: Windows media loaders accepted remote-host file URLs before local path validation

Details:
## Summary
Windows local-media handling accepted remote-host file URLs and UNC-style paths before local-path validation, so network-hosted file targets could be treated as local content.

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected: < 2026.3.22
- Fixed: >= 2026.3.22
- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)
- Latest published npm version checked: `2026.3.23-2`

## Fix Commit(s)
- `4fd7feb0fd4ec16c48ed983980dba79a09b3aaf5`
- `93880717f1cd34feaa45e74e939b7a[PII_REDACTED]`

## Release Status
The fix shipped in `v2026.3.22` and remains present in `v2026.3.23` and `v2026.3.23-2`.

## Code-Level Confirmation
- src/infra/local-file-access.ts now rejects remote-host file: URLs and UNC/network paths as non-local input.
- src/media/web-media.ts, src/media-understanding/attachments.normalize.ts, and src/agents/sandbox-paths.ts all route through the shared local-file guard.

OpenClaw thanks @RacerZ-fighting, @Fushuling for reporting.
GitHub Security Advisory: GHSA-wq58-2pvg-5h4f
Package: openclaw (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 2026.3.23
Patched in: 2026.3.23

Summary: OpenClaw: Gateway agent /reset exposes admin session reset to operator.write callers

Details:
## Summary
Before `v2026.3.23`, the Gateway `agent` RPC accepted `/reset` and `/new` for callers with only `operator.write`, even though the direct `sessions.reset` RPC correctly requires `operator.admin`.

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected: `< 2026.3.23`
- Fixed: `>= 2026.3.23`
- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)
- Latest published npm version checked: `2026.3.23-2`

## Root Cause
The vulnerable path lived in `src/gateway/server-methods/agent.ts`. A `/reset` or `/new` message with an explicit `sessionKey` reached `performGatewaySessionReset(...)` without enforcing the same `operator.admin` guard used by `sessions.reset`.

## Fix Commit(s)
- `50f6a2f136fed85b58548a38f7a3dbb98d2cd1a0` — `fix(gateway): require admin for agent session reset`

## Release Status
The fix commit is contained in released tags `v2026.3.23` and `v2026.3.23-2`. The latest shipped tag and npm release both include the fix.

## Code-Level Confirmation
- `src/gateway/server-methods/agent.ts` now rejects `/reset` and `/new` for callers that do not have `operator.admin` before calling `performGatewaySessionReset(...)`.
- `src/gateway/server-methods/agent.test.ts` contains the regression test `rejects /reset for write-scoped gateway callers`.

Thanks @smaeljaish771 for reporting.
GitHub Security Advisory: GHSA-6mqc-jqh6-x8fc
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 2026.3.23
Patched in: 2026.3.23

Summary: OpenClaw: Gateway Canvas local-direct requests bypass Canvas HTTP and WebSocket authentication

Details:
## Summary
Before `v2026.3.23`, Canvas and A2UI loopback requests could bypass Canvas bearer-or-capability authentication because `authorizeCanvasRequest(...)` treated `isLocalDirectRequest(...)` as an unconditional allow path.

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected: `< 2026.3.23`
- Fixed: `>= 2026.3.23`
- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)
- Latest published npm version checked: `2026.3.23-2`

## Root Cause
The vulnerable logic lived in `src/gateway/server/http-auth.ts`. `authorizeCanvasRequest(...)` returned `{ ok: true }` for local-direct requests before checking bearer authentication or an active node canvas capability, which meant unauthenticated loopback Canvas HTTP and WebSocket requests could succeed.

## Fix Commit(s)
- `d5dc6b6573ae489bc7e5651090f4767b93537c9e` — `fix(gateway): require auth for canvas routes`

## Release Status
The fix commit is contained in released tags `v2026.3.23` and `v2026.3.23-2`. The latest shipped tag and npm release both include the fix.

## Code-Level Confirmation
- `src/gateway/server/http-auth.ts` no longer contains the local-direct early return in `authorizeCanvasRequest(...)`.
- `src/gateway/server.canvas-auth.test.ts` adds the regression test `denies canvas HTTP/WS on loopback without bearer or capability by default`.

Thanks @smaeljaish771 for reporting.
GitHub Security Advisory: GHSA-cg6c-q2hx-69h7
Package: openclaw (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-294: Authentication Bypass by Capture-replay
Vulnerable versions: < 2026.3.23
Patched in: 2026.3.23

Summary: OpenClaw: Plivo V2 verified replay identity drifts on query-only variants

Details:
## Summary
Before `v2026.3.23`, the Plivo V2 verification path treated query-only variants of the same signed request as fresh verified work. Plivo V2 signatures authenticate `baseUrl + nonce`, but the replay key was derived from the full verification URL including the query string, so unsigned query-only changes minted a new `verifiedRequestKey`.

## Affected Packages / Versions
- Package: `openclaw` (npm)
- Affected: `< 2026.3.23`
- Fixed: `>= 2026.3.23`
- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)
- Latest published npm version checked: `2026.3.23-2`

## Root Cause
The vulnerable logic lived in `extensions/voice-call/src/webhook-security.ts`. V2 signature validation already canonicalized to the base URL without query parameters, but the replay key used the full `verificationUrl`, letting query-only variants bypass replay identity stability.

## Fix Commit(s)
- `b0ce53a79cf[PII_REDACTED]0513e26d921899b4e5b` — `fix(voice-call): stabilize plivo v2 replay keys`

## Release Status
The fix commit is contained in released tags `v2026.3.23` and `v2026.3.23-2`. The latest shipped tag and npm release both include the fix.

## Code-Level Confirmation
- `extensions/voice-call/src/webhook-security.ts` now derives the V2 replay key with `createPlivoV2ReplayKey(...)`, which hashes `getBaseUrlNoQuery(url)` plus the nonce.
- `extensions/voice-call/src/webhook-security.test.ts` contains the regression test `treats query-only V2 variants as the same verified request`.

Thanks @smaeljaish771 for reporting.
GitHub Security Advisory: GHSA-44fc-8fm5-q62h
Package: convict (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: <= 6.2.4
Patched in: 6.2.5

Summary: Convict has Prototype Pollution via startsWith() function

Details:
### Summary
A prototype pollution vulnerability exists in the latest version of the convict npm package (6.2.4). Despite a previous fix that attempted to mitigate prototype pollution by checking whether user input started with a forbidden key, it is still possible to pollute `Object.prototype` via a crafted input using `String.prototype`. 

### Details
The vulnerability resides in line 564 of https://github.com/mozilla/node-convict/blob/master/packages/convict/src/main.js where `startsWith()` function is used to check whether user provided input contain forbidden strings. 

### PoC
#### Steps to reproduce
1. Install latest version of convict using `npm install` or cloning from git
2. Run the following code snippet:

```javascript
String.prototype.startsWith = () => false; 
const convict = require('convict');
let obj = {};
const config = convict(obj);
console.log({}.polluted);
config.set('constructor.prototype.polluted', 'yes');
console.log({}.polluted);    // prints yes -> the patch is bypassed and prototype pollution occurred
```

#### Expected behavior
Prototype pollution should be prevented and {} should not gain new properties.
This should be printed on the console:
```
undefined
undefined OR throw an Error
```

#### Actual behavior
`Object.prototype` is polluted 
This is printed on the console:
```
undefined 
yes
```

### Impact
This is a prototype pollution vulnerability, which can have severe security implications depending on how convict is used by downstream applications. Any application that processes attacker-controlled input using `convict.set`  may be affected.
It could potentially lead to the following problems:

1. Authentication bypass
2. Denial of service
3. Remote code execution (if polluted property is passed to sinks like eval or child_process)
GitHub Security Advisory: GHSA-hf2r-9gf9-rwch
Package: convict (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: <= 6.2.4
Patched in: 6.2.5

Summary: Convict has prototype pollution via load(), loadFile(), and schema initialization

Details:
### Impact
Two unguarded prototype pollution paths exist, not covered by previous fixes:

1. `config.load()` / `config.loadFile()` — `overlay()` recursively merges config data without checking for forbidden keys. Input containing` __proto__` or `constructor.prototype` (e.g. from a JSON file) causes the recursion to reach `Object.prototype` and write attacker-controlled values onto it.
2. Schema initialization — passing a schema with `constructor.prototype.*` keys to `convict({...})` causes default-value propagation to write directly to `Object.prototype` at startup.

Depending on how polluted properties are consumed, impact ranges from unexpected behavior to authentication bypass or RCE.

### Workarounds
Do not pass untrusted data to load(), loadFile(), or convict().

### Resources
Prior advisory: [GHSA-44fc-8fm5-q62h](https://github.com/mozilla/node-convict/security/advisories/GHSA-44fc-8fm5-q62h)
Related issue: [https://github.com/mozilla/node-convict/issues/423](https://github.com/mozilla/node-convict/issues/423)
GitHub Security Advisory: GHSA-w83q-mcmx-mh42
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Vulnerable versions: >= 2.0.0-rc.0, < 2.13.3
Patched in: 2.13.3

Summary: n8n Vulnerable to LDAP Filter Injection in LDAP Node

Details:
## Impact
A flaw in the LDAP node's filter escape logic allowed LDAP metacharacters to pass through unescaped when user-controlled input was interpolated into LDAP search filters. In workflows where external user input is passed via expressions into the LDAP node's search parameters, an attacker could manipulate the constructed filter to retrieve unintended LDAP records or bypass authentication checks implemented in the workflow.

Exploitation requires a specific workflow configuration:
- The LDAP node must be used with user-controlled input passed via expressions (e.g., from a form or webhook).

## Patches
The issue has been fixed in n8n versions 1.123.27, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the LDAP node by adding `n8n-nodes-base.ldap` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into LDAP node search parameters via expressions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-w83q-mcmx-mh42
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Vulnerable versions: = 2.14.0
Patched in: 2.14.1

Summary: n8n Vulnerable to LDAP Filter Injection in LDAP Node

Details:
## Impact
A flaw in the LDAP node's filter escape logic allowed LDAP metacharacters to pass through unescaped when user-controlled input was interpolated into LDAP search filters. In workflows where external user input is passed via expressions into the LDAP node's search parameters, an attacker could manipulate the constructed filter to retrieve unintended LDAP records or bypass authentication checks implemented in the workflow.

Exploitation requires a specific workflow configuration:
- The LDAP node must be used with user-controlled input passed via expressions (e.g., from a form or webhook).

## Patches
The issue has been fixed in n8n versions 1.123.27, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the LDAP node by adding `n8n-nodes-base.ldap` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into LDAP node search parameters via expressions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-w83q-mcmx-mh42
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Vulnerable versions: < 1.123.27
Patched in: 1.123.27

Summary: n8n Vulnerable to LDAP Filter Injection in LDAP Node

Details:
## Impact
A flaw in the LDAP node's filter escape logic allowed LDAP metacharacters to pass through unescaped when user-controlled input was interpolated into LDAP search filters. In workflows where external user input is passed via expressions into the LDAP node's search parameters, an attacker could manipulate the constructed filter to retrieve unintended LDAP records or bypass authentication checks implemented in the workflow.

Exploitation requires a specific workflow configuration:
- The LDAP node must be used with user-controlled input passed via expressions (e.g., from a form or webhook).

## Patches
The issue has been fixed in n8n versions 1.123.27, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the LDAP node by adding `n8n-nodes-base.ldap` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into LDAP node search parameters via expressions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-qfc3-hm4j-7q77
Package: n8n (NPM)
Severity: MODERATE (CVSS 8.9)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.0.0-rc.0, < 2.13.3
Patched in: 2.13.3

Summary: n8n Vulnerable to XSS via Binary Data Inline HTML Rendering

Details:
## Impact
An authenticated user with permission to create or modify workflows could craft a workflow that produces an HTML binary data object without a filename. The `/rest/binary-data` endpoint served such responses inline on the n8n origin without `Content-Disposition` or `Content-Security-Policy` headers, allowing the HTML to render in the browser with full same-origin JavaScript access.

By sending the resulting URL to a higher-privileged user, an attacker could execute JavaScript in the victim's authenticated session, enabling exfiltration of workflows and credentials, modification of workflows, or privilege escalation to admin.

## Patches
The issue has been fixed in n8n versions 1.123.27, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Restrict network access to the n8n instance to prevent untrusted users from accessing binary data URLs.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-qfc3-hm4j-7q77
Package: n8n (NPM)
Severity: MODERATE (CVSS 8.9)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: = 2.14.0
Patched in: 2.14.1

Summary: n8n Vulnerable to XSS via Binary Data Inline HTML Rendering

Details:
## Impact
An authenticated user with permission to create or modify workflows could craft a workflow that produces an HTML binary data object without a filename. The `/rest/binary-data` endpoint served such responses inline on the n8n origin without `Content-Disposition` or `Content-Security-Policy` headers, allowing the HTML to render in the browser with full same-origin JavaScript access.

By sending the resulting URL to a higher-privileged user, an attacker could execute JavaScript in the victim's authenticated session, enabling exfiltration of workflows and credentials, modification of workflows, or privilege escalation to admin.

## Patches
The issue has been fixed in n8n versions 1.123.27, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Restrict network access to the n8n instance to prevent untrusted users from accessing binary data URLs.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-qfc3-hm4j-7q77
Package: n8n (NPM)
Severity: MODERATE (CVSS 8.9)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.123.27
Patched in: 1.123.27

Summary: n8n Vulnerable to XSS via Binary Data Inline HTML Rendering

Details:
## Impact
An authenticated user with permission to create or modify workflows could craft a workflow that produces an HTML binary data object without a filename. The `/rest/binary-data` endpoint served such responses inline on the n8n origin without `Content-Disposition` or `Content-Security-Policy` headers, allowing the HTML to render in the browser with full same-origin JavaScript access.

By sending the resulting URL to a higher-privileged user, an attacker could execute JavaScript in the victim's authenticated session, enabling exfiltration of workflows and credentials, modification of workflows, or privilege escalation to admin.

## Patches
The issue has been fixed in n8n versions 1.123.27, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Restrict network access to the n8n instance to prevent untrusted users from accessing binary data URLs.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-p36q-q72m-gchr
Package: srvx (NPM)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-706: Use of Incorrectly-Resolved Name or Reference
Vulnerable versions: < 0.11.13
Patched in: 0.11.13

Summary: srvx is vulnerable to middleware bypass via absolute URI in request line 

Details:
## Summary

A pathname parsing discrepancy in srvx's `FastURL` allows middleware bypass on the Node.js adapter when a raw HTTP request uses an absolute URI with a non-standard scheme (e.g. `file://`).

## Details

When Node.js receives an absolute URI in the request line (e.g. `GET file://hehe?/internal/run HTTP/1.1`), `req.url` is set verbatim to `file://hehe?/internal/run`. Since this doesn't start with `/`, `NodeRequestURL` passes it directly to `FastURL` as a string, which stores it in `#href` for lazy manual parsing.

`FastURL#getPos()` locates the pathname by finding `://` then scanning for the next `/` — but this fails for URLs like `file://hehe?/internal/run` where a `?` appears before the first `/` after the authority. The manual parser extracts pathname as `/internal/run`, while native `URL` correctly parses it as pathname `/` with search `?/internal/run`.

This discrepancy means the router (using the fast-path) matches `/internal/run`, but if any middleware triggers a deopt to native `URL` (e.g. by accessing `hostname`), subsequent middleware sees a different pathname — bypassing route-based middleware guards.

This is a bypass of [CVE-2026-33131](https://github.com/h3js/h3/security/advisories/GHSA-3vj8-jmxq-cgj5).

## Impact

Route-based middleware (auth guards, rate limiters, etc.) can be bypassed on the Node.js adapter when a prior middleware triggers `FastURL` deopt. Requires sending a raw HTTP request (not possible from browsers).

## Fix

srvx `FastURL` constructor now deopts to native `URL` for any string not starting with `/`, ensuring consistent pathname resolution.
GitHub Security Advisory: GHSA-98c2-4cr3-4jc3
Package: n8n (NPM)
Severity: HIGH (CVSS 9.9)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 2.0.0-rc.0, < 2.13.3
Patched in: 2.13.3

Summary: n8n has SQL Injection in Data Table Node via orderByColumn Expression

Details:
## Impact
An authenticated user with permission to create or modify workflows could exploit a SQL injection vulnerability in the Data Table Get node. On default SQLite DB, single statements can be manipulated and the attack surface is practically limited. On PostgreSQL deployments, multi-statement execution is possible, enabling data modification and deletion.

## Patches
The issue has been fixed in n8n versions 1.123.26, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Data Table node by adding `n8n-nodes-base.dataTable` to the `NODES_EXCLUDE` environment variable.
- Review existing workflows for Data Table Get nodes where `orderByColumn` is set to an expression that incorporates external or user-supplied input.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-98c2-4cr3-4jc3
Package: n8n (NPM)
Severity: HIGH (CVSS 9.9)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: = 2.14.0
Patched in: 2.14.1

Summary: n8n has SQL Injection in Data Table Node via orderByColumn Expression

Details:
## Impact
An authenticated user with permission to create or modify workflows could exploit a SQL injection vulnerability in the Data Table Get node. On default SQLite DB, single statements can be manipulated and the attack surface is practically limited. On PostgreSQL deployments, multi-statement execution is possible, enabling data modification and deletion.

## Patches
The issue has been fixed in n8n versions 1.123.26, 2.13.3, and 2.14.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Data Table node by adding `n8n-nodes-base.dataTable` to the `NODES_EXCLUDE` environment variable.
- Review existing workflows for Data Table Get nodes where `orderByColumn` is set to an expression that incorporates external or user-supplied input.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.