Parse Server EUVD-2026-104574

Username and email confirmation requires no special conditions - a remote caller with or without a session can trigger the oracle against default Parse Server deployments via the user-update API (consistent with PR:N). The password-confirmation and previous-password-confirmation capability is gated: it only applies when the server is configured with passwordPolicy.maxPasswordHistory or with doNotAllowUsername enabled. Limiting factors for defenders: the flaw yields confirmation/enumeration of guessed values rather than direct credential theft or code execution, and the strongest impact (password validation) depends on those non-default password-policy settings being active; however, the account-lockout bypass removes a key brute-force defense, so rate-limiting and monitoring remain relevant.

This is a medium-severity (CVSS 4.0 base 6.9) improper-authorization flaw (CWE-863) in Parse Server where account checks are evaluated before the caller is authorized and the result is reflected in the response. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N) is internally consistent with the description: network-reachable, low complexity, no privileges (PR:N confirms unauthorized/unauthenticated exploitation), no user interaction, and only Low confidentiality impact with no integrity or availability impact - appropriate because the bug leaks oracle information (valid usernames/emails, and under specific configs, current/previous passwords) rather than granting code execution or data modification. No EPSS score, no CISA KEV listing, and no public exploit (POC) were provided in the input, so there is no public exploit identified at time of analysis. The practical risk is moderate: the vulnerability is a reliable enumeration and lockout-bypass oracle that materially aids credential-stuffing and targeted account-takeover campaigns, but it is not itself a full compromise, which aligns with the Low confidentiality rating rather than the High-CVSS/critical tier. Missing signals to note explicitly: no EPSS probability was supplied so exploitation likelihood cannot be quantified, and no SSVC decision data (automatable, technical impact) was provided - the enumeration behavior is plausibly automatable, but this is inferred, not confirmed.

A remote attacker with no account sends crafted user-update requests to a Parse Server instance and observes the differing responses to confirm which guessed usernames or email addresses are valid. Where the server enforces passwordPolicy.maxPasswordHistory or doNotAllowUsername, the attacker extends the same oracle to validate guessed current or previous passwords while sidestepping account-lockout protections, enabling efficient credential-stuffing against discovered accounts. No public exploit code was identified in the provided data, but the technique requires only standard HTTP API calls and low attack complexity.