deardaniel/secdata-raw huggingface dataset:
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: >= 9.0.0-alpha.1, < 9.6.0-alpha.4
Patched in: 9.6.0-alpha.4

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
GitHub Security Advisory: GHSA-v8w9-8mx6-g223
Package: hono (NPM)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 4.12.7
Patched in: 4.12.7

Summary: Hono vulnerable to Prototype Pollution possible through __proto__ key allowed in parseBody({ dot: true })

Details:
## Summary

When using `parseBody({ dot: true })` in HonoRequest, specially crafted form field names such as `__proto__.x` could create objects containing a `__proto__` property.

If the parsed result is later merged into regular JavaScript objects using unsafe merge patterns, this may lead to prototype pollution in the target object.

## Details

The `parseBody({ dot: true })` feature supports dot notation to construct nested objects from form field names.

In previous versions, the `__proto__` path segment was not filtered. As a result, specially crafted keys such as `__proto__.x` could produce objects containing `__proto__` properties.

While this behavior does not directly modify `Object.prototype` within Hono itself, it may become exploitable if the parsed result is later merged into regular JavaScript objects using unsafe merge patterns.

## Impact

Applications that merge parsed form data into regular objects using unsafe patterns (for example recursive deep merge utilities) may become vulnerable to prototype pollution.
GitHub Security Advisory: GHSA-q3vj-96h2-gwvg
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.29
Patched in: 8.6.29

Summary: Parse Server vulnerable to SQL injection via `Increment` operation on nested object field in 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 `amount` value is interpolated directly into the SQL query without parameterization or type validation. An attacker who can send write requests to the Parse Server REST API can inject arbitrary SQL subqueries to read any data from the database, bypassing CLPs and ACLs.

MongoDB deployments are not affected.

### Patches

The fix adds type validation to reject non-number values and parameterizes the value in the SQL query instead of interpolating it.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q3vj-96h2-gwvg
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.3
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.29
GitHub Security Advisory: GHSA-q3vj-96h2-gwvg
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.3
Patched in: 9.6.0-alpha.3

Summary: Parse Server vulnerable to SQL injection via `Increment` operation on nested object field in 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 `amount` value is interpolated directly into the SQL query without parameterization or type validation. An attacker who can send write requests to the Parse Server REST API can inject arbitrary SQL subqueries to read any data from the database, bypassing CLPs and ACLs.

MongoDB deployments are not affected.

### Patches

The fix adds type validation to reject non-number values and parameterizes the value in the SQL query instead of interpolating it.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q3vj-96h2-gwvg
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.3
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.29
GitHub Security Advisory: GHSA-7m6r-fhh7-r47c
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Vulnerable versions: < 8.6.26
Patched in: 8.6.26

Summary: Parse Server vulnerable to LDAP injection via unsanitized user input in DN and group filter construction

Details:
### Impact

The LDAP authentication adapter is vulnerable to LDAP injection. User-supplied input (`authData.id`) is interpolated directly into LDAP Distinguished Names (DN) and group search filters without escaping special characters. This allows an attacker with valid LDAP credentials to manipulate the bind DN structure and to bypass group membership checks. This enables privilege escalation from any authenticated LDAP user to a member of any restricted group.

The vulnerability affects Parse Server deployments that use the LDAP authentication adapter with group-based access control.

### Patches

The vulnerability is fixed by escaping user input before interpolation into DN strings (per [RFC 4514](https://datatracker.ietf.org/doc/html/rfc4514#section-2.4)) and LDAP filter strings (per [RFC 4515](https://datatracker.ietf.org/doc/html/rfc4515#section-3)).

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7m6r-fhh7-r47c
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.13
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.26
GitHub Security Advisory: GHSA-7m6r-fhh7-r47c
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.2-alpha.13
Patched in: 9.5.2-alpha.13

Summary: Parse Server vulnerable to LDAP injection via unsanitized user input in DN and group filter construction

Details:
### Impact

The LDAP authentication adapter is vulnerable to LDAP injection. User-supplied input (`authData.id`) is interpolated directly into LDAP Distinguished Names (DN) and group search filters without escaping special characters. This allows an attacker with valid LDAP credentials to manipulate the bind DN structure and to bypass group membership checks. This enables privilege escalation from any authenticated LDAP user to a member of any restricted group.

The vulnerability affects Parse Server deployments that use the LDAP authentication adapter with group-based access control.

### Patches

The vulnerability is fixed by escaping user input before interpolation into DN strings (per [RFC 4514](https://datatracker.ietf.org/doc/html/rfc4514#section-2.4)) and LDAP filter strings (per [RFC 4515](https://datatracker.ietf.org/doc/html/rfc4515#section-3)).

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7m6r-fhh7-r47c
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.13
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.26
GitHub Security Advisory: GHSA-7xg7-rqf6-pw6c
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 8.6.25
Patched in: 8.6.25

Summary: Parse Server: Classes `_GraphQLConfig` and `_Audience` master key bypass via generic class routes

Details:
### Impact

The `_GraphQLConfig` and `_Audience` internal classes can be read, modified, and deleted via the generic `/classes/_GraphQLConfig` and `/classes/_Audience` REST API routes without master key authentication. This bypasses the master key enforcement that exists on the dedicated `/graphql-config` and `/push_audiences` endpoints. An attacker can read, modify and delete GraphQL configuration and push audience data.

### Patches

The fix adds the affected internal classes to the `classesWithMasterOnlyAccess` list, ensuring that the generic `/classes/` routes enforce master key access consistently with the dedicated endpoints.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7xg7-rqf6-pw6c
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.12
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.25
GitHub Security Advisory: GHSA-7xg7-rqf6-pw6c
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.2-alpha.12
Patched in: 9.5.2-alpha.12

Summary: Parse Server: Classes `_GraphQLConfig` and `_Audience` master key bypass via generic class routes

Details:
### Impact

The `_GraphQLConfig` and `_Audience` internal classes can be read, modified, and deleted via the generic `/classes/_GraphQLConfig` and `/classes/_Audience` REST API routes without master key authentication. This bypasses the master key enforcement that exists on the dedicated `/graphql-config` and `/push_audiences` endpoints. An attacker can read, modify and delete GraphQL configuration and push audience data.

### Patches

The fix adds the affected internal classes to the `classesWithMasterOnlyAccess` list, ensuring that the generic `/classes/` routes enforce master key access consistently with the dedicated endpoints.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7xg7-rqf6-pw6c
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.12
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.25
GitHub Security Advisory: GHSA-775h-3xrc-c228
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-799: Improper Control of Interaction Frequency
Vulnerable versions: < 8.6.23
Patched in: 8.6.23

Summary: Parse Server has a rate limit bypass via batch request endpoint

Details:
### Impact

Parse Server's rate limiting middleware is applied at the Express middleware layer, but the batch request endpoint (`/batch`) processes sub-requests internally by routing them directly through the Promise router, bypassing Express middleware including rate limiting. An attacker can bundle multiple requests targeting a rate-limited endpoint into a single batch request to circumvent the configured rate limit.

Any Parse Server deployment that relies on the built-in rate limiting feature is affected.

### Patches

The fix adds a pre-flight check in the batch request handler that counts the number of sub-requests targeting each rate-limited path and rejects the entire batch request if any path's count exceeds its configured `requestCount`.

Note that this is a server-level rate limit that counts sub-requests within a single batch request. Requests already consumed in the current time window by previous individual or batch requests are not counted against the batch, so the effective limit may be higher when combining individual and batch requests. For comprehensive rate limiting protection, use a reverse proxy or WAF.

### Workarounds

Use a reverse proxy or web application firewall (WAF) to enforce rate limiting before requests reach Parse Server.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-775h-3xrc-c228
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.10
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.23
GitHub Security Advisory: GHSA-775h-3xrc-c228
Package: parse-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-799: Improper Control of Interaction Frequency
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.2-alpha.10
Patched in: 9.5.2-alpha.10

Summary: Parse Server has a rate limit bypass via batch request endpoint

Details:
### Impact

Parse Server's rate limiting middleware is applied at the Express middleware layer, but the batch request endpoint (`/batch`) processes sub-requests internally by routing them directly through the Promise router, bypassing Express middleware including rate limiting. An attacker can bundle multiple requests targeting a rate-limited endpoint into a single batch request to circumvent the configured rate limit.

Any Parse Server deployment that relies on the built-in rate limiting feature is affected.

### Patches

The fix adds a pre-flight check in the batch request handler that counts the number of sub-requests targeting each rate-limited path and rejects the entire batch request if any path's count exceeds its configured `requestCount`.

Note that this is a server-level rate limit that counts sub-requests within a single batch request. Requests already consumed in the current time window by previous individual or batch requests are not counted against the batch, so the effective limit may be higher when combining individual and batch requests. For comprehensive rate limiting protection, use a reverse proxy or WAF.

### Workarounds

Use a reverse proxy or web application firewall (WAF) to enforce rate limiting before requests reach Parse Server.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-775h-3xrc-c228
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.10
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.23
GitHub Security Advisory: GHSA-fr88-w35c-r596
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 8.6.22
Patched in: 8.6.22

Summary: Parse Server OAuth2 authentication adapter account takeover via identity spoofing

Details:
### Impact

The OAuth2 authentication adapter, when configured without the `useridField` option, only verifies that a token is active via the provider's token introspection endpoint, but does not verify that the token belongs to the user identified by `authData.id`. An attacker with any valid OAuth2 token from the same provider can authenticate as any other user.

This affects any Parse Server deployment that uses the generic OAuth2 authentication adapter (configured with `oauth2: true`) without setting the `useridField` option.

### Patches

The vulnerability is fixed by defaulting `useridField` to `sub`, which is the standard subject identifier field defined by [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662). The adapter now always validates the token's identity against the claimed user ID, even when `useridField` is not explicitly configured.

### Workarounds

Set the `useridField` option to the appropriate field name for your OAuth2 provider (e.g. `sub`) in the Parse Server authentication configuration.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-fr88-w35c-r596
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.9
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.22
GitHub Security Advisory: GHSA-fr88-w35c-r596
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.2-alpha.9
Patched in: 9.5.2-alpha.9

Summary: Parse Server OAuth2 authentication adapter account takeover via identity spoofing

Details:
### Impact

The OAuth2 authentication adapter, when configured without the `useridField` option, only verifies that a token is active via the provider's token introspection endpoint, but does not verify that the token belongs to the user identified by `authData.id`. An attacker with any valid OAuth2 token from the same provider can authenticate as any other user.

This affects any Parse Server deployment that uses the generic OAuth2 authentication adapter (configured with `oauth2: true`) without setting the `useridField` option.

### Patches

The vulnerability is fixed by defaulting `useridField` to `sub`, which is the standard subject identifier field defined by [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662). The adapter now always validates the token's identity against the claimed user ID, even when `useridField` is not explicitly configured.

### Workarounds

Set the `useridField` option to the appropriate field name for your OAuth2 provider (e.g. `sub`) in the Parse Server authentication configuration.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-fr88-w35c-r596
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.9
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.22
GitHub Security Advisory: GHSA-5f92-jrq3-28rc
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 8.6.20
Patched in: 8.6.20

Summary: Parse Server has role escalation and CLP bypass via direct `_Join` table write

Details:
### Impact

Parse Server's internal tables, which store Relation field mappings such as role memberships, can be directly accessed via the REST API or GraphQL API by any client using only the application key. No master key is required.

An attacker can create, read, update, or delete records in any internal relationship table. Exploiting this allows the attacker to inject themselves into any Parse Role, gaining all permissions associated with that role, including full read, write, and delete access to classes protected by role-based Class-Level Permissions (CLP). Similarly, writing to any such table that backs a Relation field used in a `pointerFields` CLP bypasses that access control.

### Patches

The fix blocks direct client access to internal relationship tables in Parse Server's role security enforcement. All create, find, get, update, and delete operations on these tables now require the master key or maintenance key.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5f92-jrq3-28rc
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.7
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.20
GitHub Security Advisory: GHSA-5f92-jrq3-28rc
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 9.0.0-alpha.1, < 9.5.2-alpha.7
Patched in: 9.5.2-alpha.7

Summary: Parse Server has role escalation and CLP bypass via direct `_Join` table write

Details:
### Impact

Parse Server's internal tables, which store Relation field mappings such as role memberships, can be directly accessed via the REST API or GraphQL API by any client using only the application key. No master key is required.

An attacker can create, read, update, or delete records in any internal relationship table. Exploiting this allows the attacker to inject themselves into any Parse Role, gaining all permissions associated with that role, including full read, write, and delete access to classes protected by role-based Class-Level Permissions (CLP). Similarly, writing to any such table that backs a Relation field used in a `pointerFields` CLP bypasses that access control.

### Patches

The fix blocks direct client access to internal relationship tables in Parse Server's role security enforcement. All create, find, get, update, and delete operations on these tables now require the master key or maintenance key.

### Workarounds

There is no known workaround.

### References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-5f92-jrq3-28rc
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.7
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.20
GitHub Security Advisory: GHSA-6r2j-cxgf-495f
Package: parse-server (NPM)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 8.6.21
Patched in: 8.6.21

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