CVE-2026-30966: Parse Server Auth Bypass Vulnerability

CVE-2026-30966 Overview

Parse Server, an open source backend that can be deployed to any infrastructure capable of running Node.js, contains a critical broken access control vulnerability in versions prior to 9.5.2-alpha.7 and 8.6.20. The vulnerability allows unauthorized access to internal tables that store Relation field mappings, including role memberships. These internal tables can be directly accessed via the REST API or GraphQL API using only the application key—no master key is required.

Critical Impact
Attackers can create, read, update, or delete records in any internal relationship table, enabling them to inject themselves into any Parse Role and gain full read, write, and delete access to classes protected by role-based Class-Level Permissions (CLP).

Affected Products

parseplatform parse-server versions prior to 8.6.20
parseplatform parse-server versions 9.5.2-alpha1 through 9.5.2-alpha6
parseplatform parse-server versions prior to 9.5.2-alpha.7

Discovery Timeline

2026-03-10 - CVE CVE-2026-30966 published to NVD
2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-30966

Vulnerability Analysis

This vulnerability is classified as Broken Access Control (CWE-284) affecting Parse Server's internal database tables. The flaw exists in how Parse Server handles authentication and authorization for its internal tables that manage Relation field mappings. These internal tables are critical security components as they store role memberships and other relationship data that drive the platform's access control mechanisms.

The vulnerability allows any client with knowledge of the application key to directly manipulate these internal tables without requiring the master key. This fundamentally breaks the security model of Parse Server, as the master key is intended to be the only credential capable of bypassing access controls for administrative operations.

Root Cause

The root cause is insufficient access control enforcement on internal relationship tables. Parse Server fails to properly validate that requests to internal tables originate from authorized administrative contexts. The authentication check only verifies the presence of an application key rather than requiring the master key for operations on sensitive internal tables that control role memberships and relation field mappings.

Attack Vector

The attack can be executed remotely over the network without requiring user interaction. An attacker needs only the application key, which is typically embedded in client-side applications and easily discoverable through reverse engineering or network traffic inspection.

The exploitation flow involves:

Obtaining the Parse Server application key from a client application or network traffic
Crafting REST API or GraphQL API requests targeting internal relationship tables (such as _Join:roles:_User)
Creating new records to associate the attacker's user account with privileged roles
Leveraging the newly acquired role memberships to bypass Class-Level Permissions (CLP) and access protected resources

By writing to any internal table backing a Relation field used in a pointerFields CLP, attackers can completely bypass that access control mechanism. This enables unauthorized access to data and functionality that should be restricted to specific roles.

Detection Methods for CVE-2026-30966

Indicators of Compromise

Unexpected entries in internal relationship tables, particularly _Join: prefixed tables
New role memberships for user accounts that were not administratively assigned
API requests targeting internal tables from non-administrative contexts
Anomalous access patterns to classes protected by role-based CLPs
Unexplained changes to pointerFields CLP-protected data

Detection Strategies

Monitor Parse Server logs for REST API and GraphQL API requests targeting internal tables with _Join: prefixes
Implement alerting on any modifications to role membership tables that bypass the master key authentication
Audit role assignments regularly to detect unauthorized privilege escalation
Review access logs for unexpected data access to CLP-protected classes

Monitoring Recommendations

Enable verbose logging for all Parse Server API endpoints, particularly those interacting with internal tables
Implement real-time monitoring for changes to the _Role class and associated join tables
Set up alerts for bulk operations or rapid changes to relationship tables
Monitor for API requests using application keys attempting to access internal administrative tables

How to Mitigate CVE-2026-30966

Immediate Actions Required

Upgrade Parse Server to version 8.6.20 or 9.5.2-alpha.7 immediately
Audit existing role memberships and relationship tables for unauthorized modifications
Rotate application keys if there is any suspicion of prior exploitation
Review and restrict network access to Parse Server endpoints while applying patches
Implement additional network-level access controls to limit API exposure

Patch Information

Parse Server has released security patches addressing this vulnerability:

For the 8.x branch: Upgrade to version 8.6.20 - Parse Server Release 8.6.20
For the 9.x branch: Upgrade to version 9.5.2-alpha.7 - Parse Server Release 9.5.2-alpha.7

For complete details, review the GitHub Security Advisory GHSA-5f92-jrq3-28rc.

Workarounds

Implement a reverse proxy or API gateway to filter requests targeting internal tables before they reach Parse Server
Add Cloud Code beforeSave triggers on internal tables to validate master key authentication
Restrict application key exposure by implementing backend-only Parse Server architectures where possible
Use network segmentation to limit which systems can communicate with Parse Server endpoints

bash

# Example: Restrict access to Parse Server internal endpoints via nginx
# Add this to your nginx server block configuration
location ~* ^/parse/classes/_Join:.* {
    # Block direct access to internal join tables
    deny all;
    return 403;
}

location ~* ^/parse/classes/_Role {
    # Restrict _Role access to internal networks only
    allow 10.0.0.0/8;
    deny all;
}