Vulnerability Summary

Field	Details
CVE ID	CVE-2026-30229
Product	Parse Server
Vendor	Parse Community
Vulnerability Type	Privilege Escalation / Authorization Bypass
CWE	CWE-863 – Incorrect Authorization
CVSS Score	8.5
Severity	High
Attack Vector	Network
Attack Complexity	Low
Privileges Required	High (requires readOnlyMasterKey)
User Interaction	None
Confidentiality Impact	High
Integrity Impact	High
Availability Impact	Low
Exploitability	Moderate
Exploit Availability	No confirmed public exploit release
EPSS Probability	~1.3%
Affected Versions	Parse Server < 8.6.6 and 9.x < 9.5.0-alpha.4
Patched Versions	8.6.6 and 9.5.0-alpha.4
Vulnerable Component	/loginAs endpoint in user authentication router

A privilege escalation vulnerability has been identified in Parse Server where the readOnlyMasterKey can be used to impersonate any user through the /loginAs endpoint. This occurs because the authorization logic fails to differentiate between the full master key and the read-only master key, allowing the restricted credential to execute privileged operations.

---

Overview

Parse Server is commonly used as a backend service for mobile and web applications. It manages user accounts, authentication, session tokens, and database access. In most deployments, administrative operations are protected through privileged keys such as the masterKey, while the readOnlyMasterKey is intended only for safe read access to data.

In affected versions, a flaw exists in the user authentication router where requests authenticated using the read-only master key are incorrectly treated as if they were authenticated using the full master key. This allows restricted credentials to invoke administrative functionality.

As a result, a request sent to the /loginAs endpoint can generate a valid session token for any user account when the readOnlyMasterKey is supplied. Once the session token is issued, the attacker effectively gains the privileges of the targeted account and can perform any actions allowed for that user.

---

Technical Details

The vulnerability originates from insufficient authorization checks inside the user routing logic responsible for handling login impersonation. The /loginAs endpoint is designed for administrative troubleshooting, allowing administrators to authenticate as a specific user.

The vulnerable logic checks whether a request is authenticated using a master-level key but fails to verify whether the key is marked as read-only. Because of this oversight, a restricted key is mistakenly accepted as a privileged key.

Internally, the vulnerable function responsible for processing the request does not block requests where the authentication context contains isReadOnly = true. Consequently, the application allows session generation even though the key should only allow read operations.

Once the request is processed successfully, a valid session token is created and returned in the API response. That token can then be used in further API requests as if the attacker had logged in legitimately.

---

Root Cause Analysis

The issue can be attributed to improper authorization validation in the user impersonation handler.

Specifically:

• Requests authenticated with readOnlyMasterKey were not filtered.
• The authorization logic only checked whether the request used a master-type key.
• The distinction between full administrative privileges and read-only privileges was not enforced.

Because the impersonation endpoint generates a valid authentication session, misuse of this endpoint effectively results in privilege escalation and full account takeover.

---

Affected Environments

Systems most likely to be impacted include:

• Parse Server deployments used as backend APIs
• Mobile application backends using Parse
• SaaS platforms using Parse for user management
• Cloud-hosted Parse deployments exposed to the internet

The vulnerability becomes exploitable when:

• The readOnlyMasterKey is enabled
• The key is exposed or leaked
• The Parse API is accessible remotely

---

Exploitation Scenario

A realistic attack chain may unfold in the following sequence:

1. The read-only master key becomes exposed through configuration leaks, environment variables, or compromised infrastructure.
2. An attacker sends an API request to the Parse Server /loginAs endpoint.
3. The request contains the read-only master key along with a target user identifier.
4. The server accepts the request because it incorrectly treats the key as privileged.
5. A session token is returned in the response.
6. The attacker uses the session token to perform operations as the targeted user.

If a privileged account such as an administrator is impersonated, full application control may be achieved.

---

Proof of Concept (Educational Use Only)

The following example demonstrates how a request may be crafted to exploit the vulnerability.

POST /parse/loginAs HTTP/1.1
Host: vulnerable-server.example
Content-Type: application/json
X-Parse-Application-Id: APP_ID
X-Parse-Read-Only-Master-Key: READ_ONLY_MASTER_KEY{
  "userId": "target_user_id"
}

Successful exploitation may result in a response containing a valid session token.

{
  "objectId": "session_id",
  "sessionToken": "generated_session_token",
  "user": {
     "objectId": "target_user_id"
  }
}

This token can then be used in further requests:

X-Parse-Session-Token: generated_session_token

---

Indicators of Compromise

The following behaviors may indicate exploitation attempts:

• Requests to /loginAs originating from unexpected IP addresses
• Session creation events for multiple users in a short period
• API calls using readOnlyMasterKey instead of masterKey
• Repeated impersonation attempts targeting administrative accounts
• Abnormal spikes in authentication or session generation logs

---

Detection

Web Server Log Monitoring

Monitoring should focus on POST requests to the impersonation endpoint.

Suspicious pattern:

POST /parse/loginAs

Particular attention should be given when the following header appears:

X-Parse-Read-Only-Master-Key

---

Application Log Detection

Parse application logs may contain indicators of session generation events linked to impersonation requests.

Example suspicious log pattern:

endpoint=/loginAs
auth_method=readOnlyMasterKey
action=session_creation

---

Detection Rules

Splunk Query

index=web_logs
method=POST
uri_path="/loginAs"
| search headers="readOnlyMasterKey"
| stats count by src_ip, user_agent

---

Elastic / KQL Query

http.request.method : "POST" and
url.path : "/loginAs" and
http.request.headers : "*readOnlyMasterKey*"

---

WAF Detection Rule

SecRule REQUEST_METHOD "POST" "id:30229,phase:2,deny,status:403,msg:'Parse loginAs abuse attempt'"
SecRule REQUEST_URI "@contains /loginAs"
SecRule REQUEST_HEADERS "@contains readOnlyMasterKey"

---

Suricata IDS Rule

alert http any any -> any any (
msg:"Possible Parse Server loginAs privilege escalation attempt";
flow:to_server,established;
content:"POST"; http_method;
content:"/loginAs"; http_uri;
content:"readOnlyMasterKey"; http_header;
sid:30229;
rev:1;
)

---

Log Sources

Detection and investigation may rely on the following telemetry sources:

Application Logs
Parse Server runtime logs
Node.js application logs

Web Server Logs
Nginx access logs
Apache access logs

Security Monitoring Logs
Web Application Firewall logs
API gateway logs

Infrastructure Logs
Container runtime logs
Kubernetes audit logs
Reverse proxy logs

---

MITRE ATT&CK Mapping

Tactic	Technique
Initial Access	T1078 – Valid Accounts
Privilege Escalation	T1068 – Exploitation for Privilege Escalation
Credential Access	T1552 – Unsecured Credentials
Persistence	T1098 – Account Manipulation
Collection	T1213 – Data from Information Repositories

---

Impact

If the vulnerability is exploited successfully, several consequences may occur:

• Unauthorized access to user accounts
• Exposure of sensitive application data
• Manipulation or deletion of stored information
• Impersonation of administrators
• Unauthorized modification of application configuration

Because Parse Server is often deployed as a centralized backend, exploitation may affect all application users simultaneously, resulting in widespread data exposure or integrity compromise.

---

Mitigation

The following defensive measures are recommended:

1. Upgrade Parse Server to a patched version immediately.
2. Rotate both master keys and read-only keys.
3. Restrict network access to backend APIs.
4. Monitor impersonation endpoints for unusual activity.
5. Store backend keys securely using a secret management system.
6. Disable unused administrative features such as user impersonation when not required.

---

Official Patch / Upgrade

Upgrade Parse Server to the patched versions:

https://github.com/parse-community/parse-server/releases/tag/8.6.6

---