Parse Server EUVD-2026-104575

The attacker must already be an authenticated Parse Server user OR possess a valid existing session token for the target account (PR:L) - there is no path to unauthenticated exploitation. The flaw is triggered against default behavior because Parse Server fails to enforce the 'create' and 'addField' class-level permissions on the built-in _Session class, so no non-default configuration is required on the victim side; any deployment running an affected version is exposed to authenticated/token-holding abuse. The key limiting factors are: (1) prior possession of a valid session token, and (2) impact confined to session integrity (persistent/unrevoked sessions and _Session schema modification), with no confidentiality or availability consequence, which is why realistic risk is low despite the network attack vector.

This is a genuinely low-priority issue, and the signals are consistent in saying so. The CVSS 4.0 base score is 2.3 (Low), with a vector of AV:N/AC:L/AT:P/PR:L/UI:N and impact limited to VI:L (low integrity, no confidentiality or availability impact). The AT:P (attack requirements present) and PR:L (low privileges required) metrics confirm the attacker must already be an authenticated Parse Server user or already possess that user's valid session token - this is a post-authentication authorization weakness (CWE-863), not a pre-auth bypass. No EPSS score, KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The one point of tension worth flagging: the input Tags label this 'Authentication Bypass,' but the CWE-863 (Incorrect Authorization) classification and the description - which describes bypassing class-level permissions on _Session, not bypassing login - indicate this is an authorization/permission-enforcement flaw, not an authentication bypass; the label overstates the nature of the issue. Net: real but minor, suitable for routine patching rather than emergency response.

An attacker who has compromised or legitimately holds a user's Parse Server session token sends POST requests to /sessions or /classes/_Session to mint additional session objects for that account and add arbitrary fields to the _Session class. Because these attacker-created sessions are not revoked when the original session logs out, the attacker retains persistent authenticated access to the account even after the victim believes they have ended their session. No public exploit code is identified at time of analysis, but exploitation requires only standard authenticated API calls and no special tooling.