Parse Server EUVD-2026-97605

Requires an authenticated user (PR:L) who already has read access to the object that owns a Relation field protected by identity-scoped protectedFields (authenticated, role, or per-user group rules). The attacker must craft a count query using the $relatedTo operator with an objectId constraint; the missing protectedFields enforcement on this specific count path is what leaks data. Exploitation is LIMITED to disclosing membership/size of protected Relation fields - it cannot read the underlying field contents, modify data, or affect availability - and is confined to Parse Server versions before 8.6.93 and the 9.0.0 line before 9.10.1-alpha.13. The practical impact depends on whether relation membership (e.g., private group or block-list membership) is itself confidential in the deployment.

This is a genuine but modest-severity information-disclosure issue rather than a top-tier priority. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) scores 5.3 (Medium) and is internally consistent with the description: network-reachable, low complexity, but requiring authentication (PR:L) and yielding only low confidentiality impact with no integrity or availability effect. No EPSS score, KEV listing, POC, or SSVC decision data was provided, so exploitation-probability and automatability signals are absent - this is an authorization flaw (CWE-639) disclosing the size/membership of protected Relation fields, not a code-execution or full-data-exposure bug. The limited impact scope (an attacker learns whether a specific objectId is a member of a protected relation, acting as a membership oracle) means real-world risk is concentrated in deployments where relation membership itself is confidential (private groups, block lists). Because PR:L is explicitly present, exploitation is by authenticated users only. No signal here suggests widespread opportunistic exploitation; treat as a routine-priority patch, prioritized higher only where membership confidentiality is a core security property.

An authenticated low-privilege user who can read an object issues a count query using the $relatedTo operator combined with an objectId constraint against a protectedFields-restricted Relation. Because identity-scoped protectedFields are not enforced on these count queries, the returned count (0 or 1 for a specific objectId) acts as a membership oracle, revealing whether a given user belongs to a private group or block list. No public exploit identified at time of analysis.