Parse Server EUVD-2026-109423

Exploitation requires that the deployment enables Parse Server's built-in SMS multi-factor authentication adapter AND that the attacker's account is enrolled in SMS MFA; the attacker must be authenticated as that account. The trigger is the SMS MFA verification-code request, into which the user injects additional account fields that Parse Server then saves with master privileges. Limiting factors: the vendor states there is no configuration workaround (only upgrading fully fixes it), deployments that do not enable SMS-based MFA are entirely unaffected, and the impact is confined to the requester's own account - other users' data cannot be modified.

This is a genuinely low-priority issue, and the signals agree. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N) yields a base score of only 2.1, and the only impact metric set is VI:L - low integrity impact with no confidentiality (VC:N) or availability (VA:N) consequence, and no subsequent-system impact (SC/SI/SA:N). The vuln.today decision label is 'monitor', not act_now or emergency, which is consistent with the low score. No KEV listing is present (not confirmed actively exploited), no EPSS probability is supplied in the input, and the references are advisories rather than exploit code, so there is no public exploit identified at time of analysis. The practical ceiling on damage is narrow: an authenticated, SMS-MFA-enrolled user can only alter master-key-restricted fields on their OWN account (e.g., flip the email-verification flag or write beforeSave-protected values); the advisory explicitly states other users' data cannot be modified. The AT:P (attack requirement present) metric reflects that only deployments running the built-in SMS MFA adapter, and only accounts enrolled in SMS MFA, are affected. No conflicting signals were observed; the chief caveat is that EPSS and any independent telemetry are absent from the provided data.

An attacker who already controls an SMS-MFA-enrolled Parse Server account initiates a login, and in the verification-code request they append extra account fields (such as the email-verification flag or values normally guarded by a beforeSave trigger). Because Parse Server persists the entire login request with master privileges at that step, the injected fields are written to the attacker's own account, bypassing the client-level write restrictions. No public exploit code was identified in the supplied data; exploitation is confined to the requester's own account.