CVE-2026-30228: Authorization Bypass in Parse Server Files API via readOnlyMasterKey

Parse Server acts as a backend-as-a-service, offering database, file storage, and authentication APIs. To facilitate administrative tasks without granting full control, Parse Server implements a readOnlyMasterKey. Ideally, this credential functions similarly to the primary masterKey—bypassing Access Control Lists (ACLs) and Class-Level Permissions (CLPs)—but is strictly scoped to read operations (GET or find).

The vulnerability, identified as CVE-2026-30228, resides in the specific implementation of the Files API. While the core database triggers correctly enforce the read-only restriction, the file management endpoints (/files/:filename) failed to validate this constraint. Consequently, a request authenticated with the readOnlyMasterKey is treated with the same privileges as the full masterKey during file operations.

This flaw represents a classic Incorrect Authorization (CWE-863) issue. It breaks the security model of the least privilege principle, as credentials explicitly issued for auditing, analytics, or monitoring can be weaponized to modify application content.

The root cause lies in the request handling logic within src/Routers/FilesRouter.js. In Parse Server, authentication middleware processes headers (such as X-Parse-Master-Key) and populates the req.auth object. When the readOnlyMasterKey is provided, the middleware sets req.auth.isReadOnly = true alongside req.auth.isMaster = true.

The FilesRouter defines handlers for creating (createHandler) and deleting (deleteHandler) files. These handlers verify if the user has permission to write files. The logic correctly checks for req.auth.isMaster to allow administrative overrides. However, in the affected versions, the handlers omitted a subsequent check for req.auth.isReadOnly.

Because isMaster is true for both the full master key and the read-only master key, the router authorized the write operations. The handlers processed the file upload or deletion immediately after confirming master privileges, disregarding the isReadOnly flag that should have acted as a guardrail.

The remediation involved inserting an explicit guard clause at the beginning of the write operations in FilesRouter.js. The patch ensures that even if a request possesses master privileges, it is rejected if those privileges are flagged as read-only.

Below is the analysis of the fix applied in version 8.6.5 (Commit 07bddc0).

// src/Routers/FilesRouter.js
 
// [FIXED] createHandler now explicitly rejects read-only keys
async createHandler(req, res, next) {
+  if (req.auth.isReadOnly) {
+    const error = createSanitizedHttpError(403, "read-only masterKey isn't allowed to create a file.", req.config);
+    res.status(error.status);
+    res.end(`{"error":"${error.message}"}`);
+    return;
+  }
   const config = req.config;
   const fileData = req.body;
   // ... file creation logic proceeds only if not read-only
}
 
// [FIXED] deleteHandler applies the same restriction
async deleteHandler(req, res, next) {
+  if (req.auth.isReadOnly) {
+    const error = createSanitizedHttpError(403, "read-only masterKey isn't allowed to delete a file.", req.config);
+    res.status(error.status);
+    res.end(`{"error":"${error.message}"}`);
+    return;
+  }
   try {
     // ... file deletion logic
   }

The patch introduces a conditional check if (req.auth.isReadOnly) that returns a 403 Forbidden error, effectively closing the bypass path.

Exploitation of this vulnerability requires possession of the readOnlyMasterKey. This key is often distributed to semi-trusted internal services, dashboard viewers, or analytics platforms, under the assumption that it cannot modify data. An attacker with access to this key can interact with the Files API to perform unauthorized actions.

Attack Scenario: File Deletion To delete a critical asset (e.g., a logo or configuration file), the attacker sends a DELETE request authenticated with the read-only key.

DELETE /files/critical-asset.png HTTP/1.1
Host: api.target-app.com
X-Parse-Application-Id: <APP_ID>
X-Parse-Master-Key: <READ_ONLY_MASTER_KEY>

Attack Scenario: Malicious File Upload An attacker can upload arbitrary files, potentially hosting malware or phishing pages on the application's domain. The server accepts the upload because the readOnlyMasterKey satisfies the isMaster check.

POST /files/malware.html HTTP/1.1
Host: api.target-app.com
X-Parse-Application-Id: <APP_ID>
X-Parse-Master-Key: <READ_ONLY_MASTER_KEY>
Content-Type: text/html
 
<script>/* malicious payload */</script>

Prior to the patch, the server would process these requests successfully, returning a 201 Created or 200 OK status.

The impact of CVE-2026-30228 spans integrity and availability, with the severity dependent on how widely the readOnlyMasterKey is distributed.

Integrity Impact (High): Attackers can upload content to the application's file storage. This could be used to host phishing sites on a trusted domain, distribute malware, or deface the application by overwriting existing assets (if the storage adapter supports overwrites).

Availability Impact (High): The vulnerability allows for the deletion of any file accessible via the API. Attackers could systematically delete user avatars, document attachments, or critical application assets, causing denial of service or permanent data loss.

Confidentiality Impact (None): The vulnerability does not grant additional read access beyond what the readOnlyMasterKey already permits.

The CVSS v4.0 score of 6.9 reflects the requirement for high privileges (PR:H), as the attacker must possess a valid master key variant. However, the attack complexity is low (AC:L), and no user interaction is required.