Mar 6, 2026·6 min read·53 visits
Parse Server versions prior to 8.6.6 and 9.5.0-alpha.4 contain a privilege escalation flaw. The `/loginAs` endpoint improperly accepts the `readOnlyMasterKey` for authentication, allowing restricted administrators to generate full session tokens for any user. This bypasses the intended read-only constraints of the key.
A high-severity authorization bypass vulnerability exists in Parse Server's `/loginAs` endpoint. This administrative endpoint, designed to allow user impersonation, failed to strictly enforce scope restrictions on the provided master key. Consequently, an attacker possessing a `readOnlyMasterKey`—intended solely for data inspection—can successfully request a session token for any user, including full administrators. This results in a vertical privilege escalation from read-only access to full read/write capabilities across the entire application.
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 userIdPatched 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 logicThis 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:
/loginAs endpoint.
X-Parse-Master-Key: <attacker_read_only_key>{"userId": "<victim_user_id>"}sessionToken for the victim.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.
Upgrade Instructions:
For npm users:
npm install parse-server@8.6.6Mitigation / 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.
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Parse Server Parse Community | < 8.6.6 | 8.6.6 |
Parse Server Parse Community | < 9.5.0-alpha.4 | 9.5.0-alpha.4 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-863 |
| CVSS v4.0 | 8.5 (High) |
| Attack Vector | Network |
| Privileges Required | High (ReadOnly Master Key) |
| Impact | Privilege Escalation |
| KEV Status | Not Listed |
An uncontrolled resource consumption vulnerability exists in the Scala-based http4s-blaze-server package of the http4s/blaze library. The vulnerability allows remote, unauthenticated attackers to cause an Out of Memory Error (OOM) and JVM crash by streaming a continuous sequence of small or empty WebSocket continuation frames with the FIN bit set to 0. This bypasses typical payload size checks because of the JVM's per-object allocation overhead, leading to rapid heap exhaustion with minimal network bandwidth.
A critical path traversal vulnerability has been identified in the OpenList Go-based backend package. The vulnerability exists within the batch rename handler because the application does not validate the source filename parameter before constructing filesystems paths. This omission allows authenticated users to escape their designated directory and rename files in sibling paths.
OpenList version 4.2.3 and prior is vulnerable to an authorization bypass and metadata leakage. When configured with the Bleve search engine backend, OpenList fails to perform separator-aware path matching when validating tenant containment. This allows authenticated users to access sibling directories sharing similar name prefixes. Furthermore, the search backend returns unfiltered global result counts, leaking existence verification data of unauthorized files via side-channel analysis.
An authorization bypass vulnerability in OpenList version 4.2.3 and below allows authenticated users to read arbitrary files outside of their designated base directories due to an insecure path prefix check using Go's standard strings.HasPrefix function.
A security policy bypass vulnerability exists in the AWS API MCP Server (awslabs-aws-api-mcp-server) from version 0.2.13 through 1.3.46. When the server fails to load the read-only operations index during startup (due to transient network failures, file permission issues, or other exceptions), it logs a warning but continues running in an insecure, degraded state. Under this condition, the security policy engine fails open, silently skipping all subsequent security checks and consent prompts for the lifetime of the process. This permits unauthorized mutating AWS CLI commands to execute via indirect prompt injection attacks.
An incomplete escaping vulnerability in the npm package 'shescape' allows unauthenticated users to trigger dynamic shell expansions, absolute path disclosure, and command block break-outs on Unix and Windows systems.