CVE-2026-33323
Username Enumeration via Email Verification in Parse Server Pages Route
Publication date: 2026-03-24
Last updated on: 2026-03-25
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | From 9.0.0 (inc) to 9.6.0 (exc) |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | 9.6.0 |
| parseplatform | parse-server | to 8.6.51 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-204 | The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-33323 is an information leakage vulnerability in the Parse Server's email verification resend functionality. The issue arises because the server's response to resend verification email requests differs depending on whether the username or email exists and is unverified."}, {'type': 'paragraph', 'content': 'Specifically, before the fix, the resend verification email page and legacy PublicAPI route would redirect to different pages based on user existence: a success page if the user existed and a failure page if not. This difference allowed unauthenticated attackers to enumerate valid usernames by observing the redirect targets.'}, {'type': 'paragraph', 'content': 'The vulnerability was addressed by introducing a configuration option called `emailVerifySuccessOnInvalidEmail` which, when enabled (default: true), causes the server to always redirect to the success page regardless of whether the user exists or not, thus preventing user enumeration.'}] [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability allows an unauthenticated attacker to determine whether a username or email address exists in the Parse Server system by observing different redirect responses when requesting to resend email verification links.
Such user enumeration can lead to privacy violations, targeted attacks, or further exploitation by attackers who gain knowledge of valid user accounts.
By exploiting this vulnerability, attackers can gather valid usernames without authentication, which can be used for phishing, brute force attacks, or other malicious activities.
The fix ensures that by default, all resend verification email requests redirect to a success page regardless of user existence, mitigating this risk.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': "This vulnerability can be detected by observing the behavior of the Parse Server's email verification resend endpoint when submitting requests for existing and non-existing users."}, {'type': 'paragraph', 'content': 'Specifically, sending POST requests to the resend verification email route and analyzing the HTTP redirect responses can reveal if user enumeration is possible.'}, {'type': 'list_item', 'content': "Send a POST request to the /resend_verification_email endpoint with an existing user's email and note the HTTP redirect location."}, {'type': 'list_item', 'content': "Send a POST request to the same endpoint with a non-existing user's email and compare the HTTP redirect location."}, {'type': 'paragraph', 'content': 'If the redirects differ (e.g., success page for existing users and failure page for non-existing users), the system is vulnerable to user enumeration.'}, {'type': 'paragraph', 'content': 'Example curl commands to test this behavior:'}, {'type': 'list_item', 'content': "curl -X POST -d '[email protected]' -i https://your-parse-server/resend_verification_email"}, {'type': 'list_item', 'content': "curl -X POST -d '[email protected]' -i https://your-parse-server/resend_verification_email"}, {'type': 'paragraph', 'content': "Compare the 'Location' header in the HTTP 303 redirect responses. Different redirect URLs indicate the vulnerability is present."}] [1, 2, 4]
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability immediately, ensure that your Parse Server is updated to version 8.6.51 or later (or 9.6.0-alpha.40 or later), where the fix has been applied.
Additionally, verify that the configuration option `emailVerifySuccessOnInvalidEmail` is enabled (set to `true`), which is the default setting.
This configuration causes the server to always redirect to the email verification success page regardless of whether the user exists, preventing user enumeration.
If you have previously disabled this option (set it to `false`), re-enable it to suppress error details and avoid leaking user existence information.
If immediate upgrade is not possible, consider implementing network-level controls to restrict access to the resend verification email endpoint to trusted users or IP addresses.