Mar 24, 2026·6 min read·3 visits
Parse Server leaks raw MFA secrets (TOTP seeds, recovery codes) via the `/users/me` endpoint due to an over-privileged Master Key query. Updating to versions 8.6.61 or 9.6.0-alpha.55 mitigates the issue.
Parse Server versions prior to 8.6.61 and 9.6.0-alpha.55 suffer from an information disclosure vulnerability (CWE-200) in the `/users/me` endpoint. The server retrieves user objects using the Master Key context, bypassing security filters and exposing raw Multi-Factor Authentication (MFA) secrets and recovery codes to authenticated users.
Parse Server provides a /users/me endpoint to allow authenticated users to retrieve their own account information. Versions prior to 8.6.61 and 9.6.0-alpha.55 contain a sensitive information disclosure vulnerability within this endpoint. The flaw is classified as CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.
The vulnerability allows an authenticated user to extract sensitive Multi-Factor Authentication (MFA) credentials associated with their account. This data includes raw Time-Based One-Time Password (TOTP) seeds and recovery codes. The exposure occurs due to an architectural flaw in how the endpoint queries the backend database for user objects.
An attacker who obtains a valid session token can exploit this vulnerability to achieve persistent access to the target account. By extracting the TOTP seed, the attacker can independently generate valid MFA tokens, nullifying the security guarantees of the Parse Server MFA implementation.
The root cause lies in an insecure data retrieval pattern within the handleMe function of the UsersRouter.js module. When processing a GET /users/me request, the server must validate the provided session token and return the associated user data. Vulnerable versions execute this database query using the Master Key context via Auth.master().
The Master Key in Parse Server operates as a superuser override. Queries executed under this context bypass all internal security layers, including Class-Level Permissions (CLPs) and field-level visibility restrictions. Furthermore, this context bypasses authentication adapter sanitization, which normally strips secrets from the authData field before returning the object to the client.
To optimize database operations, the vulnerable implementation used a single query against the _Session collection with an { include: 'user' } parameter. Because the primary query utilized the Master Key, the included _User object was also retrieved with superuser privileges. This resulted in the complete, unsanitized user record being returned directly to the client endpoint.
The architectural flaw is clearly visible when comparing the handleMe function before and after the patch. In the vulnerable implementation, the rest.find method is invoked with Auth.master(req.config) and the { include: 'user' } directive. This single-query approach forces the user data retrieval to inherit the Master Key privileges of the session validation step.
handleMe(req) {
const sessionToken = req.info.sessionToken;
return rest.find(
req.config,
Auth.master(req.config), // Querying as Master
'_Session',
{ sessionToken },
{ include: 'user' }, // Including user data in master query
...
).then(response => {
const user = response.results[0].user; // Raw, unsanitized user data
return { response: user };
});
}The patch resolves the privilege escalation by decoupling session validation from user data retrieval. The modified function performs two distinct queries. First, it queries the _Session collection with the Master Key to validate the token, but omits the include directive to prevent fetching the user record.
async handleMe(req) {
const sessionToken = req.info.sessionToken;
// Step 1: Validate session with Master Key, no 'include'
const sessionResponse = await rest.find(req.config, Auth.master(req.config), '_Session', { sessionToken }, {}, ...);
const userId = sessionResponse.results[0].user.objectId;
// Step 2: Fetch user with the user's OWN auth context
const userResponse = await rest.get(req.config, req.auth, '_User', userId, {}, ...);
const user = userResponse.results[0]; // Correctly sanitized data
return { response: user };
}The second query retrieves the _User object using req.auth, which represents the caller's actual authentication context. This ensures the Parse Server engine correctly applies all standard security filters, CLPs, and adapter sanitization logic before returning the payload.
Exploitation requires the attacker to possess a valid session token for a target account. The attacker issues a standard HTTP GET request to the /users/me endpoint, passing the session token in the X-Parse-Session-Token header. The server responds with a JSON object containing the unsanitized authData field.
The extracted payload contains the secret key, which is the base32-encoded TOTP seed, and an array of recovery codes. The attacker inputs the base32 seed into any standard authenticator application. This grants the attacker the ability to generate valid time-based tokens indefinitely, persisting access even if the original session token is revoked.
The official test suite provides a functional Proof-of-Concept for this vulnerability. The code configures the server with MFA enabled, generates a target user, and demonstrates the data leakage via the REST API.
// Snippet from spec/vulnerabilities.spec.js
const response = await request({
headers: { 'X-Parse-Session-Token': sessionToken },
method: 'GET',
url: 'http://localhost:8378/1/users/me',
});
// response.data.authData.mfa.secret exposes the TOTP seedThe vulnerability carries a CVSS 4.0 base score of 7.1 (High), characterized by the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. The attack vector is network-based and requires low privileges (a standard authenticated session). No user interaction is required beyond the attacker's own actions.
The security impact is entirely confined to confidentiality loss. An attacker successfully exploiting this flaw gains unauthorized read access to highly sensitive cryptographic material used for authentication. Neither the availability of the Parse Server nor the integrity of the database is directly impacted by the data exposure itself.
While no weaponized exploit tools are currently documented in public databases, the exploitation technique is trivial. Attackers can leverage standard HTTP clients like curl or Postman to extract the MFA seeds. Threat actors who obtain session tokens via cross-site scripting (XSS) or other token-stealing mechanisms can use this flaw to permanently compromise the MFA layer of the affected accounts.
The primary remediation strategy requires upgrading the Parse Server dependency to a patched release. Organizations operating Parse Server version 8.x must upgrade to version 8.6.61. Organizations on the 9.x release track must upgrade to version 9.6.0-alpha.55 or later.
Administrators who cannot immediately deploy the patch can implement interim mitigations. One approach involves temporarily disabling the MFA feature within the Parse Server configuration. Alternatively, developers can implement a custom middleware layer to intercept responses from the /users/me endpoint and manually strip the authData object before the payload reaches the client.
Security teams should proactively monitor access logs for anomalous activity targeting the /users/me endpoint. A high volume of requests to this endpoint, particularly if followed by MFA configuration modifications or unusual login patterns, indicates potential exploitation attempts. Custom detection templates can be authored to verify if production endpoints are leaking the secret or recovery keys in the JSON response.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Parse Server Parse Community | < 8.6.61 | 8.6.61 |
Parse Server Parse Community | >= 9.0.0, < 9.6.0-alpha.55 | 9.6.0-alpha.55 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-200 |
| Attack Vector | Network |
| CVSS Score | 7.1 |
| Impact | Confidentiality (High) |
| Exploit Status | Proof of Concept |
| Privileges Required | Low |
Exposure of Sensitive Information to an Unauthorized Actor