CVE-2026-30946: 
JavaScript vulnerability analysis and mitigation

CVE-2026-30946 is a denial-of-service vulnerability in Parse Server, an open-source Node.js backend, caused by the absence of query complexity limits in its REST and GraphQL APIs. An unauthenticated attacker can send crafted queries to exhaust server resources including CPU, memory, and database connections. Affected versions are all Parse Server releases prior to 8.6.15 (8.x branch) and versions 9.0.0 through 9.5.2-alpha.1 (9.x branch). The vulnerability was published on March 10, 2026, with patches released the same day. It carries a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (Github Advisory, Parse Server Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): Parse Server's REST and GraphQL API endpoints did not impose any limits on query complexity, such as subquery nesting depth, include path depth, include field count, or GraphQL field selection depth. An attacker can craft queries with deeply nested subqueries (e.g., using $inQuery, $notInQuery, $select, $dontSelect) or highly complex GraphQL field selections that force the server to perform exponentially expensive database operations. No authentication is required, and no special preconditions beyond network access to the Parse Server API endpoint are needed. The fix introduces a configurable requestComplexity server option with keys subqueryDepth, includeDepth, includeCount, graphQLDepth, and graphQLFields; requests using master or maintenance keys bypass these limits (Parse Server Advisory, Github Advisory).

Successful exploitation results in a denial-of-service condition affecting all users of the Parse Server deployment, as CPU, memory, and database connections are exhausted by crafted queries. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. All Parse Server deployments exposing the REST or GraphQL API are susceptible, meaning any application built on Parse Server (mobile backends, web apps, IoT platforms) could be rendered unavailable (Github Advisory, Parse Server Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Github Advisory). The vulnerability requires no authentication, no user interaction, and no special privileges, making it trivially exploitable by any network-accessible attacker. The EPSS score is approximately 0.022% (7th percentile), indicating a low current probability of exploitation in the next 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Reconnaissance: Identify internet-facing Parse Server instances by scanning for common Parse Server API endpoints (e.g., /parse/classes/, /parse/graphql) using tools like Shodan, Censys, or direct HTTP probing. Confirm the server version is below 8.6.15 or between 9.0.0 and 9.5.2-alpha.1.
2. Craft a complex REST query: Construct a REST API request with deeply nested subqueries using operators such as $inQuery or $notInQuery, maximizing nesting depth to force expensive recursive database lookups. For example, send a GET /parse/classes/MyClass request with a where parameter containing multiple levels of nested $inQuery referencing other classes.
3. Craft a complex GraphQL query: Alternatively, send a GraphQL query to /parse/graphql with deeply nested field selections and a large number of fields, designed to maximize server-side processing time and memory allocation.
4. Flood with requests: Send a high volume of these crafted queries concurrently (e.g., using tools like ab, wrk, or custom scripts) to amplify resource exhaustion across CPU, memory, and database connection pools.
5. Achieve denial of service: The server becomes unresponsive or crashes as resources are fully consumed, denying service to all legitimate users (Parse Server Advisory).

• Network: Unusually high volume of HTTP requests to /parse/classes/, /parse/graphql, or other Parse Server API endpoints from one or more source IPs; requests with abnormally large or deeply nested where or query body parameters.
• Logs: Parse Server access logs showing repeated complex queries with deeply nested $inQuery, $notInQuery, $select, or $dontSelect operators; GraphQL requests with unusually large query bodies or high field counts; elevated error rates or timeout responses in server logs.
• Process/System: Sustained high CPU utilization by the Node.js Parse Server process; memory usage approaching system limits; exhaustion of database connection pool (e.g., MongoDB or PostgreSQL connection limit errors in server logs); increased query execution times in database slow query logs.

Upgrade Parse Server to version 8.6.15 (8.x branch) or 9.5.2-alpha.2 (9.x branch) to receive the fix (Parse Server 8.6.15 Release, Parse Server 9.5.2-alpha.2 Release). After upgrading, configure the requestComplexity server option with appropriate limits for subqueryDepth, includeDepth, includeCount, graphQLDepth, and graphQLFields to suit your application's legitimate query patterns. Note that versions 8.6.46 and 9.6.0-alpha.22 changed the defaults for these limits to -1 (disabled) to restore backwards compatibility — operators on these later versions must explicitly set limits to be protected. There is no known workaround short of patching; as interim measures, consider implementing rate limiting and query size restrictions at a reverse proxy or API gateway layer, and monitor server resource utilization for anomalies (Parse Server Advisory).