Parse Server CVE-2026-119571

Exploitation requires a Parse Server deployment on versions 9.7.0 up to (but not including) 9.10.5-alpha.10 that has explicitly enabled the protectedFieldsTriggerExempt option (disabled by default) AND defines a beforeSave trigger on the _Installation class; both must be present. The attacker must also already know the object ID of a target _Installation object they cannot otherwise access, and crafts an update addressed by that object ID while sending a different X-Parse-Installation-Id header (or _InstallationId). Limiting factors: the vulnerability does not exist in default configurations, does not affect Parse Server 8 or versions before 9.7.0, and yields only confidentiality exposure of another installation's protected fields to the trigger (no write to the targeted object, no integrity/availability impact). The complete fix is upgrading to 9.10.5-alpha.10; workarounds are to disable protectedFieldsTriggerExempt or avoid using a beforeSave installation trigger to handle data the client cannot read.

This is a medium-severity authorization flaw (CVSS 4.0 base 6.3, CWE-639 IDOR), and the real-world risk is substantially narrower than a network-exploitable score might suggest. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) marks AT:P - an attack requirement - which corresponds directly to the non-default preconditions the advisory describes: the deployment must enable protectedFieldsTriggerExempt (disabled by default) AND use a beforeSave trigger on the _Installation class, and the attacker must already know another installation's object ID. Impact is confidentiality-only and limited (VC:L; VI:N/VA:N) - a beforeSave trigger processes another installation's protected fields, with no integrity or availability effect and no scope change. The vuln.today decision label is 'this_month' (not act_now/emergency). There is no CISA KEV listing and no EPSS value supplied; no public exploit is referenced. Per the PR:N in the vendor vector the request itself needs no authenticated session, but exploitation is gated by operator configuration and knowledge of a target object ID, so this is a conditional, config-dependent issue rather than a broad unauthenticated-takeover priority. Patch during a normal cycle; it is not a drop-everything emergency, but deployments that actually enable protectedFieldsTriggerExempt with an installation beforeSave trigger should prioritize it.

On a Parse Server deployment (9.7.0 to before 9.10.5-alpha.10) that has enabled protectedFieldsTriggerExempt and runs a beforeSave trigger on the _Installation class, an attacker who has learned the object ID of an installation they cannot otherwise read sends an _Installation update addressed to that object ID while supplying their own X-Parse-Installation-Id (or _InstallationId). The server misdirects the write to the installation named by the header, but the beforeSave trigger receives the full stored data - including protected fields - of the addressed installation, exposing fields the client is not permitted to read. No public exploit is identified at time of analysis; the attack requires the specific non-default configuration and prior knowledge of the target object ID.