Parse Server EUVD-2026-36542

Exploitation requires only the standard public Parse API credentials (X-Parse-Application-Id and X-Parse-REST-API-Key) that are distributed to all clients of a Parse-backed application - no user session token, master key, or Cloud Code invocation is needed. The attacker must additionally know or enumerate the objectId of the owning parent object; Parse objectIds are 10-character alphanumeric strings that may be obtainable through other API queries, exposed in URLs, or brute-forced. The vulnerability is specifically triggered when either (a) the target relation field is listed in protectedFields for the requesting client role, or (b) the parent object's ACL or CLP denies read access to the public. Deployments where all relation fields are intentionally public and no sensitive membership data is stored in Relation fields are not meaningfully impacted. Exploitation does not require any non-default Parse Server configuration, special network positioning, or privileged access beyond what every Parse client already holds.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N) confirms network-reachable, zero-complexity, unauthenticated exploitation with limited confidentiality impact and no integrity or availability impact, yielding a score of 6.9. The EPSS score of 0.08% (23rd percentile) indicates low probability of opportunistic automated exploitation in the near term, and there is no CISA KEV listing, meaning active exploitation has not been confirmed. These signals suggest the vulnerability is not currently being mass-exploited. However, real-world impact is strongly application-dependent: deployments that use protectedFields or object ACLs to conceal sensitive relationship data face meaningful targeted disclosure risk that the low CVSS confidentiality sub-score understates. The oracle attack pattern - confirming membership of a specific object in a private relation with a single API call - enables targeted intelligence gathering rather than mass exploitation, which is consistent with the low EPSS despite the sensitivity of the exposed data. No conflicts between available data sources were identified; all signals are internally consistent.

An attacker extracts the Parse Application ID and REST API Key from a mobile or web client - these credentials are embedded in every Parse application by design. The attacker then guesses or obtains the objectId of a private parent object (e.g., a group or user record with a restricted ACL) and issues a GET request to /classes/RelChild with a where clause containing a $relatedTo operator referencing that objectId and the name of a protected relation field. Prior to the patch, Parse Server returns the list of linked child objects in full, disclosing private group membership or block list contents without any authentication beyond the public API credentials.