deardaniel/secdata-raw huggingface dataset:
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: < 1.123.26
Patched in: 1.123.26

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-mxrg-77hm-89hv
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 1.123.27
Patched in: 1.123.27

Summary: n8n: Prototype Pollution in XML and GSuiteAdmin node parameters lead to RCE

Details:
## Impact
An authenticated user with permission to create or modify workflows could exploit a prototype pollution vulnerability in the GSuiteAdmin node. By supplying a crafted parameter as part of node configuration, an attacker could write attacker-controlled values onto `Object.prototype`. An attacker could use this prototype pollution to achieve remote code execution on the n8n instance.

## 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 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-mxrg-77hm-89hv
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 2.0.0-rc.0, < 2.13.3
Patched in: 2.13.3

Summary: n8n: Prototype Pollution in XML and GSuiteAdmin node parameters lead to RCE

Details:
## Impact
An authenticated user with permission to create or modify workflows could exploit a prototype pollution vulnerability in the GSuiteAdmin node. By supplying a crafted parameter as part of node configuration, an attacker could write attacker-controlled values onto `Object.prototype`. An attacker could use this prototype pollution to achieve remote code execution on the n8n instance.

## 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 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-mxrg-77hm-89hv
Package: n8n (NPM)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: = 2.14.0
Patched in: 2.14.1

Summary: n8n: Prototype Pollution in XML and GSuiteAdmin node parameters lead to RCE

Details:
## Impact
An authenticated user with permission to create or modify workflows could exploit a prototype pollution vulnerability in the GSuiteAdmin node. By supplying a crafted parameter as part of node configuration, an attacker could write attacker-controlled values onto `Object.prototype`. An attacker could use this prototype pollution to achieve remote code execution on the n8n instance.

## 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 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-43v7-fp2v-68f6
Package: n8n (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 2.5.0
Patched in: 2.5.0

Summary: n8n's Source Control SSH Configuration Uses StrictHostKeyChecking=no

Details:
## Impact
When the Source Control feature is configured to use SSH, the SSH command used for git operations explicitly disabled host key verification. A network attacker positioned between the n8n instance and the remote Git server could intercept the connection and present a fraudulent host key, potentially injecting malicious content into workflows or intercepting repository data.

- This issue only affects instances where the Source Control feature has been explicitly enabled and configured to use SSH (non-default).

## Patches
The issue has been fixed in n8n version 2.5.0. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Disable the Source Control feature if it is not actively required.
- Restrict network access to ensure the n8n instance communicates with the Git server only over trusted, controlled network paths.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-fxcw-h3qj-8m8p
Package: n8n (NPM)
Severity: HIGH (CVSS 6.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.0.0-rc.0, < 2.6.4
Patched in: 2.6.4

Summary: n8n Has External Secrets Authorization Bypass in Credential Saving

Details:
## Impact
An authenticated user without permission to list external secrets could reference a secret by the external name in a credential and retrieve its plaintext value when saving the credential. This bypassed the `externalSecret:list` permission check and allowed access to secrets stored in connected vaults without admin or owner privileges.

- This issue requires the instance to have an external secrets vault configured.
- The attacker must know or be able to guess the name of a target secret.

## Patches
The issue has been fixed in n8n versions 1.123.23 and 2.6.4. 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 n8n access to fully trusted users only.
- Disable external secrets integration until the patch can be applied.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-fxcw-h3qj-8m8p
Package: n8n (NPM)
Severity: HIGH (CVSS 6.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 1.123.23
Patched in: 1.123.23

Summary: n8n Has External Secrets Authorization Bypass in Credential Saving

Details:
## Impact
An authenticated user without permission to list external secrets could reference a secret by the external name in a credential and retrieve its plaintext value when saving the credential. This bypassed the `externalSecret:list` permission check and allowed access to secrets stored in connected vaults without admin or owner privileges.

- This issue requires the instance to have an external secrets vault configured.
- The attacker must know or be able to guess the name of a target secret.

## Patches
The issue has been fixed in n8n versions 1.123.23 and 2.6.4. 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 n8n access to fully trusted users only.
- Disable external secrets integration until the patch can be applied.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-vpgc-2f6g-7w7x
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 2.8.0
Patched in: 2.8.0

Summary: n8n Has Authorization Bypass in OAuth Callback via N8N_SKIP_AUTH_ON_OAUTH_CALLBACK

Details:
## Impact
When the `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK` environment variable is set to `true`, the OAuth callback handler skips ownership verification of the OAuth state parameter. This allows an attacker to trick a victim into completing an OAuth flow against a credential object the attacker controls, causing the victim's OAuth tokens to be stored in the attacker's credential. The attacker can then use those tokens to execute workflows in their name.

- This issue only affects instances where `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=true` is explicitly configured (non-default).

## Patches
The issue has been fixed in n8n version 2.8.0. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Avoid enabling `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=true` unless strictly required.
- Restrict access to the n8n instance to fully trusted users only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-3v7f-55p6-f55p
Package: picomatch (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 2.3.2
Patched in: 2.3.2

Summary: Picomatch: Method Injection in POSIX Character Classes causes incorrect Glob Matching

Details:
### Impact
picomatch is vulnerable to a **method injection vulnerability (CWE-1321)** affecting the `POSIX_REGEX_SOURCE` object. Because the object inherits from `Object.prototype`, specially crafted POSIX bracket expressions (e.g., `[[:constructor:]]`) can reference inherited method names. These methods are implicitly converted to strings and injected into the generated regular expression.

This leads to **incorrect glob matching behavior (integrity impact)**, where patterns may match unintended filenames. The issue does **not enable remote code execution**, but it can cause security-relevant logic errors in applications that rely on glob matching for filtering, validation, or access control.

All users of affected `picomatch` versions that process untrusted or user-controlled glob patterns are potentially impacted.

### 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:
- Sanitizing or rejecting untrusted glob patterns, especially those containing POSIX character classes like `[[:...:]]`.
- Avoiding the use of POSIX bracket expressions if user input is involved.
- Manually patching the library by modifying `POSIX_REGEX_SOURCE` to use a null prototype:

  ```js
  const POSIX_REGEX_SOURCE = {
    __proto__: null,
    alnum: 'a-zA-Z0-9',
    alpha: 'a-zA-Z',
    // ... rest unchanged
  };
  
### Resources

- fix for similar issue: https://github.com/micromatch/picomatch/pull/144
- picomatch repository https://github.com/micromatch/picomatch
GitHub Security Advisory: GHSA-3v7f-55p6-f55p
Package: picomatch (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 3.0.0, < 3.0.2
Patched in: 3.0.2

Summary: Picomatch: Method Injection in POSIX Character Classes causes incorrect Glob Matching

Details:
### Impact
picomatch is vulnerable to a **method injection vulnerability (CWE-1321)** affecting the `POSIX_REGEX_SOURCE` object. Because the object inherits from `Object.prototype`, specially crafted POSIX bracket expressions (e.g., `[[:constructor:]]`) can reference inherited method names. These methods are implicitly converted to strings and injected into the generated regular expression.

This leads to **incorrect glob matching behavior (integrity impact)**, where patterns may match unintended filenames. The issue does **not enable remote code execution**, but it can cause security-relevant logic errors in applications that rely on glob matching for filtering, validation, or access control.

All users of affected `picomatch` versions that process untrusted or user-controlled glob patterns are potentially impacted.

### 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:
- Sanitizing or rejecting untrusted glob patterns, especially those containing POSIX character classes like `[[:...:]]`.
- Avoiding the use of POSIX bracket expressions if user input is involved.
- Manually patching the library by modifying `POSIX_REGEX_SOURCE` to use a null prototype:

  ```js
  const POSIX_REGEX_SOURCE = {
    __proto__: null,
    alnum: 'a-zA-Z0-9',
    alpha: 'a-zA-Z',
    // ... rest unchanged
  };
  
### Resources

- fix for similar issue: https://github.com/micromatch/picomatch/pull/144
- picomatch repository https://github.com/micromatch/picomatch
GitHub Security Advisory: GHSA-3v7f-55p6-f55p
Package: picomatch (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 4.0.0, < 4.0.4
Patched in: 4.0.4

Summary: Picomatch: Method Injection in POSIX Character Classes causes incorrect Glob Matching

Details:
### Impact
picomatch is vulnerable to a **method injection vulnerability (CWE-1321)** affecting the `POSIX_REGEX_SOURCE` object. Because the object inherits from `Object.prototype`, specially crafted POSIX bracket expressions (e.g., `[[:constructor:]]`) can reference inherited method names. These methods are implicitly converted to strings and injected into the generated regular expression.

This leads to **incorrect glob matching behavior (integrity impact)**, where patterns may match unintended filenames. The issue does **not enable remote code execution**, but it can cause security-relevant logic errors in applications that rely on glob matching for filtering, validation, or access control.

All users of affected `picomatch` versions that process untrusted or user-controlled glob patterns are potentially impacted.

### 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:
- Sanitizing or rejecting untrusted glob patterns, especially those containing POSIX character classes like `[[:...:]]`.
- Avoiding the use of POSIX bracket expressions if user input is involved.
- Manually patching the library by modifying `POSIX_REGEX_SOURCE` to use a null prototype:

  ```js
  const POSIX_REGEX_SOURCE = {
    __proto__: null,
    alnum: 'a-zA-Z0-9',
    alpha: 'a-zA-Z',
    // ... rest unchanged
  };
  
### Resources

- fix for similar issue: https://github.com/micromatch/picomatch/pull/144
- picomatch repository https://github.com/micromatch/picomatch
GitHub Security Advisory: GHSA-c2c7-rcm5-vvqj
Package: picomatch (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 2.3.2
Patched in: 2.3.2

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-c2c7-rcm5-vvqj
Package: picomatch (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 3.0.0, < 3.0.2
Patched in: 3.0.2

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