deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-9fv2-c7v6-p45w
Package: @fonoster/voice (NPM)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-24: Path Traversal: '../filedir'
Vulnerable versions: >= 0.5.5, < 0.6.1
Patched in: 0.6.1

Summary: Fonoster is vulnerable to directory traversal

Details:
Fonoster 0.5.5 before 0.6.1 allows ../ directory traversal to read arbitrary files via the /sounds/:file or /tts/:file VoiceServer endpoint. This occurs in serveFiles in mods/voice/src/utils.ts. NOTE: serveFiles exists in 0.5.5 but not in the next release, 0.6.1.
GitHub Security Advisory: GHSA-cwc3-p92j-g7qm
Package: flowise (NPM)
Severity: HIGH (CVSS 8.8)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: <= 3.0.12
Patched in: 3.0.13

Summary: Flowise has IDOR leading to Account Takeover and Enterprise Feature Bypass via SSO Configuration

Details:
### Summary
The Flowise platform has a critical Insecure Direct Object Reference (IDOR) vulnerability combined with a Business Logic Flaw in the PUT /api/v1/loginmethod endpoint.

While the endpoint requires authentication, it fails to validate if the authenticated user has ownership or administrative rights over the target organizationId. This allows any low-privileged user (including "Free" plan users) to:

1. Overwrite the SSO configuration of any other organization.
2. Enable "Enterprise-only" features (SSO/SAML) without a license.
3. Perform Account Takeover  by redirecting the authentication flow.

### Details
The backend accepts the organizationId parameter from the JSON body and updates the database record corresponding to that ID. There is no middleware or logic check to ensure request.user.organizationId === body.organizationId.

### PoC
Prerequisites:
1. The attacker creates a standard "Free" account and obtains a valid JWT token (Cookie/Header).
2. The attacker identifies the target organizationId (e.g., bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d).

**Step-by-Step Exploitation**: The attacker sends the following PUT request to overwrite the victim's Google SSO configuration.

**Request**:

```http
PUT /api/v1/loginmethod HTTP/2
Host: cloud.flowiseai.com
Cookie: token=<ATTACKER_JWT_TOKEN>
Content-Type: application/json
Accept: application/json

{
  "organizationId": "bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d",
  "userId": "6ab311fa-0d0a-4bd6-996e-4ae721377fb2", 
  "providers": [
    {
      "providerLabel": "Google",
      "providerName": "google",
      "config": {
        "clientID": "ATTACKER_MALICIOUS_CLIENT_ID",
        "clientSecret": "ATTACKER_MALICIOUS_SECRET"
      },
      "status": "enable"
    }
  ]
}
```

**Response**: The server responds with 200 OK, confirming the modification has been applied to the victim's organization context.

```json
{
  "status": "OK",
  "organizationId": "bd2b74e0-e0cd-4bb5-ba98-3cc2ae683d5d"
}
```

### Impact

- **Account Takeover**: An attacker can replace a victim organization's legitimate OAuth credentials (e.g., Google Client ID) with their own malicious application credentials. When victim employees try to log in via SSO, they are authenticated against the attacker's application, potentially allowing the attacker to hijack sessions or steal credentials.
- **License Control Bypass**: Users on the "Free" tier can illicitly enable and configure SSO providers (Azure, Okta, etc.), which are features strictly restricted to the "Enterprise" plan.
GitHub Security Advisory: GHSA-fj3w-jwp8-x2g3
Package: fast-xml-parser (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: >= 4.0.0-beta.0, < 4.5.4
Patched in: 4.5.4

Summary: fast-xml-parser has stack overflow in XMLBuilder with preserveOrder

Details:
### Impact
Application crashes with stack overflow when user use XML builder with `prserveOrder:true` for following or similar input 

```
[{
    'foo': [
        { 'bar': [{ '@_V': 'baz' }] }
    ]
}]
```

Cause: `arrToStr` was not validating if the input is an array or a string and treating all non-array values as text content.
_What kind of vulnerability is it? Who is impacted?_

### Patches
Yes in 5.3.8

### Workarounds
Use XML builder with `preserveOrder:false` or check the input data before passing to builder.

### References
[_Are there any links users can visit to find out more?_](https://github.com/NaturalIntelligence/fast-xml-parser/pull/791)
GitHub Security Advisory: GHSA-wvhq-wp8g-c7vq
Package: flowise (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 3.0.12
Patched in: 3.0.13

Summary: Flowise has Authorization Bypass via Spoofed x-request-from Header

Details:
### Summary

Flowise trusts any HTTP client that sets the header `x-request-from: internal`, allowing an authenticated tenant session to bypass all `/api/v1/**` authorization checks. With only a browser cookie, a low-privilege tenant can invoke internal administration endpoints (API key management, credential stores, custom function execution, etc.), effectively escalating privileges.

### Details

The global middleware that guards `/api/v1` routes lives in `external/Flowise/packages/server/src/index.ts:214`. After filtering out the whitelist, the logic short-circuits on the spoofable header:

```javascript
if (isWhitelisted) {
    next();
} else if (req.headers['x-request-from'] === 'internal') {
    verifyToken(req, res, next);
} else {
    const { isValid } = await validateAPIKey(req);
    if (!isValid) return res.status(401).json({ error: 'Unauthorized Access' });
    … // owner context stitched from API key
}
```

Because the middle branch blindly calls verifyToken, any tenant that already has a UI session cookie is treated as an internal client simply by adding that header. No additional permission checks are performed before `next()` executes, so every downstream router under `/api/v1` becomes reachable.

### PoC

1. Log into Flowise 3.0.8 and capture cookies (e.g., `curl -c /tmp/flowise_cookies.txt … /api/v1/auth/login`).
2. Invoke an internal-only endpoint with the spoofed header:

```bash
    curl -sS -b /tmp/flowise_cookies.txt \
      -H 'Content-Type: application/json' \
      -H 'x-request-from: internal' \
      -X POST http://127.0.0.1:3100/api/v1/apikey \
      -d '{"keyName":"Bypass Demo"}'
```
    The server returns HTTP 200 and the newly created key object.
3. Remove the header and retry:

```bash
    curl -sS -b /tmp/flowise_cookies.txt \
      -H 'Content-Type: application/json' \
      -X POST http://127.0.0.1:3100/api/v1/apikey \
      -d '{"keyName":"Bypass Demo"}'
```
    This yields {"error":"Unauthorized Access"}, confirming the header alone controls access.

The same spoof grants access to other privileged routes like `/api/v1/credentials`, `/api/v1/tools`, `/api/v1/node-custom-function`, etc.

### Impact

This is an authorization bypass / privilege escalation. Any authenticated tenant (even without API keys or elevated roles) can execute internal administration APIs solely from the browser, enabling actions such as minting new API keys, harvesting stored secrets, and, when combined with other flaws (e.g., Custom Function RCE), full system compromise. All self-hosted Flowise 3.0.8 deployments that rely on the default middleware are affected.
GitHub Security Advisory: GHSA-m4h2-mjfm-mp55
Package: mercurius (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 16.8.0
Patched in: 16.8.0

Summary: Mercurius's queryDepth limit bypassed for WebSocket subscriptions

Details:
## Description

Mercurius fails to enforce the configured queryDepth limit on GraphQL subscription queries received over WebSocket connections. The depth check is correctly applied to HTTP queries and mutations, but subscription queries are parsed and executed without invoking the depth validation. This allows a remote client to submit arbitrarily deeply nested subscription queries over WebSocket, bypassing the intended depth restriction. On schemas with recursive types, this can lead to denial of service through exponential data resolution on each subscription event.

## Workarounds

Disable subscriptions and, in general, queries over the WebSocket.
GitHub Security Advisory: GHSA-79wj-8rqv-jvp5
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 9.0.0, < 9.5.0-alpha.4
Patched in: 9.5.0-alpha.4

Summary: parse-server's endpoint `/loginAs` allows `readOnlyMasterKey` to gain full read and write access as any user

Details:
### Impact

The `readOnlyMasterKey` can call `POST /loginAs` to obtain a valid session token for any user. This allows a read-only credential to impersonate arbitrary users with full read and write access to their data. Any Parse Server deployment that uses `readOnlyMasterKey` is affected.

### Patches

The fix adds a check to the `/logInAs` handler.

### Workarounds

There is no workaround other than not using `readOnlyMasterKey`.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-79wj-8rqv-jvp5
- Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.4
- Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.6
GitHub Security Advisory: GHSA-79wj-8rqv-jvp5
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 8.6.6
Patched in: 8.6.6

Summary: parse-server's endpoint `/loginAs` allows `readOnlyMasterKey` to gain full read and write access as any user

Details:
### Impact

The `readOnlyMasterKey` can call `POST /loginAs` to obtain a valid session token for any user. This allows a read-only credential to impersonate arbitrary users with full read and write access to their data. Any Parse Server deployment that uses `readOnlyMasterKey` is affected.

### Patches

The fix adds a check to the `/logInAs` handler.

### Workarounds

There is no workaround other than not using `readOnlyMasterKey`.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-79wj-8rqv-jvp5
- Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.4
- Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.6
GitHub Security Advisory: GHSA-xfh7-phr7-gr2x
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 8.6.5
Patched in: 8.6.5

Summary: parse-server's file creation and deletion bypasses `readOnlyMasterKey` write restriction

Details:
### Impact

The `readOnlyMasterKey` can be used to create and delete files via the Files API (`POST /files/:filename`, `DELETE /files/:filename`). This bypasses the read-only restriction which violates the access scope of the `readOnlyMasterKey`.

Any Parse Server deployment that uses `readOnlyMasterKey` and exposes the Files API is affected. An attacker with access to the `readOnlyMasterKey` can upload arbitrary files or delete existing files.

### Patches

The fix adds permission checks to both the file upload and file delete handlers.

### Workarounds

There is no workaround other than not using `readOnlyMasterKey`, or restricting network access to the Files API endpoints.

### References
 
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-xfh7-phr7-gr2x
- Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.3
- Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.5
GitHub Security Advisory: GHSA-xfh7-phr7-gr2x
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 9.0.0, < 9.5.0-alpha.3
Patched in: 9.5.0-alpha.3

Summary: parse-server's file creation and deletion bypasses `readOnlyMasterKey` write restriction

Details:
### Impact

The `readOnlyMasterKey` can be used to create and delete files via the Files API (`POST /files/:filename`, `DELETE /files/:filename`). This bypasses the read-only restriction which violates the access scope of the `readOnlyMasterKey`.

Any Parse Server deployment that uses `readOnlyMasterKey` and exposes the Files API is affected. An attacker with access to the `readOnlyMasterKey` can upload arbitrary files or delete existing files.

### Patches

The fix adds permission checks to both the file upload and file delete handlers.

### Workarounds

There is no workaround other than not using `readOnlyMasterKey`, or restricting network access to the Files API endpoints.

### References
 
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-xfh7-phr7-gr2x
- Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.3
- Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.5
GitHub Security Advisory: GHSA-9r75-g2cr-3h76
Package: @workflow/core (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 4.1.0-beta.63
Patched in: 4.2.0-beta.64

Summary: Vercel Workflow Allows Webhook Creation with Predictable User-Specified Tokens

Details:
`createWebhook()` in Vercel Workflow DevKit accepts a user-specified `token` parameter that serves as the credential for the public webhook endpoint `/.well-known/workflow/v1/webhook/{token}`. Official documentation recommended predictable token patterns, making it possible for an unauthenticated remote attacker to guess the token and inject arbitrary payloads into the workflow execution context.

#### Impact

An attacker who guesses a webhook token can resume the associated workflow with an attacker-controlled HTTP request body, potentially triggering downstream side effects such as API calls, database writes, or deployments.

#### Fix

* Upgrade to version 4.2.0-beta.64. The fix removes the `token` option from `createWebhook()` so that webhook tokens are always randomly generated by the SDK.
* Runs created with versions prior to 4.2.0-beta.64, that are 1) still active (i.e. running), and 2) have open hooks, are still susceptible to this vulnerability. If users suspect the hook tokens are predictable or leaked - consider cancelling those runs and restarting them on the latest patch.

#### Workarounds

In case a version upgrade is not possible, avoid passing predictable or guessable values to the `token` parameter of `createWebhook()`. Instead, users can either

* switch from `createWebhook()` to `createHook()` instead and programmatically resume hooks using `resumeHook()` instead of the public webhook endpoint, or
* use `createWebhook()` without passing a user-provided `token`, which uses a non-guessable random `nanoid` by default.
GitHub Security Advisory: GHSA-9r75-g2cr-3h76
Package: workflow (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 4.1.0-beta.63
Patched in: 4.2.0-beta.64

Summary: Vercel Workflow Allows Webhook Creation with Predictable User-Specified Tokens

Details:
`createWebhook()` in Vercel Workflow DevKit accepts a user-specified `token` parameter that serves as the credential for the public webhook endpoint `/.well-known/workflow/v1/webhook/{token}`. Official documentation recommended predictable token patterns, making it possible for an unauthenticated remote attacker to guess the token and inject arbitrary payloads into the workflow execution context.

#### Impact

An attacker who guesses a webhook token can resume the associated workflow with an attacker-controlled HTTP request body, potentially triggering downstream side effects such as API calls, database writes, or deployments.

#### Fix

* Upgrade to version 4.2.0-beta.64. The fix removes the `token` option from `createWebhook()` so that webhook tokens are always randomly generated by the SDK.
* Runs created with versions prior to 4.2.0-beta.64, that are 1) still active (i.e. running), and 2) have open hooks, are still susceptible to this vulnerability. If users suspect the hook tokens are predictable or leaked - consider cancelling those runs and restarting them on the latest patch.

#### Workarounds

In case a version upgrade is not possible, avoid passing predictable or guessable values to the `token` parameter of `createWebhook()`. Instead, users can either

* switch from `createWebhook()` to `createHook()` instead and programmatically resume hooks using `resumeHook()` instead of the public webhook endpoint, or
* use `createWebhook()` without passing a user-provided `token`, which uses a non-guessable random `nanoid` by default.
GitHub Security Advisory: GHSA-46wh-pxpv-q5gq
Package: express-rate-limit (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 8.0.0, < 8.0.2
Patched in: 8.0.2

Summary: express-rate-limit: IPv4-mapped IPv6 addresses bypass per-client rate limiting on servers with dual-stack network

Details:
## Summary

The default `keyGenerator` in express-rate-limit applies IPv6 subnet masking (`/56` by default) to all addresses that `net.isIPv6()` returns true for. This includes IPv4-mapped IPv6 addresses (`::ffff:x.x.x.x`), which Node.js returns as `request.ip` on dual-stack servers.

Because the first 80 bits of all IPv4-mapped addresses are zero, a `/56` (or any `/32` to `/80`) subnet mask produces the same network key (`::/56`) for **every** IPv4 client. This collapses all IPv4 traffic into a single rate-limit bucket: one client exhausting the limit causes HTTP 429 for all other IPv4 clients.

## Details

### Root Cause

In `source/ip-key-generator.ts`:

```typescript
export function ipKeyGenerator(ip: string, ipv6Subnet: number | false = 56) {
  if (ipv6Subnet && isIPv6(ip)) {
    return `${new Address6(`${ip}/${ipv6Subnet}`).startAddress().correctForm()}/${ipv6Subnet}`
  }
  return ip
}
```

`net.isIPv6('::ffff:192.168.1.1')` returns `true`, so IPv4-mapped addresses enter the subnet masking path. With a `/56` prefix, the start address for any `::ffff:x.x.x.x` is `::`, producing the key `::/56`.

### Proof of Concept

```javascript
const { isIPv6 } = require('net');
const { Address6 } = require('ip-address');

function ipKeyGenerator(ip, ipv6Subnet = 56) {
  if (ipv6Subnet && isIPv6(ip)) {
    return `${new Address6(`${ip}/${ipv6Subnet}`).startAddress().correctForm()}/${ipv6Subnet}`;
  }
  return ip;
}

console.log(ipKeyGenerator('::ffff:192.168.1.1', 56)); // ::/56
console.log(ipKeyGenerator('::ffff:10.0.0.1', 56));    // ::/56
console.log(ipKeyGenerator('::ffff:8.8.8.8', 56));     // ::/56
// ALL produce '::/56' — same bucket
```

### End-to-End Validation

On a dual-stack Express server (`app.listen(port, '::')`), tested with Express 5.2.1:
- `request.ip` for IPv4 clients is `::ffff:127.0.0.1`
- Rate limit key resolves to `::/56`
- After `limit` requests from any IPv4 client, all other IPv4 clients receive 429

### When This Occurs

- Node.js dual-stack servers (default on Linux when listening on `::`)
- Any environment where `request.ip` contains IPv4-mapped IPv6 addresses
- Only affects the default `keyGenerator` (custom key generators are not affected)

## Impact

- **Denial of Service**: A single client can block all IPv4 traffic by exhausting the shared rate limit
- **Affects default configuration**: No special options needed to trigger this

## Affected Versions

All versions of express-rate-limit between v8.0.0 and v8.2.1.

## Fix

This issue was fixed in commit 14e53888cdfd1b9798faf5b634c4206409e27fc4. This fix has been included in release v8.3.0, and backported to all affected minor versions in the form of releases v8.2.2, v8.1.1, and v8.0.2.
GitHub Security Advisory: GHSA-46wh-pxpv-q5gq
Package: express-rate-limit (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: = 8.1.0
Patched in: 8.1.1

Summary: express-rate-limit: IPv4-mapped IPv6 addresses bypass per-client rate limiting on servers with dual-stack network

Details:
## Summary

The default `keyGenerator` in express-rate-limit applies IPv6 subnet masking (`/56` by default) to all addresses that `net.isIPv6()` returns true for. This includes IPv4-mapped IPv6 addresses (`::ffff:x.x.x.x`), which Node.js returns as `request.ip` on dual-stack servers.

Because the first 80 bits of all IPv4-mapped addresses are zero, a `/56` (or any `/32` to `/80`) subnet mask produces the same network key (`::/56`) for **every** IPv4 client. This collapses all IPv4 traffic into a single rate-limit bucket: one client exhausting the limit causes HTTP 429 for all other IPv4 clients.

## Details

### Root Cause

In `source/ip-key-generator.ts`:

```typescript
export function ipKeyGenerator(ip: string, ipv6Subnet: number | false = 56) {
  if (ipv6Subnet && isIPv6(ip)) {
    return `${new Address6(`${ip}/${ipv6Subnet}`).startAddress().correctForm()}/${ipv6Subnet}`
  }
  return ip
}
```

`net.isIPv6('::ffff:192.168.1.1')` returns `true`, so IPv4-mapped addresses enter the subnet masking path. With a `/56` prefix, the start address for any `::ffff:x.x.x.x` is `::`, producing the key `::/56`.

### Proof of Concept

```javascript
const { isIPv6 } = require('net');
const { Address6 } = require('ip-address');

function ipKeyGenerator(ip, ipv6Subnet = 56) {
  if (ipv6Subnet && isIPv6(ip)) {
    return `${new Address6(`${ip}/${ipv6Subnet}`).startAddress().correctForm()}/${ipv6Subnet}`;
  }
  return ip;
}

console.log(ipKeyGenerator('::ffff:192.168.1.1', 56)); // ::/56
console.log(ipKeyGenerator('::ffff:10.0.0.1', 56));    // ::/56
console.log(ipKeyGenerator('::ffff:8.8.8.8', 56));     // ::/56
// ALL produce '::/56' — same bucket
```

### End-to-End Validation

On a dual-stack Express server (`app.listen(port, '::')`), tested with Express 5.2.1:
- `request.ip` for IPv4 clients is `::ffff:127.0.0.1`
- Rate limit key resolves to `::/56`
- After `limit` requests from any IPv4 client, all other IPv4 clients receive 429

### When This Occurs

- Node.js dual-stack servers (default on Linux when listening on `::`)
- Any environment where `request.ip` contains IPv4-mapped IPv6 addresses
- Only affects the default `keyGenerator` (custom key generators are not affected)

## Impact

- **Denial of Service**: A single client can block all IPv4 traffic by exhausting the shared rate limit
- **Affects default configuration**: No special options needed to trigger this

## Affected Versions

All versions of express-rate-limit between v8.0.0 and v8.2.1.

## Fix

This issue was fixed in commit 14e53888cdfd1b9798faf5b634c4206409e27fc4. This fix has been included in release v8.3.0, and backported to all affected minor versions in the form of releases v8.2.2, v8.1.1, and v8.0.2.