Four Vulnerabilities in Parse Server

07 Mar, 2026

Table of Contents

• Intro Lore
• What is Parse Server?
  • The readOnlyMasterKey Contract
• Vulnerabilities
  • CVE-2026-29182 Cloud Hooks and Cloud Jobs bypass readOnlyMasterKey
  • CVE-2026-30228 File Creation and Deletion bypass readOnlyMasterKey
  • CVE-2026-30229 /loginAs allows readOnlyMasterKey to gain full access as any user
  • CVE-2026-30863 JWT Audience Validation Bypass in Google, Apple, and Facebook Adapters
• Disclosure Timeline
• References

Vulnerabilities

Intro Lore

Parse Server is one of those projects that sits quietly beneath a lot of production infrastructure. It powers the backend of a meaningful number of mobile and web applications, particularly those that started on Parse's original hosted platform before it shut down in 2017 and needed somewhere to migrate. Currently the project has over 21,000+ stars on GitHub

I recently spent some time auditing its codebase and found four security vulnerabilities. Three of them share a common root, a fundamental gap between what readOnlyMasterKey is documented to do and what the server actually enforces. The fourth is an independent issue in the social authentication adapters that is arguably more severe, a JWT validation bypass that allows an attacker to authenticate as any user on a target server using a token issued for an entirely different application.

The Parse Server team was responsive throughout and coordinated fixes promptly. All four issues have been patched.

What is Parse Server?

Parse Server is an open-source Node.js backend framework that provides a complete application backend out of the box, a database abstraction layer (typically over MongoDB or PostgreSQL), a REST and GraphQL API, user authentication, file storage, push notifications, Cloud Code for serverless functions, and a real-time event system. It is primarily used as the backend for mobile applications and is the open-source successor to Parse's original hosted backend-as-a-service platform.

Parse Server authenticates API requests using one of several key types. The masterKey grants full administrative access to all data, bypassing all object-level and class-level permission checks. It is intended for trusted server-side operations only.

The readOnlyMasterKey Contract

Parse Server also exposes a readOnlyMasterKey option. Per its documentation, this key grants master-level read access, it can query any data, bypass ACLs for reading, and perform administrative reads, but is explicitly intended to deny all write operations. It is the kind of credential you might hand to an analytics service, a monitoring agent, or a read-only admin dashboard, enough power to see everything, but no ability to change anything.

That contract is what three of these four vulnerabilities break. The implementation checks whether a request carries master-level credentials by testing a single flag — isMaster — on the auth object. The problem is that readOnlyMasterKey authentication sets both isMaster: true and isReadOnly: true, and a large number of route handlers only check the former. The isReadOnly flag is set but never consulted, which means the read-only restriction exists in concept but not in enforcement.

Vulnerabilities

CVE-2026-29182 Cloud Hooks and Cloud Jobs bypass readOnlyMasterKey

Cloud Hooks are server-side webhooks that fire when specific Parse Server events occur — object creation, deletion, user signup, and so on. Cloud Jobs are scheduled or manually triggered background tasks that can execute arbitrary Cloud Code functions. Both are powerful primitives: Cloud Hooks can exfiltrate any data passing through the server's event stream, and Cloud Jobs can execute arbitrary logic on demand.

The routes that manage Cloud Hooks and Cloud Jobs — creating new hooks, modifying existing ones, deleting them, and triggering job execution — are all guarded by master key access checks. Those checks verify only that the requesting credential has isMaster: true. Because readOnlyMasterKey satisfies that condition, a caller holding only the read-only credential can fully manage the Cloud Hook lifecycle and trigger Cloud Jobs at will.

The practical impact is data exfiltration via Cloud Hook. An attacker who knows the readOnlyMasterKey can register a new Cloud Hook pointing to an external endpoint they control, then watch as every matching Parse Server event — user signups, object writes, session creation — is delivered to them in real time. The read-only key, intended to allow passive observation, can be turned into an active wiretap on the entire application's event stream.

The fix adds explicit isReadOnly rejection checks to the Cloud Hook and Cloud Job handlers.

CVE-2026-30228 File Creation and Deletion bypass readOnlyMasterKey

Parse Server's Files API exposes endpoints for uploading and deleting files — POST /files/:filename and DELETE /files/:filename. Both routes are guarded by enforceMasterKeyAccess, a middleware that checks whether the incoming request has master-level credentials. Like the Cloud Hooks routes, this check only tests isMaster and never consults isReadOnly.

The root cause traces through three locations in the codebase. In src/middlewares.js at lines 267–278, the read-only auth object is constructed with isMaster: true. In src/Routers/FilesRouter.js at lines 107–113, the delete route applies enforceMasterKeyAccess as its only guard. At lines 586–602 of the same file, the delete handler calls through to filesController.deleteFile() without any additional read-only check in the call chain.

The consequence is that a caller with only readOnlyMasterKey can upload arbitrary files to the server's storage backend or permanently delete any existing file by name. The upload vector is primarily an integrity concern — poisoning stored assets. The deletion vector is a high-availability concern — an attacker can destroy application data (user avatars, documents, media) that may not have backups, and depending on how the application is structured, deletion of certain files could cause cascading application failures.

The fix adds isReadOnly rejection to both the file upload and file delete handlers.

CVE-2026-30229 /loginAs allows readOnlyMasterKey to gain full access as any user

This is the most impactful of the three readOnlyMasterKey issues. The /loginAs endpoint is a privileged administrative route intended for master-key workflows — it accepts a userId parameter and returns a valid, usable session token for that user. The design intent is to allow administrators to impersonate users for debugging or support purposes. It is the digital equivalent of a master key that can open any door.

The route's handler, handleLogInAs, is located in src/Routers/UsersRouter.js at lines 339–345 and is mounted as POST /loginAs at lines 706–708. The guard condition rejects requests where req.auth.isMaster is false. Because readOnlyMasterKey produces an auth object where isMaster is true — and because there is no isReadOnly check anywhere in the handler or its middleware chain — the read-only credential passes the gate and the endpoint returns a fully usable sessionToken for any userId provided.

That session token is not a read-only token. It is a normal user session token, indistinguishable from one obtained by logging in with a password. It grants full read and write access to everything that user's ACL and role memberships permit. An attacker with the readOnlyMasterKey and knowledge of any user's object ID can silently mint a session as that user and then act as them with complete write access — modifying their data, making purchases, changing their email address, deleting their account, or doing anything else the application allows its users to do.

There is no workaround other than removing readOnlyMasterKey from the deployment or upgrading. The fix is a single guard added to handleLogInAs that rejects the request when req.auth.isReadOnly is true.

CVE-2026-30863 JWT Audience Validation Bypass in Google, Apple, and Facebook Adapters

This vulnerability is independent of the readOnlyMasterKey theme and is the most severe of the four. It sits in Parse Server's social authentication layer — specifically in the adapters that validate identity tokens for Sign in with Google, Sign in with Apple, and Facebook Login.

When a user authenticates via one of these providers, the client receives a JSON Web Token signed by the provider. Parse Server's authentication adapters are supposed to verify this token, they check the signature, the expiry, and critically, the audience claim — the aud field that specifies which application the token was issued for. Audience validation is what prevents a token issued for one application from being used to authenticate against a different application. Without it, a validly signed token from any Google, Apple, or Facebook application in the world can be used to authenticate against any Parse Server that trusts the same provider.

The vulnerability arises from how the adapters handle missing configuration. For the Google and Apple adapters, the audience is passed to JWT verification via the clientId configuration option. When clientId is not set, the adapters do not reject the configuration as incomplete — they silently skip audience validation entirely. The JWT is verified for signature and expiry only, and any valid Google or Apple token from any app will be accepted.

For Facebook Limited Login, the situation is worse, the vulnerability exists regardless of configuration. The Facebook adapter validates appIds as the expected audience for the Standard Login (Graph API) flow. However, the Limited Login path — which uses JWTs rather than Graph API tokens — never passes appIds to JWT verification at all. The code path simply does not include the audience parameter in the verification call, meaning no appIds configuration value, however correct, can prevent the bypass on the Limited Login path.

The attack is straightforward. An attacker creates or uses any existing Google, Apple, or Facebook application they control, signs in to obtain a legitimately signed JWT, and then presents that token to a vulnerable Parse Server's authentication endpoint. Because audience validation is skipped, the token passes verification. Combined with the ability to specify which Parse Server user account to associate the token with, this becomes full pre-authentication account takeover for any user on the server — with no credentials, no brute force, and no interaction from the victim.

The fix enforces clientId (Google/Apple) and appIds (Facebook) as mandatory configuration and passes them correctly to JWT verification for both the Standard Login and Limited Login paths on all three adapters.

Disclosure Timeline

References

• CVE-2026-29182: GHSA-vc89-5g3r-cmhh — Fixed in 8.6.4, 9.4.1-alpha.3
• CVE-2026-30228: GHSA-xfh7-phr7-gr2x — Fixed in 8.6.5, 9.5.0-alpha.3
• CVE-2026-30229: GHSA-79wj-8rqv-jvp5 — Fixed in 8.6.6, 9.5.0-alpha.4
• CVE-2026-30863: GHSA-x6fw-778m-wr9v — Fixed in 8.6.10, 9.5.0-alpha.11
• Parse Server repository: github.com/parse-community/parse-server