Parse Server EUVD-2026-113924

Exploitation requires three concrete, confirmed conditions to all hold: (1) the Parse Server option protectedFieldsSaveResponseExempt must be set to false (non-default for this behavior); (2) a beforeSave trigger must write a value beneath a protected field using a dot notation key (writing the complete protected-field value instead avoids the bug - this is the documented workaround); and (3) the attacker must be a client already holding create or update permission on the object (PR:L). Parse Server 8 is not affected because it lacks this option. Exposure is strictly limited to values the trigger writes in the same request. These factors - required privileges, a non-default option setting, and a specific trigger-implementation pattern - sharply limit realistic exploitation despite the network attack vector.

This is a genuinely low-priority issue, and the signals agree rather than conflict. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) scores 2.3, driven down by low confidentiality-only impact (VC:L, with VI/VA/SC/SI/SA all N), a required attack precondition (AT:P), and required privileges (PR:L - the client must already hold create or update permission). The vuln.today decision label is 'monitor', the lowest urgency tier, and the CVE is not listed in CISA KEV. No EPSS score was provided in the input, and no PoC or exploit reference appears among the sources - only the GitHub security advisory (GHSA-6mfr-rv66-x7m3) and a VulnCheck advisory, which are disclosure advisories, not exploit code. The real-world risk is further gated by configuration: exploitation requires the non-default combination of protectedFieldsSaveResponseExempt=false AND a beforeSave trigger that writes beneath a protected field using dot notation, so most deployments are not affected at all. All signals point the same way - this is a low-severity, narrowly-scoped information disclosure, not a high-CVSS-but-overrated issue nor an underrated one; the inputs are internally consistent.

In an affected deployment, an authenticated client holding create or update permission on a class submits a save request for an object; a beforeSave trigger writes a value beneath a protected field using a dot notation key, and the save response returns that trigger-written value to the client even though the field is protected for them. No public exploit code is referenced, and the exposure is limited to values the trigger writes in that same request. The required non-default configuration (protectedFieldsSaveResponseExempt=false plus a dot-notation-writing trigger) makes opportunistic exploitation unlikely.