Impact

A relation query using the $relatedTo operator could read the membership of a Relation field even when that field was hidden from the requesting client by protectedFields, and even when the object owning the relation was not readable by the client under its ACL or class-level permissions. The request requires only the public API credentials that Parse clients normally carry — no user session, master key, or Cloud Code is needed.

As a result, an unauthenticated client who knows or obtains the owning object's objectId could enumerate the objects linked through a protected relation, or combine the operator with an objectId constraint to use it as a membership oracle — confirming whether a specific object is linked to a private parent. This affects applications that rely on protectedFields or object ACLs to keep Relation membership confidential, such as private group memberships, block lists, or account-to-resource associations.

Patches

The relation query path now authorizes $relatedTo against the owning object before reading the relation join table, using the caller's authentication context. The relation key is checked against the owning class's protectedFields (the query is rejected if the key is protected), and the owning object must be readable by the caller under its class-level permissions, ACL, and pointer permissions; otherwise the relation returns no results. Master and maintenance requests are unaffected. The check is applied consistently whether $relatedTo is used at the top level or nested within $or, $and, or $nor.

Workarounds

There is no complete workaround without upgrading. As mitigation, applications can avoid exposing sensitive membership through Relation fields to untrusted clients, or enforce access on the queried class in a beforeFind trigger.

Impact

The routeAllowList server option restricts external client access to a configured list of REST API routes. The check is only enforced as Express middleware against the outer HTTP request URL, so the /batch handler dispatches each sub-request to the internal router without re-running the allow-list check. An external caller whose outer route matches batch can issue batch sub-requests to any REST API route that the operator omitted from the allow-list.

Authentication, ACL, CLP, and other inner-route authorization controls still apply — only the operator-configured route firewall is bypassed.

Patches

routeAllowList is now re-enforced for each batch sub-request inside the batch handler before dispatch, mirroring the existing per-sub-request rate-limit enforcement pattern. The path-normalization and regex-match logic was extracted into a shared helper used by both the outer middleware and the batch handler. Master and maintenance keys bypass the per-sub-request check on the same terms as the outer middleware.

Workarounds

Operators who use routeAllowList and have allowlisted batch can mitigate without upgrading by explicitly including every inner route they intend to allow via batch in the allow-list (for example, routeAllowList: ['batch', 'classes/Public.', 'functions/allowedFunction']). This approach makes those inner routes reachable as direct REST requests as well, so it is broader than the post-patch behavior, but it eliminates the bypass.

Operators who do not configure routeAllowList are not affected. Parse Server v8 LTS is not affected because routeAllowList was introduced in v9.8.0.

This is the daily security digest covering confirmed npm, PyPI, and supply-chain security threats detected in the past 24 hours. A total of 14 threats have been identified across various ecosystems, including active credential harvesting campaigns.

📊 Threat Summary

|Package(s)|Ecosystem|Severity|CVE|Vulnerability| |:-|:-|:-|:-|:-| |u/cap-js/sqlite, postgres, db-service|npm|CRITICAL|CVE-2026-46421|Credential harvesting / Self-propagation| |u/beproduct/nestjs-auth|npm|CRITICAL|CVE-2026-46412|Mini Shai-Hulud worm payload| |guardrails-ai|PyPI|CRITICAL|CVE-2026-45758|Supply chain compromise| |Parse Server|npm|HIGH|CVE-2026-47138|DoS via header regex backtracking| |qs|npm|HIGH|CVE-2026-8723|Remotely triggerable DoS| |u/libp2p/gossipsub|npm|HIGH|CVE-2026-46679|Memory DoS (Subscription flood)| |u/libp2p/kad-dht|npm|HIGH|CVE-2026-45783|Disk exhaustion (Unvalidated PUT)| |SQLFluff|PyPI|HIGH|CVE-2026-46374|DoS via Resource Exhaustion| |Diffusers|ai-ml|HIGH|CVE-2026-45804|TOCTOU Remote Code Execution| |lmdeploy|ai-ml|HIGH|CVE-2026-46517|Unsafe remote-code load path| |Crawlee for Python|PyPI|HIGH|CVE-2026-46497|SSRF via sitemap-derived URLs| |SillyTavern|ai-ml|HIGH|CVE-2026-46372|SSRF in SearXNG Search Proxy| |samlify|npm|HIGH|CVE-2026-46490|XML Injection / Privilege Escalation| |js-cookie|npm|HIGH|CVE-2026-46625|Prototype hijack / Cookie injection|

🚨 CRITICAL Alerts (Immediate Action Required)

1. u/cap-js ecosystem compromise (CVE-2026-46421)

Threat: Compromised versions of u/cap-js/sqlite, u/cap-js/postgres, and u/cap-js/db-service were published to harvest credentials and self-propagate. Action: Upgrade immediately (sqlite \>= 2.4.0, postgres \>= 2.3.0, db-service \>= 2.10.2). Assume all local credentials are compromised if you installed the malicious versions.

2. u/beproduct/nestjs-auth worm (CVE-2026-46412)

Threat: Malicious versions containing payloads from the Mini Shai-Hulud npm supply-chain worm campaign were published. Action: Remove and reinstall dependencies. Audit for signs of compromise if installed during the affected window (v0.1.2 - 0.1.19).

3. guardrails-ai compromise (CVE-2026-45758)

Threat: A malicious version of guardrails-ai (0.10.1) was published to PyPI. It has been quarantined. Action: Uninstall guardrails-ai==0.10.1 and reinstall a known good version.

⚠️ HIGH Severity Highlights

Denial of Service (DoS) Wave: Several major packages are vulnerable to crashing today. Parse Server (CVE-2026-47138) can be taken down pre-auth via a regex backtracking attack in the client version header. qs (CVE-2026-8723) will crash on specific null/undefined arrays. u/libp2p packages are vulnerable to both memory and disk exhaustion attacks. AI Toolchain Remote Code Execution: Both Diffusers (CVE-2026-45804) and lmdeploy (CVE-2026-46517) have vulnerabilities bypassing trustremotecode guardrails, allowing arbitrary remote code execution on model fetch. SSRF & Injection: Crawlee for Python and SillyTavern both suffer from SSRF vulnerabilities requiring configuration updates. samlify is vulnerable to XML injection leading to privilege escalation, and js-cookie is vulnerable to a prototype hijacking attack.

Automated daily digest, created via https://github.com/Deam0on/wakellm - feedback welcome. Stay safe out there!

Impact

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

Patches

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

Workarounds

Use beforeFind(Parse.File) instead of afterFind(Parse.File) for file access authorization. The beforeFind trigger runs on all download paths including streaming.

Impact

An authenticated user with find class-level permission can bypass the protectedFields class-level permission setting on LiveQuery subscriptions. By sending a subscription with a $or, $and, or $nor operator value as a plain object with numeric keys and a length property (an "array-like" object) instead of an array, the protected-field guard is bypassed. The subscription event firing acts as a binary oracle, allowing the attacker to infer whether a protected field matches a given test value.

Patches

The fix validates that $or, $and, and $nor operator values are arrays in the LiveQuery subscription handler, the query depth checker, and the protected-field guard. As defense in depth, the LiveQuery query evaluator also rejects non-array values for these operators.

Workarounds

There is no known workaround.

Impact

The GraphQL query complexity validator can be exploited to cause a denial-of-service by sending a crafted query with binary fan-out fragment spreads. A single unauthenticated request can block the Node.js event loop for seconds, denying service to all concurrent users. This only affects deployments that have enabled the requestComplexity.graphQLDepth or requestComplexity.graphQLFields configuration options.

Patches

The fix replaces the per-branch fragment traversal with memoized fragment computation, reducing the traversal from exponential O(2^N) to linear O(N) time. Additionally, early termination aborts the traversal as soon as configured limits are exceeded.

Workarounds

Disable GraphQL complexity limits by setting requestComplexity.graphQLDepth and requestComplexity.graphQLFields to -1 (the default).

Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-mfj6-6p54-m98c - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10344 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10345

Impact

An attacker can bypass Cloud Function validator access controls by appending .prototype.constructor to the function name in the URL. When a Cloud Function handler is declared using the function keyword and its validator is a plain object or arrow function, the trigger store traversal resolves the handler through its own prototype chain while the validator store fails to mirror this traversal, causing all access control enforcement to be skipped.

This allows unauthenticated callers to invoke Cloud Functions that are meant to be protected by validators such as requireUser, requireMaster, or custom validation logic.

Patches

The trigger store traversal now verifies that each intermediate node is a legitimate store object before continuing traversal. If the traversal encounters a non-store value such as a function handler, it stops and returns an empty store, preventing prototype chain escape.

Workarounds

Use arrow functions instead of the function keyword for Cloud Function handlers. Arrow functions do not have a prototype property and are not affected by this vulnerability.

Resources

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-vpj2-qq7w-5qq6 - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10342 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10343

Impact

An authenticated user calling GET /users/me receives unsanitized auth data, including sensitive credentials such as MFA TOTP secrets and recovery codes. The endpoint internally uses master-level authentication for the session query, and the master context leaks through to the user data, bypassing auth adapter sanitization. An attacker who obtains a user's session token can extract MFA secrets to generate valid TOTP codes indefinitely.

Patches

The /users/me endpoint now queries the session and user data separately, using the caller's authentication context for the user query so that all security layers apply correctly.

Workarounds

There is no known workaround.

Impact

An attacker who obtains a user's password and a single MFA recovery code can reuse that recovery code an unlimited number of times by sending concurrent login requests. This defeats the single-use design of recovery codes. The attack requires the user's password, a valid recovery code, and the ability to send concurrent requests within milliseconds.

Patches

The login handler now uses optimistic locking when updating auth data that contains consumed single-use tokens. If a concurrent request has already modified the recovery array, the update fails and the login is rejected.

Workarounds

There are no known workarounds.

Impact

The password reset mechanism does not enforce single-use guarantees for reset tokens. When a user requests a password reset, the generated token can be consumed by multiple concurrent requests within a short time window. An attacker who has intercepted a password reset token can race the legitimate user's password reset request, causing both requests to succeed. This may result in the legitimate user believing their password was changed successfully while the attacker's password takes effect instead.

All Parse Server deployments that use the password reset feature are affected.

Patches

The password reset token is now atomically validated and consumed as part of the password update operation. The database query that updates the password includes the reset token as a condition, ensuring that only one concurrent request can successfully consume the token. Subsequent requests using the same token will fail because the token has already been cleared.

Workarounds

There is no known workaround other than upgrading.

Impact

Any Parse Server deployment that uses the GraphQL API is affected. The GraphQL WebSocket endpoint for subscriptions does not pass requests through the Express middleware chain that enforces authentication, introspection control, and query complexity limits. An attacker can connect to the WebSocket endpoint and execute GraphQL operations without providing a valid application or API key, access the GraphQL schema via introspection even when public introspection is disabled, and send arbitrarily complex queries that bypass configured complexity limits.

Patches

The unfinished GraphQL WebSocket subscription feature has been removed, including the createSubscriptions method and the subscriptions-transport-ws dependency. GraphQL subscriptions were never functional in Parse Server as the schema did not define any subscription types.

Workarounds

Block WebSocket upgrade requests to the GraphQL subscriptions path (by default /subscriptions) at the network level, for example using a reverse proxy or load balancer rule.

Impact

The OAuth2 authentication adapter does not correctly validate app IDs when appidField and appIds are configured. During app ID validation, a malformed value is sent to the token introspection endpoint instead of the user's actual access token. Depending on the introspection endpoint's behavior, this could either cause all OAuth2 logins to fail, or allow authentication from disallowed app contexts if the endpoint returns valid-looking data for the malformed request.

Deployments using the OAuth2 adapter with appidField and appIds configured are affected.

Patches

The fix corrects the parameter alignment in the OAuth2 adapter's app ID validation method to match the expected interface, ensuring the correct access token is sent to the introspection endpoint.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-69xg-f649-w5g2 - Fix in Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.13 - Fix in Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.39

Impact

An attacker with access to the master key can inject malicious SQL via crafted field names used in query constraints when Parse Server is configured with PostgreSQL as the database. The field name in a $regex query operator is passed to PostgreSQL using unparameterized string interpolation, allowing the attacker to manipulate the SQL query. While the master key controls what can be done through the Parse Server abstraction layer, this SQL injection bypasses Parse Server entirely and operates at the database level.

This vulnerability only affects Parse Server deployments using PostgreSQL.

Patches

The fix applies proper SQL identifier escaping to field names in the query handler and hardens query field name validation to reject malicious field names for all query types.

Workarounds

There is no known workaround.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-c442-97qw-j6c6 - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.10 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.36

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

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) and LDAP filter strings (per RFC 4515).

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

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 /pushaudiences 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

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

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

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

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

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

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

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

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

If the server options are not set their default values apply to fix the vulnerability. Requests using master key or maintenance key bypass these limits. Set any property to -1 to disable that specific limit.

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

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

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.OPERATIONFORBIDDEN, '$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

Impact

When graphQLPublicIntrospection is disabled, type queries nested inside inline fragments (e.g. ... on Query { type(name:"User") { name } }) bypass the introspection control, allowing unauthenticated users to perform type reconnaissance. schema introspection is not affected.

Patches

The check was changed from a flat iteration over root-level selections to a recursive walk of all selection sets, detecting type inside inline fragments at any depth.

Workarounds

Require master key authentication at the network layer (e.g. reverse proxy) for the GraphQL endpoint.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-q5q9-2rhp-33qw - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.10

Impact

The file metadata endpoint (GET /files/:appId/metadata/:filename) does not enforce beforeFind / afterFind file triggers. When these triggers are used as access-control gates, the metadata endpoint bypasses them entirely, allowing unauthorized access to file metadata.

This affects any deployment that relies on Parse.Cloud.beforeFind(Parse.File, ...) to restrict file access. Only file metadata (user-defined key-value pairs set via addMetadata) is exposed; file content remains protected.

Patches

The metadata handler now runs beforeFind and afterFind triggers and returns HTTP 403 when a trigger denies access.

Workarounds

Disable the metadata endpoint by overriding the route with a middleware that rejects all requests:

js // Add before mounting Parse Server app.get('/parse/files/:appId/metadata/:filename', (req, res) => { res.status(403).json({ error: 'Forbidden' }); });

Adjust the path prefix (/parse) to match your mountPath.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hwx8-q9cg-mqmc - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.9 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.9

Impact

The PagesRouter static file serving route is vulnerable to a path traversal attack that allows unauthenticated reading of files outside the configured pagesPath directory. The boundary check uses a string prefix comparison without enforcing a directory separator boundary. An attacker can use path traversal sequences to access files in sibling directories whose names share the same prefix as the pages directory (e.g. pages-secret starts with pages).

This affects any Parse Server deployment with the pages feature enabled (pages.enableRouter: true). Exploitation requires a sibling directory of pagesPath whose name begins with the same string as the pages directory name.

Patches

The fix enforces a path separator boundary in the check, ensuring resolved paths must be strictly inside the pagesPath directory.

Workarounds

Ensure the pagesPath directory has no sibling directories whose names begin with the same prefix. For example, if pagesPath is /srv/pages, ensure no directory like /srv/pages-backup or /srv/pagesold exists alongside it.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-hm3f-q6rw-m6wh - Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.8 - Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.8

Impact

The Google, Apple, and Facebook authentication adapters use JWT verification to validate identity tokens. When the adapter's audience configuration option is not set (clientId for Google/Apple, appIds for Facebook), JWT verification silently skips audience claim validation. This allows an attacker to use a validly signed JWT issued for a different application to authenticate as any user on the target Parse Server.

- For Google and Apple, the vulnerability is exploitable when the server does not configure clientId. The adapters accepted this as valid and simply skipped audience validation. - For Facebook Limited Login, the vulnerability exists regardless of configuration. The adapter validated appIds only for Standard Login (Graph API), but the Limited Login JWT path never passed appIds as the audience to JWT verification.

Patches

The fix enforces clientId (Google/Apple) and appIds (Facebook) as mandatory and passes them to JWT verification for audience validation. While this is technically a breaking change for servers that omit these options, it is not a breaking change as per documentation — all three options are documented as required configuration.

Workarounds

- Google / Apple: Ensure clientId is set in the adapter configuration. When set, JWT verification correctly validates the audience claim even on unpatched versions. - Facebook Limited Login: There is no workaround. The unpatched adapter does not pass appIds to JWT audience validation, so the only mitigation is to upgrade.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-x6fw-778m-wr9v - Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.11 - Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.10