deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-q4fm-pjq6-m63g
Package: n8n (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.123.25
Patched in: 1.123.25

Summary: n8n has a Stored XSS Vulnerability in its Form Trigger

Details:
## Impact
An authenticated user with permission to create or modify workflows could exploit a flaw in the Form Trigger node's CSS sanitization to store a cross-site scripting (XSS) payload. The injected script executes persistently for every visitor of the published form, enabling form submission hijacking and phishing. The existing Content Security Policy prevents direct n8n session cookie theft but does not prevent script execution or form action manipulation.

## Patches
The issue has been fixed in n8n versions 2.12.0, 2.11.2, and 1.123.25. 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 Form Trigger node by adding `n8n-nodes-base.formTrigger` 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-q4fm-pjq6-m63g
Package: n8n (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.0.0-rc.0, < 2.11.2
Patched in: 2.11.2

Summary: n8n has a Stored XSS Vulnerability in its Form Trigger

Details:
## Impact
An authenticated user with permission to create or modify workflows could exploit a flaw in the Form Trigger node's CSS sanitization to store a cross-site scripting (XSS) payload. The injected script executes persistently for every visitor of the published form, enabling form submission hijacking and phishing. The existing Content Security Policy prevents direct n8n session cookie theft but does not prevent script execution or form action manipulation.

## Patches
The issue has been fixed in n8n versions 2.12.0, 2.11.2, and 1.123.25. 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 Form Trigger node by adding `n8n-nodes-base.formTrigger` 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-3843-rr4g-m8jq
Package: express-xss-sanitizer (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-183: Permissive List of Allowed Inputs
Vulnerable versions: < 2.0.2
Patched in: 2.0.2

Summary: Express XSS Sanitizer: allowedTags/allowedAttributes bypass leads to permissive sanitization (XSS risk)

Details:
## Description
A vulnerability has been identified in express-xss-sanitizer (<= 2.0.1) where restrictive sanitization configurations are silently ignored.

When a developer explicitly sets:

  allowedTags: []
  allowedAttributes: {}

the library incorrectly treats these values as "not provided" due to length/emptiness checks, and falls back to sanitize-html's default configuration.

As a result, instead of stripping all HTML tags and attributes, the sanitizer allows a permissive set of tags ``` (e.g., <a>, <p>, <div>, etc.) and attributes (e.g., href on <a>)```.

This behavior violates the expected API contract and may lead to security issues such as content injection or XSS, depending on how the sanitized output is used.

##  Impact

Developers intending to fully strip HTML content by providing empty allowedTags or allowedAttributes configurations may unknowingly allow a wide range of HTML elements and attributes.

This can result in:
- Injection of unintended HTML content ```(e.g., <div>, <table>, headings)```
- Injection of links via``` <a href="...">```
- Potential XSS vectors depending on downstream usage

The impact depends on how the sanitized output is rendered or consumed, but the root issue is a mismatch between developer intent and actual behavior.

## Proof of Concept

```javascript
const { sanitize } = require('express-xss-sanitizer');
const sanitizeHtml = require('sanitize-html');

const input = '<a href="http://evil.com">click</a><p>phish</p>';

// Using express-xss-sanitizer (v2.0.1)
sanitize(input, { allowedTags: [], allowedAttributes: {} });
// => '<a href="http://evil.com">click</a><p>phish</p>'

// Expected behavior (sanitize-html directly)
sanitizeHtml(input, { allowedTags: [], allowedAttributes: {} });
// => 'clickphish'
```

## Root Cause
The issue was caused by validation logic that checked for non-empty arrays/objects:

- allowedTags required length > 0
- allowedAttributes required Object.keys(...).length > 0

This caused empty configurations ([]) and ({}) to be ignored, resulting in fallback to default permissive settings.

## Fix
The validation logic has been updated to respect explicitly provided empty configurations.

Now, if allowedTags or allowedAttributes are provided (even if empty), they are passed directly to sanitize-html without being overridden.
GitHub Security Advisory: GHSA-89v5-38xr-9m4j
Package: postiz (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 2.0.12
Patched in: unpatched

Summary: Postiz has Multiple SSRF Vectors - Webhooks, RSS Feed, URL Loader

Details:
## Summary

Postiz has multiple SSRF vulnerabilities where user-provided URLs are fetched server-side without any IP validation or SSRF protection.

## Vulnerable Code

### 1. Webhook Send Endpoint (Most Critical)

**`apps/backend/src/api/routes/webhooks.controller.ts` lines 58-70:**
```typescript
async sendWebhook(@Body() body: any, @Query('url') url: string) {
  try {
    await fetch(url, {  // No URL validation
      method: 'POST',
      body: JSON.stringify(body),
      headers: { 'Content-Type': 'application/json' },
    });
  } catch (err) { }
  return { send: true };
}
```

Accepts arbitrary URL via query parameter and fetches directly.

### 2. Stored Webhook Delivery

**`apps/orchestrator/src/activities/post.activity.ts` lines 256-281:**
```typescript
async sendWebhooks(postId: string, orgId: string, integrationId: string) {
  const webhooks = await this._webhookService.getWebhooks(orgId);
  return Promise.all(
    webhooks.map(async (webhook) => {
      await fetch(webhook.url, {  // Stored URL, no validation
        method: 'POST',
        body: JSON.stringify(post),
      });
    })
  );
}
```

### 3. RSS/XML Feed Parser

**`libraries/nestjs-libraries/src/database/prisma/autopost/autopost.service.ts` line 135:**
```typescript
async loadXML(url: string) {
  const { items } = await parser.parseURL(url);  // No URL validation
}
```

### 4. HTML Content Loader

**`libraries/nestjs-libraries/src/database/prisma/autopost/autopost.service.ts` line 185:**
```typescript
async loadUrl(url: string) {
  const loadDom = new JSDOM(await (await fetch(url)).text());  // No validation
}
```

## Missing Protections

- No `request-filtering-agent` or SSRF library
- No private IP range filtering
- No cloud metadata endpoint blocking
- No DNS rebinding protection
- URL validation only via `@IsUrl()` decorator (format only, no IP check)

## Attack Scenarios

1. `POST /webhooks/send?url=http://169.254.169.254/latest/meta-data/` → AWS metadata theft
2. `POST /autopost/send?url=http://127.0.0.1:6379` → Internal Redis access
3. Create webhook with `http://10.0.0.1:8080/admin` → Internal service access on post publish

## Impact

- **Cloud metadata theft**: AWS/GCP/Azure credentials
- **Internal network scanning**: Full access to private IP ranges
- **Multiple entry points**: Webhooks, RSS feeds, URL loader all vulnerable
GitHub Security Advisory: GHSA-vj2p-7pgw-g2wf
Package: postiz (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF), CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: <= 2.0.12
Patched in: unpatched

Summary: Postiz App has a High-Severity SSRF Vulnerability via Next.js

Details:
### Impact
A successful SSRF attack allows an attacker to:
- Bypass firewalls to scan and interact with internal network services/ports.
- Access sensitive cloud metadata services (e.g., AWS IMDS 169.254.169.254) to potentially leak instance credentials.
- Pivot into the internal network environment where Postiz is hosted.

### Workarounds
There are no workarounds known to this, please upgrade to Postiz version `v2.21.1`.
GitHub Security Advisory: GHSA-f886-m6hf-6m8v
Package: brace-expansion (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 1.1.13
Patched in: 1.1.13

Summary: brace-expansion: Zero-step sequence causes process hang and memory exhaustion

Details:
### Impact

A brace pattern with a zero step value (e.g., `{1..2..0}`) causes the sequence generation loop to run indefinitely, making the process hang for seconds and allocate heaps of memory.

The loop in question:

https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L184

`test()` is one of

https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L107-L113

The increment is computed as `Math.abs(0) = 0`, so the loop variable never advances. On a test machine, the process hangs for about 3.5 seconds and allocates roughly 1.9 GB of memory before throwing a `RangeError`. Setting max to any value has no effect because the limit is only checked at the output combination step, not during sequence generation.

This affects any application that passes untrusted strings to expand(), or by error sets a step value of `0`. That includes tools built on minimatch/glob that resolve patterns from CLI arguments or config files. The input needed is just 10 bytes.

### Patches


Upgrade to versions
- 5.0.5+

A step increment of 0 is now sanitized to 1, which matches bash behavior.

### Workarounds

Sanitize strings passed to `expand()` to ensure a step value of `0` is not used.
GitHub Security Advisory: GHSA-f886-m6hf-6m8v
Package: brace-expansion (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 2.0.0, < 2.0.3
Patched in: 2.0.3

Summary: brace-expansion: Zero-step sequence causes process hang and memory exhaustion

Details:
### Impact

A brace pattern with a zero step value (e.g., `{1..2..0}`) causes the sequence generation loop to run indefinitely, making the process hang for seconds and allocate heaps of memory.

The loop in question:

https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L184

`test()` is one of

https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L107-L113

The increment is computed as `Math.abs(0) = 0`, so the loop variable never advances. On a test machine, the process hangs for about 3.5 seconds and allocates roughly 1.9 GB of memory before throwing a `RangeError`. Setting max to any value has no effect because the limit is only checked at the output combination step, not during sequence generation.

This affects any application that passes untrusted strings to expand(), or by error sets a step value of `0`. That includes tools built on minimatch/glob that resolve patterns from CLI arguments or config files. The input needed is just 10 bytes.

### Patches


Upgrade to versions
- 5.0.5+

A step increment of 0 is now sanitized to 1, which matches bash behavior.

### Workarounds

Sanitize strings passed to `expand()` to ensure a step value of `0` is not used.
GitHub Security Advisory: GHSA-f886-m6hf-6m8v
Package: brace-expansion (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.0.0, < 3.0.2
Patched in: 3.0.2

Summary: brace-expansion: Zero-step sequence causes process hang and memory exhaustion

Details:
### Impact

A brace pattern with a zero step value (e.g., `{1..2..0}`) causes the sequence generation loop to run indefinitely, making the process hang for seconds and allocate heaps of memory.

The loop in question:

https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L184

`test()` is one of

https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L107-L113

The increment is computed as `Math.abs(0) = 0`, so the loop variable never advances. On a test machine, the process hangs for about 3.5 seconds and allocates roughly 1.9 GB of memory before throwing a `RangeError`. Setting max to any value has no effect because the limit is only checked at the output combination step, not during sequence generation.

This affects any application that passes untrusted strings to expand(), or by error sets a step value of `0`. That includes tools built on minimatch/glob that resolve patterns from CLI arguments or config files. The input needed is just 10 bytes.

### Patches


Upgrade to versions
- 5.0.5+

A step increment of 0 is now sanitized to 1, which matches bash behavior.

### Workarounds

Sanitize strings passed to `expand()` to ensure a step value of `0` is not used.
GitHub Security Advisory: GHSA-f886-m6hf-6m8v
Package: brace-expansion (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 4.0.0, < 5.0.5
Patched in: 5.0.5

Summary: brace-expansion: Zero-step sequence causes process hang and memory exhaustion

Details:
### Impact

A brace pattern with a zero step value (e.g., `{1..2..0}`) causes the sequence generation loop to run indefinitely, making the process hang for seconds and allocate heaps of memory.

The loop in question:

https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L184

`test()` is one of

https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L107-L113

The increment is computed as `Math.abs(0) = 0`, so the loop variable never advances. On a test machine, the process hangs for about 3.5 seconds and allocates roughly 1.9 GB of memory before throwing a `RangeError`. Setting max to any value has no effect because the limit is only checked at the output combination step, not during sequence generation.

This affects any application that passes untrusted strings to expand(), or by error sets a step value of `0`. That includes tools built on minimatch/glob that resolve patterns from CLI arguments or config files. The input needed is just 10 bytes.

### Patches


Upgrade to versions
- 5.0.5+

A step increment of 0 is now sanitized to 1, which matches bash behavior.

### Workarounds

Sanitize strings passed to `expand()` to ensure a step value of `0` is not used.
GitHub Security Advisory: GHSA-2qvq-rjwj-gvw9
Package: handlebars (NPM)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 4.0.0, < 4.7.9
Patched in: 4.7.9

Summary: Handlebars.js has Prototype Pollution Leading to XSS through Partial Template Injection

Details:
## Summary

`resolvePartial()` in the Handlebars runtime resolves partial names via a plain property lookup on `options.partials` without guarding against prototype-chain traversal. When `Object.prototype` has been polluted with a string value whose key matches a partial reference in a template, the polluted string is used as the partial body and rendered **without HTML escaping**, resulting in reflected or stored XSS.

## Description

The root cause is in `lib/handlebars/runtime.js` inside `resolvePartial()` and `invokePartial()`:

```javascript
// Vulnerable: plain bracket access traverses Object.prototype
partial = options.partials[options.name];
```

`hasOwnProperty` is never checked, so if `Object.prototype` has been seeded with a key whose name matches a partial reference in the template (e.g. `widget`), the lookup succeeds and the polluted string is returned. The runtime emits a prototype-access warning, but the partial is still resolved and its content is inserted into the rendered output unescaped. This contradicts the documented security model and is distinct from CVE-2021-23369 and CVE-2021-23383, which addressed data property access rather than partial template resolution.

**Prerequisites for exploitation:**
1. The target application must be vulnerable to prototype pollution (e.g. via `qs`, `minimist`, or
   any querystring/JSON merge sink).
2. The attacker must know or guess the name of a partial reference used in a template.

## Proof of Concept

```javascript
const Handlebars = require('handlebars');

// Step 1: Prototype pollution (via qs, minimist, or another vector)
Object.prototype.widget = '<img src=x onerror="alert(document.domain)">';

// Step 2: Normal template that references a partial
const template = Handlebars.compile('<div>Welcome! {{> widget}}</div>');

// Step 3: Render — XSS payload injected unescaped
const output = template({});
// Output: <div>Welcome! <img src=x onerror="alert(document.domain)"></div>
```

> The runtime prints a prototype access warning claiming "access has been denied," but the partial still resolves and returns the polluted value.

## Workarounds

- Apply `Object.freeze(Object.prototype)` early in application startup to prevent prototype  pollution. Note: this may break other libraries.
- Use the Handlebars runtime-only build (`handlebars/runtime`), which does not compile templates  and reduces the attack surface.
GitHub Security Advisory: GHSA-cfp9-w5v9-3q4h
Package: openclaw (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-668: Exposure of Resource to Wrong Sphere, CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.3.2
Patched in: 2026.3.2

Summary: OpenClaw: Image Tool `tools.fs.workspaceOnly` Bypass via Sandbox Bridge Mounts

Details:
## Summary
The `image` tool did not fully honor the `tools.fs.workspaceOnly` filesystem boundary. In affected releases, image-path resolution could still traverse sandbox bridge mounts outside the workspace and read files from mounted directories that the other file tools would reject.

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

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

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

## Code-Level Confirmation
- `src/agents/openclaw-tools.ts` now passes `fsPolicy` into `createImageTool`, so the image tool receives the same workspace-only policy input as the other filesystem tools.
- `src/agents/tools/image-tool.ts`, `src/agents/tools/media-tool-shared.ts`, and `src/agents/sandbox-media-paths.ts` now restrict local roots and sandbox-bridge resolution to the workspace when `tools.fs.workspaceOnly` is enabled.

OpenClaw thanks @YLChen-007 for reporting.
GitHub Security Advisory: GHSA-74wf-h43j-vvmj
Package: openclaw (NPM)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-807: Reliance on Untrusted Inputs in a Security Decision, CWE-863: Incorrect Authorization
Vulnerable versions: < 2026.3.22
Patched in: 2026.3.22

Summary: OpenClaw's Conflicting Tool Identity Hints Bypass Dangerous-Tool Prompting

Details:
## Summary
ACP permission resolution trusted conflicting tool identity hints from rawInput and metadata, which could suppress dangerous-tool prompting.

## 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)
- `e4c61723cd2d530680cc61789311d464ab8cdf60`

## 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/acp/client.ts now fails closed when meta, rawInput, and title tool identities conflict instead of trusting spoofable raw input.
- src/acp/client.test.ts ships regressions for conflicting tool identity hints and dangerous-tool prompting.

OpenClaw thanks @zpbrent for reporting.
GitHub Security Advisory: GHSA-rqp8-q22p-5j9q
Package: openclaw (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-285: Improper Authorization
Vulnerable versions: < 2026.3.22
Patched in: 2026.3.22

Summary: OpenClaw Bypasses DM Policy Separation via Synology Chat Webhook Path Collision 

Details:
## Summary
Synology Chat multi-account configuration could collapse onto a shared webhook path, replacing route ownership and bypassing per-account DM policy separation.

## 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)
- `980940aa58f862da4e19372597bbc2a9f268d70b`

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

## Code-Level Confirmation
- extensions/synology-chat/src/accounts.ts now distinguishes inherited base webhook paths from explicit per-account paths.
- extensions/synology-chat/src/gateway-runtime.ts now fails closed on inherited or duplicate webhook paths and registers routes without replacement.

OpenClaw thanks @tdjackey for reporting.
GitHub Security Advisory: GHSA-x2cm-hg9c-mf5w
Package: openclaw (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-285: Improper Authorization, CWE-862: Missing Authorization
Vulnerable versions: < 2026.3.22
Patched in: 2026.3.22

Summary: OpenClaw leaf subagents can bypass controlScope restrictions to send messages to child sessions

Details:
## Summary
Leaf subagents could still use the send action to message controlled child sessions even when their controlScope was narrower than children.

## 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)
- `7679eb375294941b02214c234aff[PII_REDACTED]d0`

## 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/auto-reply/reply/commands-subagents/action-send.ts now threads controller context through the send path.
- src/agents/subagent-control.ts now blocks send attempts unless the requester owns the target and has controlScope="children".

OpenClaw thanks @space08 for reporting.