CVE-2026-31901: Parse Server Email User Enumeration Flaw

CVE-2026-31901 Overview

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. A user enumeration vulnerability exists in versions prior to 8.6.34 and 9.6.0-alpha.8 within the email verification endpoint (/verificationEmailRequest). The endpoint returns distinct error responses depending on whether an email address belongs to an existing user, is already verified, or does not exist. An attacker can send requests with different email addresses and observe the error codes to determine which email addresses are registered in the application.

Critical Impact

This user enumeration vulnerability affects any Parse Server deployment with email verification enabled (verifyUserEmails: true), allowing attackers to harvest valid user email addresses for targeted phishing campaigns or credential stuffing attacks.

Affected Products

• Parse Server versions prior to 8.6.34 (stable branch)
• Parse Server versions prior to 9.6.0-alpha.8 (alpha branch)
• Any Parse Server deployment with email verification enabled (verifyUserEmails: true)

Discovery Timeline

• 2026-03-11 - CVE-2026-31901 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-31901

Vulnerability Analysis

This vulnerability is classified under CWE-204 (Observable Response Discrepancy), which occurs when an application provides different responses that reveal the existence or state of a resource. In Parse Server, the email verification request endpoint behaves differently based on the status of the submitted email address, creating an oracle that attackers can abuse.

When an attacker submits various email addresses to the /verificationEmailRequest endpoint, the server responds with distinct error messages or codes depending on three possible states: the email exists and requires verification, the email exists and is already verified, or the email does not exist in the system. This information leakage allows attackers to enumerate valid user accounts within the application.

The network-accessible nature of this vulnerability means that exploitation requires no authentication or prior access to the target system. However, some attack complexity exists as the attacker must analyze response patterns to distinguish between the different states.

Root Cause

The root cause lies in the email verification request handler's error response logic. Instead of returning a generic response regardless of the email's registration status, the implementation returns specific error codes or messages that differentiate between registered users, already-verified users, and non-existent accounts. This behavior, while potentially useful for debugging or user experience, creates an information disclosure vector that can be exploited by malicious actors.

Attack Vector

The attack vector is network-based and requires no authentication. An attacker can automate requests to the /verificationEmailRequest endpoint with a list of potential email addresses (harvested from data breaches, social media, or generated programmatically). By analyzing the HTTP response codes and error messages returned by the server, the attacker can build a list of valid registered email addresses.

This enumerated list of valid users can then be leveraged for:

• Targeted phishing campaigns against confirmed users
• Credential stuffing attacks using known email/password combinations from other breaches
• Social engineering attacks with knowledge of account existence
• Privacy violations by confirming whether specific individuals use the service

Detection Methods for CVE-2026-31901

Indicators of Compromise

• Unusual volume of requests to the /verificationEmailRequest endpoint from a single IP address or IP range
• Sequential or pattern-based email address submissions indicating automated enumeration attempts
• Rapid requests with varying email addresses that suggest dictionary or list-based testing
• Failed verification requests significantly outnumbering successful ones

Detection Strategies

• Implement rate limiting monitoring on the email verification endpoint and alert on threshold breaches
• Analyze web server access logs for patterns consistent with enumeration attacks (high request volume, varied email parameters, same source IP)
• Deploy web application firewall (WAF) rules to detect and block automated enumeration attempts
• Monitor application-level logs for repeated verification failures from the same source

Monitoring Recommendations

• Configure alerts for request rate anomalies on authentication and verification endpoints
• Implement SIEM rules to correlate rapid sequential requests to sensitive endpoints
• Enable detailed logging on the /verificationEmailRequest endpoint including request source, timing, and response codes
• Establish baseline metrics for normal verification request patterns to identify deviations

How to Mitigate CVE-2026-31901

Immediate Actions Required

• Upgrade Parse Server to version 8.6.34 or later for stable deployments
• Upgrade Parse Server to version 9.6.0-alpha.8 or later for alpha channel deployments
• Implement rate limiting on the /verificationEmailRequest endpoint as a temporary mitigation
• Review access logs for evidence of prior enumeration attempts

Patch Information

The vulnerability is fixed in Parse Server versions 8.6.34 and 9.6.0-alpha.8. The fix normalizes the response behavior of the email verification endpoint to return consistent responses regardless of whether an email address is registered, already verified, or non-existent. Organizations should update to these patched versions immediately.

For detailed patch information, refer to the GitHub Security Advisory GHSA-w54v-hf9p-8856.

Release notes are available at:

• Parse Server 8.6.34 Release
• Parse Server 9.6.0-alpha.8 Release

Workarounds

• Implement rate limiting on the /verificationEmailRequest endpoint to slow enumeration attempts
• Deploy a web application firewall (WAF) with rules to detect and block rapid enumeration patterns
• Consider temporarily disabling email verification (verifyUserEmails: false) if not critical to operations, until patching is complete
• Use CAPTCHA or similar challenge-response mechanisms on the verification request endpoint

# Example nginx rate limiting configuration for Parse Server
# Add to nginx server block to limit verification endpoint requests

limit_req_zone $binary_remote_addr zone=verification_limit:10m rate=5r/m;

location /parse/verificationEmailRequest {
    limit_req zone=verification_limit burst=2 nodelay;
    proxy_pass http://parse_server;
}