Impact
Apps that enable MFA and deny get on the _User class via Class-Level Permissions could expose sensitive user data through the /login and /verifyPassword endpoints.
These endpoints re-fetch the user through the access-controlled query pipeline (CLP, protectedFields, auth-adapter sanitizers) before responding. When that re-fetch was denied by the _User get permission, the server fell back to the raw database row, exposing raw authData (including MFA TOTP secrets and recovery codes) and fields hidden by protectedFields (when protectedFieldsOwnerExempt is false).
/verifyPassword is the most severe: with only a username and password (no session or MFA token), an attacker who knows a victim's password could retrieve their MFA secret and recovery codes, defeating the second factor.
Only Parse Server 9.8.0 and later are affected; 8.x and earlier are not. Master and maintenance key requests are unaffected, as they bypass these controls by design.
Patches
On a denied re-fetch, /login and /verifyPassword no longer fall back to the raw row; they return only the user's identity (plus the session token for /login). Master and maintenance key callers still receive the full record.
Workarounds
None that preserve the intended _User get restriction. Upgrade to a patched version.
References
Impact
Apps that enable MFA and deny
geton the_Userclass via Class-Level Permissions could expose sensitive user data through the/loginand/verifyPasswordendpoints.These endpoints re-fetch the user through the access-controlled query pipeline (CLP,
protectedFields, auth-adapter sanitizers) before responding. When that re-fetch was denied by the_Usergetpermission, the server fell back to the raw database row, exposing rawauthData(including MFA TOTP secrets and recovery codes) and fields hidden byprotectedFields(whenprotectedFieldsOwnerExemptisfalse)./verifyPasswordis the most severe: with only a username and password (no session or MFA token), an attacker who knows a victim's password could retrieve their MFA secret and recovery codes, defeating the second factor.Only Parse Server 9.8.0 and later are affected; 8.x and earlier are not. Master and maintenance key requests are unaffected, as they bypass these controls by design.
Patches
On a denied re-fetch,
/loginand/verifyPasswordno longer fall back to the raw row; they return only the user's identity (plus the session token for/login). Master and maintenance key callers still receive the full record.Workarounds
None that preserve the intended
_Usergetrestriction. Upgrade to a patched version.References