### 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.
### 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.
Update parse-server to 9.9.1-alpha.5 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanparse-server: Endpoints `/login` and `/verifyPassword` disclose MFA secrets and protected fields when `_User` get is denied affects parse-server (npm). Severity is medium. ### 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.
AI coding agents often install or upgrade packages automatically in npm. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| parse-servernpm | >=9.8.0,<9.9.1-alpha.5 | 9.9.1-alpha.5 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate parse-server to 9.9.1-alpha.5 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanparse-server: Endpoints `/login` and `/verifyPassword` disclose MFA secrets and protected fields when `_User` get is denied affects parse-server (npm). Severity is medium. ### 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.
AI coding agents often install or upgrade packages automatically in npm. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| parse-servernpm | >=9.8.0,<9.9.1-alpha.5 | 9.9.1-alpha.5 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard