deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-c2c7-rcm5-vvqj
Package: picomatch (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 4.0.0, < 4.0.4
Patched in: 4.0.4

Summary: Picomatch has a ReDoS vulnerability via extglob quantifiers

Details:
### Impact
`picomatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as `+()` and `*()`, especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input.

Examples of problematic patterns include `+(a|aa)`, `+(*|?)`, `+(+(a))`, `*(+(a))`, and `+(+(+(a)))`. In local reproduction, these patterns caused multi-second event-loop blocking with relatively short inputs. For example, `+(a|aa)` compiled to `^(?:(?=.)(?:a|aa)+)$` and took about 2 seconds to reject a 41-character non-matching input, while nested patterns such as `+(+(a))` and `*(+(a))` took around 29 seconds to reject a 33-character input on a modern M1 MacBook.

Applications are impacted when they allow untrusted users to supply glob patterns that are passed to `picomatch` for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way.

### Patches
This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2.

Users should upgrade to one of these versions or later, depending on their supported release line.

### Workarounds
If upgrading is not immediately possible, avoid passing untrusted glob patterns to `picomatch`.

Possible mitigations include:
- disable extglob support for untrusted patterns by using `noextglob: true`
- reject or sanitize patterns containing nested extglobs or extglob quantifiers such as `+()` and `*()`
- enforce strict allowlists for accepted pattern syntax
- run matching in an isolated worker or separate process with time and resource limits
- apply application-level request throttling and input validation for any endpoint that accepts glob patterns

### Resources
- Picomatch repository: https://github.com/micromatch/picomatch
- `lib/parse.js` and `lib/constants.js` are involved in generating the vulnerable regex forms
- Comparable ReDoS precedent: CVE-2024-4067 (`micromatch`)
- Comparable generated-regex precedent: CVE-2024-45296 (`path-to-regexp`)
GitHub Security Advisory: GHSA-c545-x2rh-82fc
Package: n8n (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 1.121.0
Patched in: 1.121.0

Summary: n8n: LDAP Email-Based Account Linking Allows Privilege Escalation and Account Takeover

Details:
## Impact
When LDAP authentication is enabled, n8n automatically linked an LDAP identity to an existing local account if the LDAP email attribute matched the local account's email. An authenticated LDAP user who could control their own LDAP email attribute could set it to match another user's email — including an administrator's — and upon login gain full access to that account. The account linkage persisted even if the LDAP email was later reverted, resulting in a permanent account takeover.

- LDAP authentication must be configured and active (non-default).

## Patches
The issue has been fixed in n8n versions 2.4.0 and 1.121.0. 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:
- Disable LDAP authentication until the instance can be upgraded.
- Restrict LDAP directory permissions so that users cannot modify their own email attributes.
- Audit existing LDAP-linked accounts for unexpected account associations.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-c545-x2rh-82fc
Package: n8n (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 2.0.0-rc.0, < 2.4.0
Patched in: 2.4.0

Summary: n8n: LDAP Email-Based Account Linking Allows Privilege Escalation and Account Takeover

Details:
## Impact
When LDAP authentication is enabled, n8n automatically linked an LDAP identity to an existing local account if the LDAP email attribute matched the local account's email. An authenticated LDAP user who could control their own LDAP email attribute could set it to match another user's email — including an administrator's — and upon login gain full access to that account. The account linkage persisted even if the LDAP email was later reverted, resulting in a permanent account takeover.

- LDAP authentication must be configured and active (non-default).

## Patches
The issue has been fixed in n8n versions 2.4.0 and 1.121.0. 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:
- Disable LDAP authentication until the instance can be upgraded.
- Restrict LDAP directory permissions so that users cannot modify their own email attributes.
- Audit existing LDAP-linked accounts for unexpected account associations.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-m63j-689w-3j35
Package: n8n (NPM)
Severity: HIGH (CVSS 9.9)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 2.0.0-rc.0, < 2.13.3
Patched in: 2.13.3

Summary: n8n is Vulnerable to Credential Theft via Name-Based Resolution and Permission Checker Bypass in Community Edition

Details:
## Impact
An authenticated user with the `global:member` role could exploit chained authorization flaws in n8n's credential pipeline to steal plaintext secrets from generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) belonging to other users on the same instance.

The attack abuses a name-based credential resolution path that does not enforce ownership or project scope, combined with a bypass in the credentials permission checker that causes generic HTTP credential types to be skipped during pre-execution validation. Together, these flaws allow a member-role user to resolve another user's credential ID and execute a workflow that decrypts and uses that credential without authorization.

Native integration credential types (e.g. `slackApi`, `openAiApi`, `postgres`) are not affected by this issue.

This vulnerability affects Community Edition only. Enterprise Edition has additional permission gates on workflow creation and execution that independently block this attack chain.

## 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:
- Restrict instance access to fully trusted users only.
- Audit credentials stored on the instance and rotate any generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) that may have been exposed.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-m63j-689w-3j35
Package: n8n (NPM)
Severity: HIGH (CVSS 9.9)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: = 2.14.0
Patched in: 2.14.1

Summary: n8n is Vulnerable to Credential Theft via Name-Based Resolution and Permission Checker Bypass in Community Edition

Details:
## Impact
An authenticated user with the `global:member` role could exploit chained authorization flaws in n8n's credential pipeline to steal plaintext secrets from generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) belonging to other users on the same instance.

The attack abuses a name-based credential resolution path that does not enforce ownership or project scope, combined with a bypass in the credentials permission checker that causes generic HTTP credential types to be skipped during pre-execution validation. Together, these flaws allow a member-role user to resolve another user's credential ID and execute a workflow that decrypts and uses that credential without authorization.

Native integration credential types (e.g. `slackApi`, `openAiApi`, `postgres`) are not affected by this issue.

This vulnerability affects Community Edition only. Enterprise Edition has additional permission gates on workflow creation and execution that independently block this attack chain.

## 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:
- Restrict instance access to fully trusted users only.
- Audit credentials stored on the instance and rotate any generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) that may have been exposed.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-m63j-689w-3j35
Package: n8n (NPM)
Severity: HIGH (CVSS 9.9)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 1.123.27
Patched in: 1.123.27

Summary: n8n is Vulnerable to Credential Theft via Name-Based Resolution and Permission Checker Bypass in Community Edition

Details:
## Impact
An authenticated user with the `global:member` role could exploit chained authorization flaws in n8n's credential pipeline to steal plaintext secrets from generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) belonging to other users on the same instance.

The attack abuses a name-based credential resolution path that does not enforce ownership or project scope, combined with a bypass in the credentials permission checker that causes generic HTTP credential types to be skipped during pre-execution validation. Together, these flaws allow a member-role user to resolve another user's credential ID and execute a workflow that decrypts and uses that credential without authorization.

Native integration credential types (e.g. `slackApi`, `openAiApi`, `postgres`) are not affected by this issue.

This vulnerability affects Community Edition only. Enterprise Edition has additional permission gates on workflow creation and execution that independently block this attack chain.

## 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:
- Restrict instance access to fully trusted users only.
- Audit credentials stored on the instance and rotate any generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) that may have been exposed.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-58qr-rcgv-642v
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 1.123.27
Patched in: 1.123.27

Summary: n8n has Multiple Remote Code Execution Vulnerabilities in Merge Node AlaSQL SQL Mode

Details:
## Impact
An authenticated user with permission to create or modify workflows could use the Merge node's "Combine by SQL" mode to read local files on the n8n host and achieve remote code execution. The AlaSQL sandbox did not sufficiently restrict certain SQL statements, allowing an attacker to access sensitive files on the server or even compromise the intance.

## Patches
The issue has been fixed in n8n versions 2.14.1, 2.13.3, and 1.123.27. 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 Merge node by adding `n8n-nodes-base.merge` 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-58qr-rcgv-642v
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 2.0.0-rc.0, < 2.13.3
Patched in: 2.13.3

Summary: n8n has Multiple Remote Code Execution Vulnerabilities in Merge Node AlaSQL SQL Mode

Details:
## Impact
An authenticated user with permission to create or modify workflows could use the Merge node's "Combine by SQL" mode to read local files on the n8n host and achieve remote code execution. The AlaSQL sandbox did not sufficiently restrict certain SQL statements, allowing an attacker to access sensitive files on the server or even compromise the intance.

## Patches
The issue has been fixed in n8n versions 2.14.1, 2.13.3, and 1.123.27. 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 Merge node by adding `n8n-nodes-base.merge` 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-58qr-rcgv-642v
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: = 2.14.0
Patched in: 2.14.1

Summary: n8n has Multiple Remote Code Execution Vulnerabilities in Merge Node AlaSQL SQL Mode

Details:
## Impact
An authenticated user with permission to create or modify workflows could use the Merge node's "Combine by SQL" mode to read local files on the n8n host and achieve remote code execution. The AlaSQL sandbox did not sufficiently restrict certain SQL statements, allowing an attacker to access sensitive files on the server or even compromise the intance.

## Patches
The issue has been fixed in n8n versions 2.14.1, 2.13.3, and 1.123.27. 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 Merge node by adding `n8n-nodes-base.merge` 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-v3rj-xjv7-4jmq
Package: smol-toml (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: < 1.6.1
Patched in: 1.6.1

Summary: smol-toml: Denial of Service via TOML documents containing thousands of consecutive commented lines

Details:
### Summary
An attacker can send a maliciously crafted TOML to cause the parser to crash, because of a stack overflow caused by thousands of consecutive commented lines.

The library uses recursion internally while parsing to skip over commented lines, which can be exploited to crash an application that is processing arbitrary TOML documents.

### Proof of concept
```js
require("smol-toml").parse('# comment\n'.repeat(8000) + 'key = "value"')
```

### Impact
Applications which parse arbitrary TOML documents may suffer availability issues if they receive malicious input. If uncaught, the crash may cause the application itself to crash. The impact is deemed minor, as the function is already likely to throw errors on invalid input. Downstream users are supposed to properly handle errors in such situations.

Due to the design of most JavaScript runtimes, the uncontrolled recursion does not lead to excessive memory usage and the execution is quickly aborted.

As a reminder, it is **strongly** advised when working with untrusted user input to expect errors to occur and to appropriately catch them.

### Patches
Version 1.6.1 uses a different approach for parsing comments, which no longer involves recursion.

### Workarounds
Wrap all invocations of `parse` and `stringify` in a try/catch block when dealing with untrusted user input.
GitHub Security Advisory: GHSA-48c2-rrv3-qjmp
Package: yaml (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: >= 1.0.0, < 1.10.3
Patched in: 1.10.3

Summary: yaml is vulnerable to Stack Overflow via deeply nested YAML collections

Details:
Parsing a YAML document with `yaml` may throw a RangeError due to a stack overflow.

The node resolution/composition phase uses recursive function calls without a depth bound. An attacker who can supply YAML for parsing can trigger a `RangeError: Maximum call stack size exceeded` with a small payload (~2–10 KB). The `RangeError` is not a `YAMLParseError`, so applications that only catch YAML-specific errors will encounter an unexpected exception type. Depending on the host application's exception handling, this can fail requests or terminate the Node.js process.

Flow sequences allow deep nesting with minimal bytes (2 bytes per level: one `[` and one `]`). On the default Node.js stack, approximately 1,000–5,000 levels of nesting (2–10 KB input) exhaust the call stack. The exact threshold is environment-dependent (Node.js version, stack size, call stack depth at invocation).

Note: the library's `Parser` (CST phase) uses a stack-based iterative approach and is not affected. Only the compose/resolve phase uses actual call-stack recursion.

All three public parsing APIs are affected: `YAML.parse()`, `YAML.parseDocument()`, and `YAML.parseAllDocuments()`.

### PoC

```javascript
const YAML = require('yaml');

// ~10 KB payload: 5000 levels of nested flow sequences
const payload = '['.repeat(5000) + '1' + ']'.repeat(5000);

try {
  YAML.parse(payload);
} catch (e) {
  console.log(e.constructor.name); // RangeError (NOT YAMLParseError)
  console.log(e.message);          // Maximum call stack size exceeded
}
```

Test environment: Node.js v24.12.0, macOS darwin arm64

| Version | Nesting Depth | Input Size | Result |
|---|---|---|---|
| 1.0.0 | 5,000 | 10,001 B | RangeError |
| 1.10.2 | 5,000 | 10,001 B | RangeError |
| 2.0.0 | 5,000 | 10,001 B | RangeError |
| 2.8.2 | 5,000 | 10,001 B | RangeError |
| 2.8.3 | 5,000 | 10,001 B | YAMLParseError |

Depth threshold on yaml 2.8.2:

| Nesting Depth | Input Size | Result |
|---|---|---|
| 500 | 1,001 B | Parses successfully |
| 1,000 | 2,001 B | RangeError (threshold varies by stack size) |
| 5,000 | 10,001 B | RangeError |
GitHub Security Advisory: GHSA-48c2-rrv3-qjmp
Package: yaml (NPM)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: >= 2.0.0, < 2.8.3
Patched in: 2.8.3

Summary: yaml is vulnerable to Stack Overflow via deeply nested YAML collections

Details:
Parsing a YAML document with `yaml` may throw a RangeError due to a stack overflow.

The node resolution/composition phase uses recursive function calls without a depth bound. An attacker who can supply YAML for parsing can trigger a `RangeError: Maximum call stack size exceeded` with a small payload (~2–10 KB). The `RangeError` is not a `YAMLParseError`, so applications that only catch YAML-specific errors will encounter an unexpected exception type. Depending on the host application's exception handling, this can fail requests or terminate the Node.js process.

Flow sequences allow deep nesting with minimal bytes (2 bytes per level: one `[` and one `]`). On the default Node.js stack, approximately 1,000–5,000 levels of nesting (2–10 KB input) exhaust the call stack. The exact threshold is environment-dependent (Node.js version, stack size, call stack depth at invocation).

Note: the library's `Parser` (CST phase) uses a stack-based iterative approach and is not affected. Only the compose/resolve phase uses actual call-stack recursion.

All three public parsing APIs are affected: `YAML.parse()`, `YAML.parseDocument()`, and `YAML.parseAllDocuments()`.

### PoC

```javascript
const YAML = require('yaml');

// ~10 KB payload: 5000 levels of nested flow sequences
const payload = '['.repeat(5000) + '1' + ']'.repeat(5000);

try {
  YAML.parse(payload);
} catch (e) {
  console.log(e.constructor.name); // RangeError (NOT YAMLParseError)
  console.log(e.message);          // Maximum call stack size exceeded
}
```

Test environment: Node.js v24.12.0, macOS darwin arm64

| Version | Nesting Depth | Input Size | Result |
|---|---|---|---|
| 1.0.0 | 5,000 | 10,001 B | RangeError |
| 1.10.2 | 5,000 | 10,001 B | RangeError |
| 2.0.0 | 5,000 | 10,001 B | RangeError |
| 2.8.2 | 5,000 | 10,001 B | RangeError |
| 2.8.3 | 5,000 | 10,001 B | YAMLParseError |

Depth threshold on yaml 2.8.2:

| Nesting Depth | Input Size | Result |
|---|---|---|
| 500 | 1,001 B | Parses successfully |
| 1,000 | 2,001 B | RangeError (threshold varies by stack size) |
| 5,000 | 10,001 B | RangeError |
GitHub Security Advisory: GHSA-444r-cwp2-x5xf
Package: fastify (NPM)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-348: Use of Less Trusted Source
Vulnerable versions: <= 5.8.2
Patched in: 5.8.3

Summary: fastify: request.protocol and request.host Spoofable via X-Forwarded-Proto/Host from Untrusted Connections

Details:
## Summary

When `trustProxy` is configured with a restrictive trust function (e.g., a specific IP like `trustProxy: '10.0.0.1'`, a subnet, a hop count, or a custom function), the `request.protocol` and `request.host` getters read `X-Forwarded-Proto` and `X-Forwarded-Host` headers from any connection — including connections from untrusted IPs. This allows an attacker connecting directly to Fastify (bypassing the proxy) to spoof both the protocol and host seen by the application.

## Affected Versions

fastify <= 5.8.2

## Impact

Applications using `request.protocol` or `request.host` for security decisions (HTTPS enforcement, secure cookie flags, CSRF origin checks, URL construction, host-based routing) are affected when `trustProxy` is configured with a restrictive trust function.

When `trustProxy: true` (trust everything), both `host` and `protocol` trust all forwarded headers — this is expected behavior. The vulnerability only manifests with restrictive trust configurations.