CVE-2026-30229: Privilege Escalation via Read-Only Master Key in Parse Server

Parse Server is a widely used open-source backend framework that provides database management, authentication, and API generation. The framework supports two tiers of administrative keys: the standard masterKey (full access) and the readOnlyMasterKey (inspection-only access). The vulnerability resides in the /loginAs endpoint, a utility function located in the UsersRouter class. This endpoint allows administrators to generate a valid session token for a specific user ID without knowing that user's password, facilitating support and debugging operations.

The core issue is a failure in authorization logic (CWE-863). While the endpoint correctly requires a master-level key for access, it did not distinguish between the read-write masterKey and the readOnlyMasterKey. Prior to the fix, the server accepted the read-only key as valid authorization for this operation. This oversight allows an entity with restricted, read-only administrative access to generate a session token for any user in the system. Once the attacker obtains this session token, they can authenticate as that user and perform write operations, effectively bypassing the restrictions placed on their original credential.

The root cause of this vulnerability lies in the implementation of the handleLoginAs method within src/Routers/UsersRouter.js. Parse Server's request handling pipeline populates the req.auth object with metadata about the authentication used for the request, including flags such as isMaster (indicating if a master key was used) and isReadOnly (indicating if that master key is read-only).

In the vulnerable versions, the /loginAs endpoint verified that the request was made by a master-level entity but failed to check the isReadOnly flag. The authorization logic implicitly trusted that if the request was authenticated via a master key mechanism, the operation should proceed. Because the readOnlyMasterKey is technically a master-level credential—albeit one with restricted scope—it satisfied the baseline check.

This is a logic error where the specific constraints of the readOnlyMasterKey were not enforced at the endpoint level. The framework relies on individual endpoints to reject read-only keys for state-changing operations. Since /loginAs generates a new session (a state change that leads to further state changes), it should have explicitly forbidden the use of read-only credentials.

The following analysis examines the patch applied in src/Routers/UsersRouter.js. The fix explicitly checks the req.auth.isReadOnly property and throws a OPERATION_FORBIDDEN error if the flag is true.

Vulnerable Code (Before Patch):

The code validates the user ID but proceeds directly to token generation if a master key (of any type) is present.

// src/Routers/UsersRouter.js
 
// [..] Previous logic validating Master Key presence generally
 
const userId = req.body?.userId || req.query.userId;
if (!userId) {
  throw createSanitizedError(
    Parse.Error.OBJECT_NOT_FOUND,
    'Missing userId',
    req.config
  );
}
// Proceed to generate session for userId

Patched Code (After Patch):

The fix introduces a guard clause immediately before processing the userId. This ensures that even if the request passes the general master key check, it is rejected if the key is read-only.

// src/Routers/UsersRouter.js
 
// Added security check
if (req.auth.isReadOnly) {
  throw createSanitizedError(
    Parse.Error.OPERATION_FORBIDDEN,
    "read-only masterKey isn't allowed to login as another user.",
    req.config
  );
}
 
const userId = req.body?.userId || req.query.userId;
// [..] Existing logic

This change ensures that the semantic meaning of "Read Only" is preserved: a read-only key cannot be used to generate credentials (session tokens) that would allow write access.

To exploit this vulnerability, an attacker requires possession of the readOnlyMasterKey. This key is often distributed to support staff, monitoring systems, or junior administrators who are not intended to have modification rights. The attack does not require interaction with the target user.

Attack Flow:

1. Target Identification: The attacker selects a victim user ID (e.g., a system administrator's ID).
2. Request Construction: The attacker constructs a POST request to the /loginAs endpoint.
   • Header: X-Parse-Master-Key: <attacker_read_only_key>
   • Body: {"userId": "<victim_user_id>"}
3. Privilege Escalation: The server processes the request, fails to reject the read-only key, and returns a JSON response containing a sessionToken for the victim.
4. Impersonation: The attacker uses the returned sessionToken in the X-Parse-Session-Token header for subsequent requests. They now possess all privileges associated with the victim account, allowing them to create, update, or delete data.

The following diagram illustrates the successful attack path on a vulnerable system:

The impact of CVE-2026-30229 is rated as High (CVSS 8.5) due to the complete bypass of role-based access controls for holders of the read-only key.

Confidentiality Impact (High): By generating a session token for any user, the attacker can access private data belonging to that user which might otherwise be protected by Class Level Permissions (CLPs) or Access Control Lists (ACLs) that even the read-only master key might not inherently bypass in standard queries (depending on specific configuration), or simply to act as that user within the application logic.

Integrity Impact (High): The most critical aspect is the conversion of read-only access into write access. A read-only administrator can impersonate a full administrator and modify application data, delete users, or change configurations.

Privileges Required: The attack is not available to unauthenticated public users; it requires the readOnlyMasterKey. However, in many organizations, this key is less tightly guarded than the primary masterKey, increasing the likelihood of internal threats or leakage.

The vulnerability is addressed in the following Parse Server versions. Administrators should upgrade immediately.

• Version 8.x: Fixed in version 8.6.6.
• Version 9.x: Fixed in version 9.5.0-alpha.4.

Upgrade Instructions:

For npm users:

npm install parse-server@8.6.6

Mitigation / Workarounds:

If an immediate upgrade is not feasible, the primary mitigation is to revoke or disable the readOnlyMasterKey. If the key is not in use, remove it from the server configuration. If it is in use, restricting network access to the Parse Server admin endpoints (e.g., via firewall rules or load balancer configurations blocking /loginAs) can limit exposure, though path-based blocking can be error-prone.