deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-6r2j-cxgf-495f
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.2-alpha.8
Patched in: 9.5.2-alpha.8

Summary: Parse Server vulnerable to session token exfiltration via `redirectClassNameForKey` query parameter

Details:
### Impact

A vulnerability in Parse Server's query handling allows an authenticated or unauthenticated attacker to exfiltrate session tokens of other users by exploiting the `redirectClassNameForKey` query parameter. Exfiltrated session tokens can be used to take over user accounts.

The vulnerability requires the attacker to be able to create or update an object with a new relation field, which depends on the Class-Level Permissions of at least one class.

### Patches

The fix applies the same security checks that normally protect class access after the query redirect, ensuring that queries redirected via `redirectClassNameForKey` are subject to the same restrictions as direct queries to the target class.

### Workarounds

Set restrictive Class-Level Permissions to prevent clients from creating new fields on classes, specifically by disabling `addField` for public access and unauthenticated users. Note that this limits client functionality and does not fully eliminate the risk if a relation field pointing to a protected class already exists in the schema.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-6r2j-cxgf-495f
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.8
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.21
GitHub Security Advisory: GHSA-72hp-qff8-4pvv
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 8.6.19
Patched in: 8.6.19

Summary: Parse Server has a protected fields bypass via logical query operators

Details:
### Impact

The validation for protected fields only checks top-level query keys. By wrapping a query constraint on a protected field inside a logical operator, the check is bypassed entirely. This allows any authenticated user to query on protected fields to extract field values.

All Parse Server deployments have default protected fields and are vulnerable.

### Patches

The fix adds recursive validation of sub-queries with logical operators, consistent with the existing recursive validation patterns.

### Workarounds

Use a `beforeFind` trigger on affected classes to manually inspect the query for protected field references in logical operator sub-queries and reject the request.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-72hp-qff8-4pvv
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.6
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.19
GitHub Security Advisory: GHSA-72hp-qff8-4pvv
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 9.0.0, < 9.5.2-alpha.6
Patched in: 9.5.2-alpha.6

Summary: Parse Server has a protected fields bypass via logical query operators

Details:
### Impact

The validation for protected fields only checks top-level query keys. By wrapping a query constraint on a protected field inside a logical operator, the check is bypassed entirely. This allows any authenticated user to query on protected fields to extract field values.

All Parse Server deployments have default protected fields and are vulnerable.

### Patches

The fix adds recursive validation of sub-queries with logical operators, consistent with the existing recursive validation patterns.

### Workarounds

Use a `beforeFind` trigger on affected classes to manually inspect the query for protected field references in logical operator sub-queries and reject the request.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-72hp-qff8-4pvv
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.6
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.19
GitHub Security Advisory: GHSA-48mh-j4p5-7j9v
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 8.6.18
Patched in: 8.6.18

Summary: Parse Server missing audience validation in Keycloak authentication adapter

Details:
### Impact

The Keycloak authentication adapter does not validate the `azp` (authorized party) claim of Keycloak access tokens against the configured `client-id`. A valid access token issued by the same Keycloak realm for a *different* client application can be used to authenticate as any user on the Parse Server that uses the Keycloak adapter. This enables cross-application account takeover in multi-client Keycloak realms.

All Parse Server deployments that use the Keycloak authentication adapter with a Keycloak realm that has multiple client applications are affected.

### Patches

The fix replaces the userinfo HTTP call with local JWT verification and enforces `azp` claim validation against the configured `client-id`.

### Workarounds

None.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-48mh-j4p5-7j9v
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.5
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.18
GitHub Security Advisory: GHSA-48mh-j4p5-7j9v
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 9.0.0, < 9.5.2-alpha.5
Patched in: 9.5.2-alpha.5

Summary: Parse Server missing audience validation in Keycloak authentication adapter

Details:
### Impact

The Keycloak authentication adapter does not validate the `azp` (authorized party) claim of Keycloak access tokens against the configured `client-id`. A valid access token issued by the same Keycloak realm for a *different* client application can be used to authenticate as any user on the Parse Server that uses the Keycloak adapter. This enables cross-application account takeover in multi-client Keycloak realms.

All Parse Server deployments that use the Keycloak authentication adapter with a Keycloak realm that has multiple client applications are affected.

### Patches

The fix replaces the userinfo HTTP call with local JWT verification and enforces `azp` claim validation against the configured `client-id`.

### Workarounds

None.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-48mh-j4p5-7j9v
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.5
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.18
GitHub Security Advisory: GHSA-hcj7-6gxh-24ww
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 8.6.17
Patched in: 8.6.17

Summary: Parse Server vulnerable to stored cross-site scripting (XSS) via SVG file upload

Details:
### Impact

A stored cross-site scripting (XSS) vulnerability allows any authenticated user to upload an SVG file containing JavaScript. The file is served inline with `Content-Type: image/svg+xml` and without protective headers, causing the browser to execute embedded scripts in the Parse Server origin. This can be exploited to steal session tokens from `localStorage` and achieve account takeover.

The default `fileExtensions` option blocks HTML file extensions but does not block SVG, which is a well-known XSS vector. All Parse Server deployments where file upload is enabled for authenticated users (the default) are affected.

### Patches

The fix adds `svg` (case-insensitive) to the default file extension denylist. The default regex changes from `^(?![xXsS]?[hH][tT][mM][lL]?$)` to `^(?!([xXsS]?[hH][tT][mM][lL]?|[sS][vV][gG])$)`.

### Workarounds

Configure the `fileExtensions` option to explicitly block SVG uploads:

```js
{
  fileUpload: {
    fileExtensions: ['^(?!([xXsS]?[hH][tT][mM][lL]?|[sS][vV][gG])$)']
  }
}
```

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hcj7-6gxh-24ww
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.4
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.17
GitHub Security Advisory: GHSA-hcj7-6gxh-24ww
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 9.0.0, < 9.5.2-alpha.4
Patched in: 9.5.2-alpha.4

Summary: Parse Server vulnerable to stored cross-site scripting (XSS) via SVG file upload

Details:
### Impact

A stored cross-site scripting (XSS) vulnerability allows any authenticated user to upload an SVG file containing JavaScript. The file is served inline with `Content-Type: image/svg+xml` and without protective headers, causing the browser to execute embedded scripts in the Parse Server origin. This can be exploited to steal session tokens from `localStorage` and achieve account takeover.

The default `fileExtensions` option blocks HTML file extensions but does not block SVG, which is a well-known XSS vector. All Parse Server deployments where file upload is enabled for authenticated users (the default) are affected.

### Patches

The fix adds `svg` (case-insensitive) to the default file extension denylist. The default regex changes from `^(?![xXsS]?[hH][tT][mM][lL]?$)` to `^(?!([xXsS]?[hH][tT][mM][lL]?|[sS][vV][gG])$)`.

### Workarounds

Configure the `fileExtensions` option to explicitly block SVG uploads:

```js
{
  fileUpload: {
    fileExtensions: ['^(?!([xXsS]?[hH][tT][mM][lL]?|[sS][vV][gG])$)']
  }
}
```

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hcj7-6gxh-24ww
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.4
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.17
GitHub Security Advisory: GHSA-7ch5-98q2-7289
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 8.6.16
Patched in: 8.6.16

Summary: Parse Server has a bypass of class-level permissions in LiveQuery

Details:
### Impact

Class-level permissions (CLP) are not enforced for LiveQuery subscriptions. An unauthenticated or unauthorized client can subscribe to any LiveQuery-enabled class and receive real-time events for all objects, regardless of CLP restrictions.

All Parse Server deployments that use LiveQuery with class-level permissions are affected. Data intended to be restricted by CLP is leaked to unauthorized subscribers in real time.

### Patches

The fix enforces CLP before creating the subscription and during event delivery.

### Workarounds

Disable LiveQuery for classes that use CLP restrictions by removing them from the `liveQuery.classNames` server configuration.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7ch5-98q2-7289
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.3
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.16
GitHub Security Advisory: GHSA-7ch5-98q2-7289
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 9.0.0, < 9.5.2-alpha.3
Patched in: 9.5.2-alpha.3

Summary: Parse Server has a bypass of class-level permissions in LiveQuery

Details:
### Impact

Class-level permissions (CLP) are not enforced for LiveQuery subscriptions. An unauthenticated or unauthorized client can subscribe to any LiveQuery-enabled class and receive real-time events for all objects, regardless of CLP restrictions.

All Parse Server deployments that use LiveQuery with class-level permissions are affected. Data intended to be restricted by CLP is leaked to unauthorized subscribers in real time.

### Patches

The fix enforces CLP before creating the subscription and during event delivery.

### Workarounds

Disable LiveQuery for classes that use CLP restrictions by removing them from the `liveQuery.classNames` server configuration.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7ch5-98q2-7289
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.3
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.16
GitHub Security Advisory: GHSA-cmj3-wx7h-ffvg
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 9.0.0, < 9.5.2-alpha.2
Patched in: 9.5.2-alpha.2

Summary: Parse Server affected by denial-of-service via unbounded query complexity in REST and GraphQL API

Details:
### Impact

An unauthenticated attacker can exhaust Parse Server resources (CPU, memory, database connections) through crafted queries that exploit the lack of complexity limits in the REST and GraphQL APIs.

All Parse Server deployments using the REST or GraphQL API are affected.

### Patches

The vulnerability is fixed by introducing configurable request complexity limits via the `requestComplexity` server option with the following keys:

- `subqueryDepth`: Maximum nesting depth for `$inQuery`, `$notInQuery`, `$select`, `$dontSelect`
- `includeDepth`: Maximum depth of dot-separated `include` paths
- `includeCount`: Maximum number of `include` fields per query
- `graphQLDepth`: Maximum depth of GraphQL field selections
- `graphQLFields`: Maximum number of field selections in a GraphQL query

Requests using master key or maintenance key bypass these limits. Set any property to `-1` to disable that specific limit.

In versions `8.6.15` and `9.5.2-alpha.2`, these limits were enabled by default. This unintentionally introduced a breaking change for some applications with legitimate complex queries. In versions `8.6.46` and `9.6.0-alpha.22`, the defaults were changed to `-1` (disabled) to restore backwards compatibility.

The limits remain available as configuration options. To mitigate the vulnerability, upgrade to a patched version and set each `requestComplexity` property to a value appropriate for your application.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-cmj3-wx7h-ffvg
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.2
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.15
GitHub Security Advisory: GHSA-cmj3-wx7h-ffvg
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 8.6.15
Patched in: 8.6.15

Summary: Parse Server affected by denial-of-service via unbounded query complexity in REST and GraphQL API

Details:
### Impact

An unauthenticated attacker can exhaust Parse Server resources (CPU, memory, database connections) through crafted queries that exploit the lack of complexity limits in the REST and GraphQL APIs.

All Parse Server deployments using the REST or GraphQL API are affected.

### Patches

The vulnerability is fixed by introducing configurable request complexity limits via the `requestComplexity` server option with the following keys:

- `subqueryDepth`: Maximum nesting depth for `$inQuery`, `$notInQuery`, `$select`, `$dontSelect`
- `includeDepth`: Maximum depth of dot-separated `include` paths
- `includeCount`: Maximum number of `include` fields per query
- `graphQLDepth`: Maximum depth of GraphQL field selections
- `graphQLFields`: Maximum number of field selections in a GraphQL query

Requests using master key or maintenance key bypass these limits. Set any property to `-1` to disable that specific limit.

In versions `8.6.15` and `9.5.2-alpha.2`, these limits were enabled by default. This unintentionally introduced a breaking change for some applications with legitimate complex queries. In versions `8.6.46` and `9.6.0-alpha.22`, the defaults were changed to `-1` (disabled) to restore backwards compatibility.

The limits remain available as configuration options. To mitigate the vulnerability, upgrade to a patched version and set each `requestComplexity` property to a value appropriate for your application.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-cmj3-wx7h-ffvg
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.2
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.15
GitHub Security Advisory: GHSA-vgjh-hmwf-c588
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-943: Improper Neutralization of Special Elements in Data Query Logic
Vulnerable versions: < 8.6.14
Patched in: 8.6.14

Summary: Parse Server has a NoSQL injection via token type in password reset and email verification endpoints

Details:
### Impact

A NoSQL injection vulnerability allows an unauthenticated attacker to inject MongoDB query operators via the `token` field in the password reset and email verification resend endpoints. The `token` value is passed to database queries without type validation and can be used to extract password reset and email verification tokens.

Any Parse Server deployment using MongoDB with email verification or password reset enabled is affected. When `emailVerifyTokenReuseIfValid` is configured, the email verification token can be fully extracted and used to verify a user's email address without inbox access.

### Patches

### Patches

The vulnerability is fixed by adding input type validation at the endpoint level.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vgjh-hmwf-c588
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.1
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.14
GitHub Security Advisory: GHSA-vgjh-hmwf-c588
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-943: Improper Neutralization of Special Elements in Data Query Logic
Vulnerable versions: >= 9.0.0, < 9.5.2-alpha.1
Patched in: 9.5.2-alpha.1

Summary: Parse Server has a NoSQL injection via token type in password reset and email verification endpoints

Details:
### Impact

A NoSQL injection vulnerability allows an unauthenticated attacker to inject MongoDB query operators via the `token` field in the password reset and email verification resend endpoints. The `token` value is passed to database queries without type validation and can be used to extract password reset and email verification tokens.

Any Parse Server deployment using MongoDB with email verification or password reset enabled is affected. When `emailVerifyTokenReuseIfValid` is configured, the email verification token can be fully extracted and used to verify a user's email address without inbox access.

### Patches

### Patches

The vulnerability is fixed by adding input type validation at the endpoint level.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vgjh-hmwf-c588
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.1
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.14
GitHub Security Advisory: GHSA-7fv4-fmmc-86g2
Package: @siteboon/claude-code-ui (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 1.23.0
Patched in: 1.24.0

Summary: @siteboon/claude-code-ui is Vulnerable to Shell Command Injection in Git Routes

Details:
# Shell Command Injection in User Git Config Endpoint

| Field | Value |
|-------|-------|
| **Severity** | High |
| **CVSS 3.1** | 8.8 (High) — when chained with VULN-01 |
| **CWE** | CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') |
| **Attack Vector** | Network |
| **Authentication** | JWT required (bypassable via VULN-01) |
| **Affected Files** | `server/routes/user.js` (lines 58-59) |

## Description

The `/api/user/git-config` endpoint constructs shell commands by interpolating user-supplied `gitName` and `gitEmail` values into command strings passed to `child_process.exec()`. The input is placed within double quotes and only `"` is escaped, but backticks (`` ` ``), `$()` command substitution, and `\` sequences are all interpreted within double-quoted strings in bash.

This allows authenticated attackers to execute arbitrary OS commands via the git configuration endpoint.

## Root Cause

`server/routes/user.js` lines 58-59:

```javascript
await execAsync(`git config --global user.name "${gitName.replace(/"/g, '\\"')}"`);
await execAsync(`git config --global user.email "${gitEmail.replace(/"/g, '\\"')}"`);
```

Only `"` is escaped. However, within double-quoted bash strings, the following are still interpreted:

- `` `malicious_command` `` — backtick execution
- `$(malicious_command)` — subshell execution

## Impact

- **Remote Code Execution (RCE)** — arbitrary OS commands execute as the Node.js process user
- The `git config --global` vector modifies the **server-wide** git configuration, affecting all git operations
- When chained with VULN-01 (hardcoded JWT), this is fully **unauthenticated RCE**
- Attacker can: read/write any file, install backdoors, pivot to other systems, exfiltrate data

## Proof of Concept

```bash
# Step 1: Forge a JWT (see VULN-01)
TOKEN=$(python3 -c "import jwt; print(jwt.encode({'userId':1,'username':'admin'}, 'claude-ui-dev-secret-change-in-production', algorithm='HS256'))")

# Step 2: Inject via gitName using command substitution
curl -X POST "http://REDACTED:5173/api/user/git-config" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"gitName":"$(id)","gitEmail":"attacker@example.com"}'
```

The server executes:

```
git config --global user.name "$(id)"
```

Bash evaluates `$(id)` before passing it to git, executing the `id` command and setting the username to the output.

## Remediation

Replace `exec()` with `spawn()` (array arguments, no shell):

```javascript
// BEFORE (vulnerable):
await execAsync(`git config --global user.name "${gitName.replace(/"/g, '\\"')}"`);

// AFTER (safe):
await spawnAsync('git', ['config', '--global', 'user.name', gitName]);
await spawnAsync('git', ['config', '--global', 'user.email', gitEmail]);
```