Parse Server EUVD-2026-101737

Requires the Parse Server email verification and/or password-reset features to be configured and enabled (these endpoints must exist and dispatch mail). Exploitation also requires that the configured mail/SMTP provider reject, rate-limit, or be unavailable when the email is sent - the AT:P attack requirement - a state an attacker can induce by rapidly issuing many requests to trigger provider rate-limiting. Only public application keys are needed (no user account or authentication), and affected versions are Parse Server before 8.6.97 and the 9.0.0 line before 9.10.2-alpha.6. Deployments with email flows disabled, or on patched versions that catch the send error, are not affected.

This is a genuine, easily-triggered availability risk rather than an inflated high-CVSS score. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VA:H) correctly captures a network-reachable, unauthenticated denial-of-service with no confidentiality or integrity impact - a full process crash (CWE-248, uncaught exception). The one signal tempering raw severity is AT:P (attack requirement 'Present'): exploitation depends on the mail provider rejecting, rate-limiting, or being unavailable at request time, which the description confirms. However, an attacker can realistically force this condition simply by flooding verification/reset requests until the provider rate-limits, making the 'requirement' largely attacker-controllable and the 8.2 rating credible. No EPSS score, CISA KEV listing, or public POC is present in the supplied data, so exploitation status is 'no public exploit identified at time of analysis' - this is not confirmed active exploitation. Net: a real patching priority for exposed Parse Server deployments with email flows enabled, but DoS-only (no data compromise) and no evidence of in-the-wild use.

An attacker possessing only the public Parse application keys (no account required) repeatedly calls the sign-up, email-verification, or password-reset endpoints. Because Parse Server does not catch errors thrown while dispatching the email, a single rejection, rate-limit, or outage from the mail provider raises an unhandled exception that terminates the Node.js process. No public exploit code is referenced, but the attack requires no special tooling.