CVE-2026-30972: Parse Server Auth Bypass Vulnerability

CVE-2026-30972 Overview

Parse Server, an open source backend that can be deployed to any infrastructure running Node.js, contains a rate limiting bypass vulnerability in versions prior to 9.5.2-alpha.10 and 8.6.23. The vulnerability exists because 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. This allows attackers to circumvent configured rate limits by bundling multiple requests into a single batch request.

Critical Impact

Any Parse Server deployment relying on the built-in rate limiting feature is vulnerable to rate limit bypass attacks, potentially enabling brute force attacks, credential stuffing, or resource exhaustion against protected endpoints.

Affected Products

• Parse Server versions prior to 8.6.23 (8.x branch)
• Parse Server versions 9.5.2-alpha1 through 9.5.2-alpha9
• All Parse Server deployments utilizing built-in rate limiting features

Discovery Timeline

• 2026-03-10 - CVE-2026-30972 published to NVD
• 2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-30972

Vulnerability Analysis

This vulnerability is classified as CWE-799 (Improper Control of Interaction Frequency), which relates to the failure to properly limit the rate at which operations can be performed. The core issue stems from an architectural design flaw in how Parse Server implements rate limiting across different request processing paths.

Parse Server provides a built-in rate limiting feature that administrators configure to protect endpoints from abuse, such as brute force login attempts or API abuse. This rate limiting is implemented as Express middleware, which intercepts incoming HTTP requests before they reach the application logic. However, the /batch endpoint exists to allow clients to bundle multiple operations into a single HTTP request for efficiency.

When a batch request arrives, the Express middleware correctly processes the single HTTP request (counting it as one request against rate limits). However, the individual sub-requests within the batch are then processed internally through the Promise router, which completely bypasses the Express middleware layer—including rate limiting. This creates a significant security gap where an attacker can execute thousands of operations against a rate-limited endpoint while only consuming a single rate limit token.

Root Cause

The root cause is the separation between the Express middleware stack and the internal Promise router used for batch request processing. The rate limiting middleware was designed with the assumption that all requests would flow through the Express pipeline, but the batch endpoint's internal routing mechanism operates outside this security boundary. This architectural oversight means that rate limiting controls are not enforced on the actual operations being performed, only on the HTTP requests being received.

Attack Vector

An attacker can exploit this vulnerability by sending a single POST request to the /batch endpoint containing multiple sub-requests targeting a rate-limited endpoint. For example, if an authentication endpoint is configured to allow only 5 attempts per minute, an attacker could bundle 1000 login attempts into a single batch request, effectively bypassing the rate limit entirely. This attack requires only network access to the Parse Server instance and no authentication, making it accessible to any remote attacker.

The batch request endpoint accepts an array of operations, each specifying a method, path, and body. The server processes each operation sequentially through the Promise router without checking rate limits for individual operations. This enables attacks such as:

• Credential stuffing against login endpoints
• Brute force attacks on password reset functionality
• Enumeration attacks against user existence checks
• Resource exhaustion through high-volume API operations

Detection Methods for CVE-2026-30972

Indicators of Compromise

• Unusually large batch requests to the /batch endpoint containing many sub-requests
• Repeated batch requests from single IP addresses targeting authentication endpoints
• Successful authentication attempts following a series of batch requests
• Log entries showing multiple failed operations processed within single batch requests

Detection Strategies

• Monitor batch endpoint request sizes and alert on requests containing more than a threshold number of sub-requests
• Implement application-level logging to track operations within batch requests separately from HTTP request counts
• Analyze request patterns for correlation between batch requests and subsequent successful authentications
• Deploy web application firewall rules to inspect and limit batch request payloads

Monitoring Recommendations

• Enable detailed logging for the /batch endpoint to capture sub-request details
• Set up alerts for anomalous request volumes even when rate limiters show normal traffic patterns
• Monitor authentication success rates following periods of heavy batch endpoint usage
• Review application logs for patterns indicating brute force attempts masked by batch requests

How to Mitigate CVE-2026-30972

Immediate Actions Required

• Upgrade Parse Server to version 8.6.23 or 9.5.2-alpha.10 immediately
• Review logs for evidence of exploitation attempts targeting the batch endpoint
• Consider temporarily disabling the batch endpoint if immediate patching is not possible
• Implement additional authentication protections such as account lockout policies and CAPTCHA

Patch Information

The Parse Server maintainers have released patched versions that address this vulnerability. The fix ensures that rate limiting is properly enforced at the operation level within batch requests, not just at the HTTP request level.

• Version 8.6.23: GitHub Release 8.6.23
• Version 9.5.2-alpha.10: GitHub Release 9.5.2-alpha.10

For complete details on the vulnerability and remediation, refer to the GitHub Security Advisory GHSA-775h-3xrc-c228.

Workarounds

• Implement external rate limiting at the reverse proxy or load balancer level that inspects batch request contents
• Deploy a web application firewall rule to limit the number of operations allowed per batch request
• Add custom middleware before the batch endpoint to enforce per-operation rate limiting
• Consider implementing account lockout policies at the database level as an additional defense layer

# Example nginx configuration to limit batch request body size
location /parse/batch {
    client_max_body_size 10k;
    limit_req zone=batch_limit burst=5 nodelay;
    proxy_pass http://parse-server:1337;
}