deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-gjxx-92w9-8v8f
Package: @clerk/hono (NPM)
Severity: HIGH (CVSS 7.4)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 0.1.0, <= 0.1.4
Patched in: 0.1.5

Summary: Clerk: SSRF in the opt-in clerkFrontendApiProxy feature may leak secret keys to unintended host

Details:
## Summary

The `clerkFrontendApiProxy` function in `@clerk/backend` is vulnerable to Server-Side Request Forgery (SSRF). An unauthenticated attacker can craft a request path that causes the proxy to send the application's `Clerk-Secret-Key` to an attacker-controlled server.

## Affected packages

Only applications that have opted into the `frontendApiProxy` feature are affected. This feature is not enabled by default. **Users of `@clerk/nextjs` are not affected** due to how the framework handles repeated `/` in request paths.

| Package | Affected versions | Fixed version |
|---|---|---|
| `@clerk/backend` | `>= 3.0.0, <= 3.2.2` | `3.2.3` |
| `@clerk/express` | `>= 2.0.0, <= 2.0.6` | `2.0.7` |
| `@clerk/hono` | `>= 0.1.0, <= 0.1.4` | `0.1.5` |
| `@clerk/fastify` | `>= 3.1.0, <= 3.1.4` | `3.1.5` |

Search your codebase for the `frontendApiProxy` option. If none of the patterns below appear in your code, you are not affected.

**@clerk/express**
```ts
app.use(clerkMiddleware({ frontendApiProxy: { enabled: true } }));
```

**@clerk/hono**
```ts
app.use('*', clerkMiddleware({ frontendApiProxy: { enabled: true } }));
```

**@clerk/fastify**
```ts
fastify.register(clerkPlugin, { frontendApiProxy: { enabled: true } });
```

**@clerk/backend**
```ts
import { clerkFrontendApiProxy } from '@clerk/backend/proxy';
```

A quick way to check across your entire project:

```sh
grep -r "frontendApiProxy\|clerkFrontendApiProxy" .
```

If there are no matches, you are not using this feature.


## Recommended actions

Clerk's internal logs show no evidence of users utilizing the built-in proxy with the impacted versions. Despite that, if you are on an impacted version and use the built-in proxy we recommend upgrading and rotating your Clerk Secret Key immediately.

1. **Upgrade** to the patched version of `@clerk/backend` (and `@clerk/express`, `@clerk/hono`, etc.)
2. **Rotate your Clerk Secret Key** after upgrading - if an attacker exploited this vulnerability, they may have captured your key. Rotate it in the [Clerk Dashboard](https://dashboard.clerk.com) under **API Keys**.  You should deploy your application with the updated key before revoking the existing key.
3. **Audit access logs** for requests to your proxy endpoint (`/__clerk/` by default) containing double slashes in the path.



## Credit

Discovered during an internal code audit.
GitHub Security Advisory: GHSA-gjxx-92w9-8v8f
Package: @clerk/express (NPM)
Severity: HIGH (CVSS 7.4)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 2.0.0, <= 2.0.6
Patched in: 2.0.7

Summary: Clerk: SSRF in the opt-in clerkFrontendApiProxy feature may leak secret keys to unintended host

Details:
## Summary

The `clerkFrontendApiProxy` function in `@clerk/backend` is vulnerable to Server-Side Request Forgery (SSRF). An unauthenticated attacker can craft a request path that causes the proxy to send the application's `Clerk-Secret-Key` to an attacker-controlled server.

## Affected packages

Only applications that have opted into the `frontendApiProxy` feature are affected. This feature is not enabled by default. **Users of `@clerk/nextjs` are not affected** due to how the framework handles repeated `/` in request paths.

| Package | Affected versions | Fixed version |
|---|---|---|
| `@clerk/backend` | `>= 3.0.0, <= 3.2.2` | `3.2.3` |
| `@clerk/express` | `>= 2.0.0, <= 2.0.6` | `2.0.7` |
| `@clerk/hono` | `>= 0.1.0, <= 0.1.4` | `0.1.5` |
| `@clerk/fastify` | `>= 3.1.0, <= 3.1.4` | `3.1.5` |

Search your codebase for the `frontendApiProxy` option. If none of the patterns below appear in your code, you are not affected.

**@clerk/express**
```ts
app.use(clerkMiddleware({ frontendApiProxy: { enabled: true } }));
```

**@clerk/hono**
```ts
app.use('*', clerkMiddleware({ frontendApiProxy: { enabled: true } }));
```

**@clerk/fastify**
```ts
fastify.register(clerkPlugin, { frontendApiProxy: { enabled: true } });
```

**@clerk/backend**
```ts
import { clerkFrontendApiProxy } from '@clerk/backend/proxy';
```

A quick way to check across your entire project:

```sh
grep -r "frontendApiProxy\|clerkFrontendApiProxy" .
```

If there are no matches, you are not using this feature.


## Recommended actions

Clerk's internal logs show no evidence of users utilizing the built-in proxy with the impacted versions. Despite that, if you are on an impacted version and use the built-in proxy we recommend upgrading and rotating your Clerk Secret Key immediately.

1. **Upgrade** to the patched version of `@clerk/backend` (and `@clerk/express`, `@clerk/hono`, etc.)
2. **Rotate your Clerk Secret Key** after upgrading - if an attacker exploited this vulnerability, they may have captured your key. Rotate it in the [Clerk Dashboard](https://dashboard.clerk.com) under **API Keys**.  You should deploy your application with the updated key before revoking the existing key.
3. **Audit access logs** for requests to your proxy endpoint (`/__clerk/` by default) containing double slashes in the path.



## Credit

Discovered during an internal code audit.
GitHub Security Advisory: GHSA-gjxx-92w9-8v8f
Package: @clerk/backend (NPM)
Severity: HIGH (CVSS 7.4)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 3.0.0, <= 3.2.2
Patched in: 3.2.3

Summary: Clerk: SSRF in the opt-in clerkFrontendApiProxy feature may leak secret keys to unintended host

Details:
## Summary

The `clerkFrontendApiProxy` function in `@clerk/backend` is vulnerable to Server-Side Request Forgery (SSRF). An unauthenticated attacker can craft a request path that causes the proxy to send the application's `Clerk-Secret-Key` to an attacker-controlled server.

## Affected packages

Only applications that have opted into the `frontendApiProxy` feature are affected. This feature is not enabled by default. **Users of `@clerk/nextjs` are not affected** due to how the framework handles repeated `/` in request paths.

| Package | Affected versions | Fixed version |
|---|---|---|
| `@clerk/backend` | `>= 3.0.0, <= 3.2.2` | `3.2.3` |
| `@clerk/express` | `>= 2.0.0, <= 2.0.6` | `2.0.7` |
| `@clerk/hono` | `>= 0.1.0, <= 0.1.4` | `0.1.5` |
| `@clerk/fastify` | `>= 3.1.0, <= 3.1.4` | `3.1.5` |

Search your codebase for the `frontendApiProxy` option. If none of the patterns below appear in your code, you are not affected.

**@clerk/express**
```ts
app.use(clerkMiddleware({ frontendApiProxy: { enabled: true } }));
```

**@clerk/hono**
```ts
app.use('*', clerkMiddleware({ frontendApiProxy: { enabled: true } }));
```

**@clerk/fastify**
```ts
fastify.register(clerkPlugin, { frontendApiProxy: { enabled: true } });
```

**@clerk/backend**
```ts
import { clerkFrontendApiProxy } from '@clerk/backend/proxy';
```

A quick way to check across your entire project:

```sh
grep -r "frontendApiProxy\|clerkFrontendApiProxy" .
```

If there are no matches, you are not using this feature.


## Recommended actions

Clerk's internal logs show no evidence of users utilizing the built-in proxy with the impacted versions. Despite that, if you are on an impacted version and use the built-in proxy we recommend upgrading and rotating your Clerk Secret Key immediately.

1. **Upgrade** to the patched version of `@clerk/backend` (and `@clerk/express`, `@clerk/hono`, etc.)
2. **Rotate your Clerk Secret Key** after upgrading - if an attacker exploited this vulnerability, they may have captured your key. Rotate it in the [Clerk Dashboard](https://dashboard.clerk.com) under **API Keys**.  You should deploy your application with the updated key before revoking the existing key.
3. **Audit access logs** for requests to your proxy endpoint (`/__clerk/` by default) containing double slashes in the path.



## Credit

Discovered during an internal code audit.
GitHub Security Advisory: GHSA-8j44-735h-w4w2
Package: node-tesseract-ocr (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 2.2.1
Patched in: unpatched

Summary: node-tesseract-ocr is vulnerable to OS Command Injection through unsanitized recognize() function parameter

Details:
node-tesseract-ocr is an npm package that provides a Node.js wrapper for Tesseract OCR. In all versions through 2.2.1, the recognize() function in src/index.js is vulnerable to OS Command Injection. The file path parameter is concatenated into a shell command string and passed to child_process.exec() without proper sanitization
GitHub Security Advisory: GHSA-q5mh-72xg-628w
Package: pdf-image (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 2.0.0
Patched in: unpatched

Summary: pdf-image has an OS Command Injection Vulnerability through its pdfFilePath parameter

Details:
pdf-image (npm package) through version 2.0.0 allows OS command injection via the pdfFilePath parameter. The constructGetInfoCommand and constructConvertCommandForPage functions use util.format() to interpolate user-controlled file paths into shell command strings that are executed via child_process.exec().
GitHub Security Advisory: GHSA-9cx6-37pm-9jff
Package: handlebars (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: >= 4.0.0, <= 4.7.8
Patched in: 4.7.9

Summary: Handlebars.js has Denial of Service via Malformed Decorator Syntax in Template Compilation

Details:
## Summary

When a Handlebars template contains decorator syntax referencing an unregistered decorator (e.g. `{{*n}}`), the compiled template calls `lookupProperty(decorators, "n")`, which returns `undefined`. The runtime then immediately invokes the result as a function, causing an unhandled `TypeError: ... is not a function` that crashes the Node.js process. Any application that compiles user-supplied templates without wrapping the call in a `try/catch` is vulnerable to a single-request Denial of Service.

## Description

In `lib/handlebars/compiler/javascript-compiler.js`, the code generated for a decorator invocation looks like:

```javascript
fn = lookupProperty(decorators, "n")(fn, props, container, options) || fn;
```

When `"n"` is not a registered decorator, `lookupProperty(decorators, "n")` returns `undefined`. The expression immediately attempts to call `undefined` as a function, producing:

```
TypeError: lookupProperty(...) is not a function
```

Because the error is thrown inside the compiled template function and is not caught by the runtime, it propagates up as an unhandled exception and — when not caught by the application — crashes the Node.js process.

This inconsistency is notable: references to unregistered **helpers** produce a clean `"Missing helper: ..."` error, while references to unregistered **decorators** cause a hard crash.

**Attack scenario:** An attacker submits `{{*n}}` as template content to any endpoint that calls `Handlebars.compile(userInput)()`. Each request crashes the server process; with process managers that auto-restart (PM2, systemd), repeated submissions create a persistent DoS.

## Proof of Concept

```javascript
const Handlebars = require('handlebars'); // Handlebars 4.7.8, Node.js v22.x

// Any of these payloads crash the process
Handlebars.compile('{{*n}}')({});
Handlebars.compile('{{*decorator}}')({});
Handlebars.compile('{{*constructor}}')({});
```

Expected crash output:
```
TypeError: lookupProperty(...) is not a function
    at Function.eval [as decorator] (eval at compile (...javascript-compiler.js:134:36))
```

## Workarounds

- **Wrap compilation and rendering in `try/catch`:**
  ```javascript
  try {
    const result = Handlebars.compile(userInput)(context);
    res.send(result);
  } catch (err) {
    res.status(400).send('Invalid template');
  }
  ```
- **Validate template input** before passing it to `compile()`. Reject templates containing  decorator syntax (`{{*...}}`) if decorators are not used in your application.
- **Use the pre-compilation workflow:** compile templates at build time and serve only pre-compiled  templates; do not call `compile()` at request time.
GitHub Security Advisory: GHSA-qj8w-gfj5-8c6v
Package: serialize-javascript (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-834: Excessive Iteration
Vulnerable versions: < 7.0.5
Patched in: 7.0.5

Summary: Serialize JavaScript has CPU Exhaustion Denial of Service via crafted array-like objects

Details:
### Impact

**What kind of vulnerability is it?**

It is a **Denial of Service (DoS)** vulnerability caused by CPU exhaustion. When serializing a specially crafted "array-like" object (an object that inherits from `Array.prototype` but has a very large `length` property), the process enters an intensive loop that consumes 100% CPU and hangs indefinitely.

**Who is impacted?**

Applications that use `serialize-javascript` to serialize untrusted or user-controlled objects are at risk. While direct exploitation is difficult, it becomes a high-priority threat if the application is also vulnerable to **Prototype Pollution** or handles untrusted data via **YAML Deserialization**, as these could be used to inject the malicious object.

### Patches

**Has the problem been patched?**

Yes, the issue has been patched by replacing `instanceof Array` checks with `Array.isArray()` and using `Object.keys()` for sparse array detection.

**What versions should users upgrade to?**

Users should upgrade to **`v7.0.5`** or later.

### Workarounds

**Is there a way for users to fix or remediate the vulnerability without upgrading?**

There is no direct code-level workaround within the library itself. However, users can mitigate the risk by:

* Validating and sanitizing all input before passing it to the `serialize()` function.
* Ensuring the environment is protected against Prototype Pollution.
* Upgrading to **`v7.0.5`** as soon as possible.

### Acknowledgements

Serialize JavaScript thanks **Tomer Aberbach** (@TomerAberbach) for discovering and privately disclosing this issue.
GitHub Security Advisory: GHSA-364x-8g5j-x2pr
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.6.4
Patched in: 2.6.4

Summary: n8n has XSS in its Credential Management Flow

Details:
## Impact
An authenticated user with permission to create and share credentials could craft a malicious OAuth2 credential containing a JavaScript URL in the Authorization URL field. If a victim opened the credential and interacted with the OAuth authorization button, the injected script would execute in their browser session.

## Patches
The issue has been fixed in n8n versions 2.8.0 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:
- Limit credential creation and sharing permissions to fully trusted users only.
- Restrict access to the n8n instance to 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-364x-8g5j-x2pr
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.7.0, < 2.8.0
Patched in: 2.8.0

Summary: n8n has XSS in its Credential Management Flow

Details:
## Impact
An authenticated user with permission to create and share credentials could craft a malicious OAuth2 credential containing a JavaScript URL in the Authorization URL field. If a victim opened the credential and interacted with the OAuth authorization button, the injected script would execute in their browser session.

## Patches
The issue has been fixed in n8n versions 2.8.0 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:
- Limit credential creation and sharing permissions to fully trusted users only.
- Restrict access to the n8n instance to 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-3c7f-5hgj-h279
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.13.3
Patched in: 2.13.3

Summary: n8n has XSS in Chat Trigger Node through Custom CSS

Details:
## Impact
An authenticated user with permission to create or modify workflows could inject malicious JavaScript into the Custom CSS field of the Chat Trigger node. Due to a misconfiguration in the `sanitize-html` library, the sanitization could be bypassed, resulting in stored XSS on the public chat page. Any user visiting the chat URL would be affected.

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

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Chat Trigger node by adding `@n8n/n8n-nodes-langchain.chatTrigger` 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-3c7f-5hgj-h279
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.27
Patched in: 1.123.27

Summary: n8n has XSS in Chat Trigger Node through Custom CSS

Details:
## Impact
An authenticated user with permission to create or modify workflows could inject malicious JavaScript into the Custom CSS field of the Chat Trigger node. Due to a misconfiguration in the `sanitize-html` library, the sanitization could be bypassed, resulting in stored XSS on the public chat page. Any user visiting the chat URL would be affected.

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

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Chat Trigger node by adding `@n8n/n8n-nodes-langchain.chatTrigger` 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-w673-8fjw-457c
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.1)
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: < 1.123.24
Patched in: 1.123.24

Summary: n8n: Authenticated XSS and Open Redirect via Form Node

Details:
## Impact
An authenticated user with permission to create or modify workflows could configure a Form Node with an unsanitized HTML description field or exploit an overly permissive iframe sandbox policy to perform stored cross-site scripting or redirect end users visiting the form to an arbitrary external URL. The vulnerability could be used to facilitate phishing attacks.

## Patches
The issue has been fixed in n8n versions 1.123.24, 2.10.4 and 2.12.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:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable.
- 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-w673-8fjw-457c
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.1)
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: >= 2.0.0-rc.0, < 2.10.4
Patched in: 2.10.4

Summary: n8n: Authenticated XSS and Open Redirect via Form Node

Details:
## Impact
An authenticated user with permission to create or modify workflows could configure a Form Node with an unsanitized HTML description field or exploit an overly permissive iframe sandbox policy to perform stored cross-site scripting or redirect end users visiting the form to an arbitrary external URL. The vulnerability could be used to facilitate phishing attacks.

## Patches
The issue has been fixed in n8n versions 1.123.24, 2.10.4 and 2.12.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:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable.
- 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-w673-8fjw-457c
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.1)
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: >= 2.11.0, < 2.12.0
Patched in: 2.12.0

Summary: n8n: Authenticated XSS and Open Redirect via Form Node

Details:
## Impact
An authenticated user with permission to create or modify workflows could configure a Form Node with an unsanitized HTML description field or exploit an overly permissive iframe sandbox policy to perform stored cross-site scripting or redirect end users visiting the form to an arbitrary external URL. The vulnerability could be used to facilitate phishing attacks.

## Patches
The issue has been fixed in n8n versions 1.123.24, 2.10.4 and 2.12.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:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable.
- 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.