deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-j7mm-f4rv-6q6q
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.9
Patched in: 9.6.0-alpha.9

Summary: Parse Server has a protected fields bypass via LiveQuery subscription WHERE clause

Details:
### Impact

An attacker can exploit LiveQuery subscriptions to infer the values of protected fields without directly receiving them. By subscribing with a WHERE clause that references a protected field (including via dot-notation or `$regex`), the attacker can observe whether LiveQuery events are delivered for matching objects. This creates a boolean oracle that leaks protected field values. The attack affects any class that has both `protectedFields` configured in Class-Level Permissions and LiveQuery enabled.

### Patches

The fix adds validation of the LiveQuery subscription WHERE clause against the class's protected fields, mirroring the existing REST API validation. If a subscription's WHERE clause references a protected field directly, via dot-notation, or inside `$or` / `$and` / `$nor` operators, the subscription is rejected with a permission error. This is applied during subscription creation, so existing event delivery paths are not affected.

### Workarounds

Disable LiveQuery for classes that use `protectedFields` in their Class-Level Permissions, or remove `protectedFields` from classes that require LiveQuery.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-j7mm-f4rv-6q6q
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.9
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.35
GitHub Security Advisory: GHSA-5339-hvwr-7582
Package: unhead (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 2.1.10
Patched in: 2.1.11

Summary: Unhead Vulnerable to Bypass of URI Scheme Sanitization in makeTagSafe via Case-Sensitivity

Details:
The `link.href` check in `makeTagSafe` (safe.ts, line 68-71) uses `String.includes()`, which is case-sensitive:

```typescript
if (key === 'href') {
  if (val.includes('javascript:') || val.includes('data:')) {
    return
  }
  next[key] = val
}
```

Browsers treat URI schemes case-insensitively. `DATA:text/css,...` is the same as `data:text/css,...` to the browser, but `'DATA:...'.includes('data:')` returns `false`.

### PoC

```javascript
useHeadSafe({
  link: [{
    rel: 'stylesheet',
    href: 'DATA:text/css,body{display:none}'
  }]
})
```

SSR output:

```html
<link rel="stylesheet" href="DATA:text/css,body{display:none}">
```

The browser loads this as a CSS stylesheet. An attacker can inject arbitrary CSS for UI redressing or data exfiltration via CSS attribute selectors with background-image callbacks.

Any case variation works: `DATA:`, `Data:`, `dAtA:`, `JAVASCRIPT:`, etc.

## Suggested fix

```typescript
if (key === 'href') {
  const lower = val.toLowerCase()
  if (lower.includes('javascript:') || lower.includes('data:')) {
    return
  }
  next[key] = val
}
```
GitHub Security Advisory: GHSA-cfw5-2vxh-hr84
Package: devalue (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 5.6.4
Patched in: 5.6.4

Summary: devalue has prototype pollution in devalue.parse and devalue.unflatten

Details:
In devalue v5.6.3, `devalue.parse` and `devalue.unflatten` were susceptible to prototype pollution via maliciously crafted payloads. Successful exploitation could lead to Denial of Service (DoS) or type confusion.
GitHub Security Advisory: GHSA-wp52-r2fp-4vmr
Package: pdfmake (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 0.3.0-beta.2, < 0.3.6
Patched in: 0.3.6

Summary: pdfmake is vulnerable to server-side request forgery (SSRF)

Details:
Server-Side Request Forgery (SSRF) vulnerability in pdfmake versions 0.3.0-beta.2 through 0.3.5 allows a remote attacker to obtain sensitive information via the src/URLResolver.js component. The fix was released in version 0.3.6 which introduces the setUrlAccessPolicy() method allowing server operators to define URL access rules. A warning is now logged when pdfmake is used server-side without a policy configured.
GitHub Security Advisory: GHSA-9jfh-9xrq-4vwm
Package: shescape (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 2.1.10
Patched in: 2.1.10

Summary: Shescape escape() leaves bracket glob expansion active on Bash, BusyBox, and Dash

Details:
### Summary

`Shescape#escape()` does not escape square-bracket glob syntax for Bash, BusyBox `sh`, and Dash. Applications that interpolate the return value directly into a shell command string can cause an attacker-controlled value like `secret[12]` to expand into multiple filesystem matches instead of a single literal argument, turning one argument into multiple trusted-pathname matches.

### Details

The unquoted Unix escape helpers never add `[` or `]` to their “special characters” regexes:

- `src/internal/unix/bash.js:14-30`
- `src/internal/unix/busybox.js:14-30`
- `src/internal/unix/dash.js:12-19`

They escape `*`/`?` but not brackets, so `new Shescape({ shell: "/usr/bin/bash" }).escape("secret[12]")` still produces `secret[12]`. The fixtures (`test/fixtures/unix.js:2236-2265`, `3496-3525`, `5762-5792`) are currently written to expect literal brackets for these shells, confirming the behavior. The documentation recommends `Shescape#escape()` as the fallback for `exec` when quoting isn’t possible (`docs/recipes.md:154-183`).

### Proof of Concept

Use the published npm tarball without modifications:

```shell
tmp=$(mktemp -d)
cd "$tmp"
npm pack shescape@2.1.9 >/dev/null
mkdir pkg
tar -xzf shescape-2.1.9.tgz -C pkg
cd pkg/package
npm install --omit=dev

node --input-type=module - <<'NODE'
import { mkdtempSync, writeFileSync } from "node:fs";
import { tmpdir } from "node:os";
import path from "node:path";
import { execSync } from "node:child_process";
import { Shescape } from "./src/index.js";

const dir = mkdtempSync(path.join(tmpdir(), "shescape-ghsa-poc-"));
writeFileSync(path.join(dir, "secret1"), "");
writeFileSync(path.join(dir, "secret2"), "");

for (const shell of ["/usr/bin/bash", "/usr/bin/dash"]) {
  const shescape = new Shescape({ shell });
  const escaped = shescape.escape("secret[12]");
  console.log(${shell} escaped=${escaped});
  const out = execSync(printf '<%s>\\n' ${escaped}, { cwd: dir, shell }).toString();
  process.stdout.write(out);
}
NODE
```

Output:

```text
/usr/bin/bash escaped=secret[12]
<secret1>
<secret2>
/usr/bin/dash escaped=secret[12]
<secret1>
<secret2>
```

Expected: the shell receives `secret\[12\]`, so only one literal argument runs.

### Impact

Argument injection: a single untrusted argument expands into multiple pathname matches from the trusted filesystem. This can change command behavior, target unintended files, or leak filenames. Any application calling `Shescape#escape()` with Bash/BusyBox/Dash shells and interpolating the result into a shell command string is affected.
GitHub Security Advisory: GHSA-mmf8-487q-p45m
Package: @striae-org/striae (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm, CWE-353: Missing Support for Integrity Check, CWE-354: Improper Validation of Integrity Check Value
Vulnerable versions: >= 0.9.22-0, < 3.0.0
Patched in: 3.0.0

Summary: Striae has a hash validation utility vulnerability

Details:
## Summary

A high-severity integrity bypass vulnerability existed in Striae's digital confirmation workflow prior to v3.0.0. Hash-only validation trusted manifest hash fields that could be modified together with package content, allowing tampered confirmation packages to pass integrity checks.

## Impact

Confirmation package integrity could be bypassed because both content and hash values were mutable in the same trust boundary. An attacker with access to an exported package could alter confirmation data and recompute hashes so hash-only checks still passed.

This affects users relying on digital confirmations as an immutability and forensic chain-of-custody control.

## Patches

Patched in **v3.0.0**.

Upgrade to:
- `v3.0.0` or later

Security behavior added in v3.0.0:
- Server-issued asymmetric signatures for forensic manifests
- Canonical payload signature verification during import and manual hash verification
- Fail-closed behavior when signature metadata is missing or invalid
- Signature/key provenance support for audit-related workflows

## Workarounds

There is no full cryptographic workaround equivalent to upgrading.

Temporary mitigations:
- Treat hash-only validation as a tamper indicator, not proof of immutability
- Restrict package exchange to trusted authenticated internal channels
- Require out-of-band reviewer attestation for sensitive confirmation workflows
- Pause imports from untrusted sources until upgraded
GitHub Security Advisory: GHSA-w54v-hf9p-8856
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-204: Observable Response Discrepancy
Vulnerable versions: < 8.6.34
Patched in: 8.6.34

Summary: Parse Server vulnerable to user enumeration via email verification endpoint

Details:
### Impact

The email verification endpoint (`/verificationEmailRequest`) returns distinct error responses depending on whether an email address belongs to an existing user, is already verified, or does not exist. An attacker can send requests with different email addresses and observe the error codes to determine which email addresses are registered in the application.

This is a user enumeration vulnerability that affects any Parse Server deployment with email verification enabled (`verifyUserEmails: true`).

### Patches

The fix introduces a new Parse Server option `emailVerifySuccessOnInvalidEmail` (default: `true`) that returns a generic success response for all verification email requests, regardless of whether the email address is valid, already verified, or non-existent. This prevents an attacker from distinguishing between these cases.

The fix also strengthens the input validation for the related `resetPasswordSuccessOnInvalidEmail` option, and adds security checks that warn when either enumeration mitigation is disabled.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-w54v-hf9p-8856
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.8
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.34
GitHub Security Advisory: GHSA-w54v-hf9p-8856
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-204: Observable Response Discrepancy
Vulnerable versions: >= 9.0.0-alpha.1, < 9.6.0-alpha.8
Patched in: 9.6.0-alpha.8

Summary: Parse Server vulnerable to user enumeration via email verification endpoint

Details:
### Impact

The email verification endpoint (`/verificationEmailRequest`) returns distinct error responses depending on whether an email address belongs to an existing user, is already verified, or does not exist. An attacker can send requests with different email addresses and observe the error codes to determine which email addresses are registered in the application.

This is a user enumeration vulnerability that affects any Parse Server deployment with email verification enabled (`verifyUserEmails: true`).

### Patches

The fix introduces a new Parse Server option `emailVerifySuccessOnInvalidEmail` (default: `true`) that returns a generic success response for all verification email requests, regardless of whether the email address is valid, already verified, or non-existent. This prevents an attacker from distinguishing between these cases.

The fix also strengthens the input validation for the related `resetPasswordSuccessOnInvalidEmail` option, and adds security checks that warn when either enumeration mitigation is disabled.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-w54v-hf9p-8856
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.8
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.34
GitHub Security Advisory: GHSA-4hf6-3x24-c9m8
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: < 8.6.33
Patched in: 8.6.33

Summary: Parse Server's MFA recovery codes not consumed after use

Details:
### Impact

When multi-factor authentication (MFA) via TOTP is enabled for a user account, Parse Server generates two single-use recovery codes. These codes are intended as a fallback when the user cannot provide a TOTP token. However, recovery codes are not consumed after use, allowing the same recovery code to be used an unlimited number of times. This defeats the single-use design of recovery codes and weakens the security of MFA-protected accounts.

An attacker who obtains a single recovery code can repeatedly authenticate as the affected user without the code ever being invalidated.

### Patches

The fix ensures that each recovery code is removed from the stored recovery code list after a successful login.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.33
GitHub Security Advisory: GHSA-4hf6-3x24-c9m8
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: >= 9.0.0-alpha.1, < 9.6.0-alpha.7
Patched in: 9.6.0-alpha.7

Summary: Parse Server's MFA recovery codes not consumed after use

Details:
### Impact

When multi-factor authentication (MFA) via TOTP is enabled for a user account, Parse Server generates two single-use recovery codes. These codes are intended as a fallback when the user cannot provide a TOTP token. However, recovery codes are not consumed after use, allowing the same recovery code to be used an unlimited number of times. This defeats the single-use design of recovery codes and weakens the security of MFA-protected accounts.

An attacker who obtains a single recovery code can repeatedly authenticate as the affected user without the code ever being invalidated.

### Patches

The fix ensures that each recovery code is removed from the stored recovery code list after a successful login.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.33
GitHub Security Advisory: GHSA-r2m8-pxm9-9c4g
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 8.6.32
Patched in: 8.6.32

Summary: Parse Server has a protected fields bypass via dot-notation in query and sort

Details:
### Impact

The `protectedFields` class-level permission (CLP) can be bypassed using dot-notation in query WHERE clauses and sort parameters. An attacker can use dot-notation to query or sort by sub-fields of a protected field, enabling a binary oracle attack to enumerate protected field values.

This affects both MongoDB and PostgreSQL deployments.

### Patches

The fix ensures that query WHERE clause keys and sort keys are checked against protected fields by extracting the root field from dot-notation paths. For example, a query on `secretObj.apiKey` is now correctly blocked when `secretObj` is a protected field.

### Workarounds

None.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-r2m8-pxm9-9c4g
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.6
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.32
GitHub Security Advisory: GHSA-r2m8-pxm9-9c4g
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 9.0.0-alpha.1, < 9.6.0-alpha.6
Patched in: 9.6.0-alpha.6

Summary: Parse Server has a protected fields bypass via dot-notation in query and sort

Details:
### Impact

The `protectedFields` class-level permission (CLP) can be bypassed using dot-notation in query WHERE clauses and sort parameters. An attacker can use dot-notation to query or sort by sub-fields of a protected field, enabling a binary oracle attack to enumerate protected field values.

This affects both MongoDB and PostgreSQL deployments.

### Patches

The fix ensures that query WHERE clause keys and sort keys are checked against protected fields by extracting the root field from dot-notation paths. For example, a query on `secretObj.apiKey` is now correctly blocked when `secretObj` is a protected field.

### Workarounds

None.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-r2m8-pxm9-9c4g
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.6
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.32
GitHub Security Advisory: GHSA-gqpp-xgvh-9h7h
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.31
Patched in: 8.6.31

Summary: Parse Server vulnerable to SQL Injection via dot-notation sub-key name in `Increment` operation on PostgreSQL

Details:
### Impact

A SQL injection vulnerability exists in the PostgreSQL storage adapter when processing `Increment` operations on nested object fields using dot notation (e.g., `stats.counter`). The sub-key name is interpolated directly into SQL string literals without escaping. An attacker who can send write requests to the Parse Server REST API can inject arbitrary SQL via a crafted sub-key name containing single quotes, potentially executing commands or reading data from the database, bypassing CLPs and ACLs.

Only Postgres deployments are affected.

### Patches

The fix escapes single quotes in the sub-key name before interpolating it into the SQL query, preventing breakout from SQL string literals.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-gqpp-xgvh-9h7h
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.5
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.31
GitHub Security Advisory: GHSA-gqpp-xgvh-9h7h
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-alpha.1, < 9.6.0-alpha.5
Patched in: 9.6.0-alpha.5

Summary: Parse Server vulnerable to SQL Injection via dot-notation sub-key name in `Increment` operation on PostgreSQL

Details:
### Impact

A SQL injection vulnerability exists in the PostgreSQL storage adapter when processing `Increment` operations on nested object fields using dot notation (e.g., `stats.counter`). The sub-key name is interpolated directly into SQL string literals without escaping. An attacker who can send write requests to the Parse Server REST API can inject arbitrary SQL via a crafted sub-key name containing single quotes, potentially executing commands or reading data from the database, bypassing CLPs and ACLs.

Only Postgres deployments are affected.

### Patches

The fix escapes single quotes in the sub-key name before interpolating it into the SQL query, preventing breakout from SQL string literals.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-gqpp-xgvh-9h7h
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.5
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.31
GitHub Security Advisory: GHSA-v5hf-f4c3-m5rv
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 8.6.30
Patched in: 8.6.30

Summary: Parse Server vulnerable to stored XSS via file upload of HTML-renderable file types

Details:
### Impact

An attacker can upload a file with a file extension or content type that is not blocked by the default configuration of the Parse Server `fileUpload.fileExtensions` option. The file can contain malicious code, for example JavaScript in an SVG or XHTML file. When the file is accessed via its URL, the browser renders the file and executes the malicious code in the context of the Parse Server domain. This is a stored Cross-Site Scripting (XSS) vulnerability that can be exploited to steal session tokens, redirect users, or perform actions on behalf of other users.

Affected file extensions and content types include `.svgz`, `.xht`, `.xml`, `.xsl`, `.xslt`, and content types `application/xhtml+xml` and `application/xslt+xml` for extensionless uploads. Uploading of `.html`, `.htm`, `.shtml`, `.xhtml`, and `.svg` files was already blocked.

### Patches

The fix adds the missing file extensions and content types to the default value of the `fileUpload.fileExtensions` server option.

### Workarounds

Configure the `fileUpload.fileExtensions` server option to block the affected file extensions and content types.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-v5hf-f4c3-m5rv
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.4
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.30