CVE-2026-30228
Authorization Bypass in Parse Server Files API via readOnlyMasterKey
Publication date: 2026-03-06
Last updated on: 2026-03-11
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| parseplatform | parse-server | 9.5.0 |
| parseplatform | parse-server | 9.5.0 |
| parseplatform | parse-server | to 8.6.5 (exc) |
| parseplatform | parse-server | From 9.0.0 (inc) to 9.4.1 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-30228 is a vulnerability in the Parse Server backend where the readOnlyMasterKey, which is supposed to restrict write operations, can be misused to create and delete files via the Files API endpoints (POST /files/:filename and DELETE /files/:filename). This means that the intended read-only restriction is bypassed, allowing an attacker with access to the readOnlyMasterKey to upload arbitrary files or delete existing files.
The root cause is an incorrect authorization check that fails to properly enforce write restrictions for the readOnlyMasterKey. This issue affects Parse Server versions below 8.6.5 and versions from 9.0.0 up to but not including 9.5.0-alpha.3. The vulnerability has been fixed in versions 8.6.5 and 9.5.0-alpha.3 by adding proper permission checks.
How can this vulnerability impact me? :
If an attacker gains access to the readOnlyMasterKey in a vulnerable Parse Server deployment that exposes the Files API, they can upload arbitrary files or delete existing files. This unauthorized modification can compromise the integrity of your data and files stored or managed by the server.
The attack can be performed remotely over the network with low complexity and requires no user interaction, but the attacker must have high privileges by obtaining the readOnlyMasterKey. There is no impact on confidentiality or availability, but the integrity of files is highly impacted.
No workaround exists other than avoiding the use of the readOnlyMasterKey or restricting network access to the Files API endpoints until the server is updated to a patched version.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability involves unauthorized file creation and deletion via the Files API endpoints POST /files/:filename and DELETE /files/:filename when using the readOnlyMasterKey. Detection can focus on monitoring access logs or network traffic for suspicious use of these endpoints with the readOnlyMasterKey.'}, {'type': 'paragraph', 'content': 'You can check your Parse Server logs or network traffic for requests to the Files API endpoints that use the readOnlyMasterKey, especially POST or DELETE requests to /files/:filename.'}, {'type': 'paragraph', 'content': 'Suggested commands include using network monitoring or log searching tools to find such requests. For example, using grep on server logs:'}, {'type': 'list_item', 'content': "grep -i 'POST /files/' parse-server.log"}, {'type': 'list_item', 'content': "grep -i 'DELETE /files/' parse-server.log"}, {'type': 'paragraph', 'content': 'Additionally, monitoring network traffic with tools like tcpdump or Wireshark for HTTP requests to these endpoints can help detect exploitation attempts.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade your Parse Server deployment to a patched version that fixes this vulnerability. Specifically, upgrade to version 8.6.5 or later, or 9.5.0-alpha.3 or later.
If upgrading immediately is not possible, restrict network access to the Files API endpoints (POST /files/:filename and DELETE /files/:filename) to prevent unauthorized use of the readOnlyMasterKey.
Avoid using the readOnlyMasterKey in environments where the Files API is exposed, as no other workaround exists.