CVE-2026-34574: Parse Server Auth Bypass Vulnerability

CVE-2026-34574 Overview

Parse Server, an open source backend that can be deployed to any infrastructure running Node.js, contains an authorization bypass vulnerability in session field handling. Prior to versions 8.6.69 and 9.7.0-alpha.14, an authenticated user can bypass the immutability guard on session fields (expiresAt, createdWith) by sending a null value in a PUT request to the session update endpoint. This allows nullifying the session expiry, making the session valid indefinitely and bypassing configured session length policies.

Critical Impact

Authenticated attackers can create indefinitely valid sessions by nullifying expiration timestamps, effectively bypassing session management policies and maintaining persistent unauthorized access.

Affected Products

• Parse Server versions prior to 8.6.69
• Parse Server versions 9.7.0-alpha.1 through 9.7.0-alpha.13
• parseplatform parse-server for Node.js

Discovery Timeline

• 2026-03-31 - CVE-2026-34574 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-34574

Vulnerability Analysis

This vulnerability is classified under CWE-697 (Incorrect Comparison), which manifests in how Parse Server validates session field modifications. The root issue lies in the session update handler's conditional checks that use JavaScript's truthy/falsy evaluation rather than explicit property existence checks.

When an authenticated user attempts to modify protected session fields like expiresAt or createdWith, the server's immutability guard incorrectly allows the operation when the submitted value is null. This occurs because JavaScript evaluates null as falsy, causing the conditional check if (this.data.expiresAt) to pass without triggering the security error.

The practical consequence is significant: by setting expiresAt to null, an attacker can transform a time-limited session into one that never expires. This undermines the entire session lifecycle management, allowing persistent access even after administrative attempts to enforce session rotation or expiration policies.

Root Cause

The vulnerability stems from improper comparison logic in the RestWrite.js file. The original code used JavaScript's truthy evaluation (this.data.expiresAt) to check if a field was being modified. However, this approach fails to catch null values, as null evaluates to falsy in JavaScript. The fix changes the comparison to use the in operator ('expiresAt' in this.data), which correctly detects the presence of the property regardless of its value.

Attack Vector

The attack requires network access and low-privilege authenticated access. An attacker with a valid user session can send a crafted PUT request to the session update endpoint with expiresAt set to null. The server's flawed validation logic allows this modification, effectively removing the session expiration constraint. This attack vector is particularly concerning because:

1. It requires only basic user authentication
2. No user interaction is needed
3. The modification persists in the database
4. Standard session expiration checks become ineffective

// Security patch in src/RestWrite.js
// Source: https://github.com/parse-community/parse-server/commit/90802969fc713b7bc9733d7255c7519a6ed75d21

   if (this.query) {
     if (this.data.user && !this.auth.isMaster && this.data.user.objectId != this.auth.user.id) {
       throw new Parse.Error(Parse.Error.INVALID_KEY_NAME, 'Invalid key name: user');
-    } else if (this.data.installationId) {
+    } else if ('installationId' in this.data) {
       throw new Parse.Error(Parse.Error.INVALID_KEY_NAME, 'Invalid key name: installationId');
-    } else if (this.data.sessionToken) {
+    } else if ('sessionToken' in this.data) {
       throw new Parse.Error(Parse.Error.INVALID_KEY_NAME, 'Invalid key name: sessionToken');
-    } else if (this.data.expiresAt && !this.auth.isMaster && !this.auth.isMaintenance) {
+    } else if ('expiresAt' in this.data && !this.auth.isMaster && !this.auth.isMaintenance) {
       throw new Parse.Error(Parse.Error.INVALID_KEY_NAME, 'Invalid key name: expiresAt');
-    } else if (this.data.createdWith && !this.auth.isMaster && !this.auth.isMaintenance) {
+    } else if ('createdWith' in this.data && !this.auth.isMaster && !this.auth.isMaintenance) {
       throw new Parse.Error(Parse.Error.INVALID_KEY_NAME, 'Invalid key name: createdWith');
     }
     if (!this.auth.isMaster) {

Detection Methods for CVE-2026-34574

Indicators of Compromise

• Session records in the database with null values in expiresAt or createdWith fields
• PUT requests to session update endpoints containing null values for protected fields
• Sessions that remain valid significantly beyond configured expiration policies
• Unusual session activity patterns indicating persistent unauthorized access

Detection Strategies

• Monitor Parse Server API logs for PUT requests to /parse/sessions endpoints containing null payloads
• Implement database queries to identify sessions with null expiresAt values that should have expiration timestamps
• Deploy application-layer monitoring to detect attempts to modify protected session fields
• Configure alerts for sessions that exceed expected maximum lifetime thresholds

Monitoring Recommendations

• Enable verbose logging on Parse Server session management operations
• Implement periodic database audits to identify anomalous session records
• Set up real-time alerting for session modification attempts on protected fields
• Monitor authentication patterns for users with abnormally long-lived sessions

How to Mitigate CVE-2026-34574

Immediate Actions Required

• Upgrade Parse Server to version 8.6.69 or later for the stable branch
• Upgrade Parse Server to version 9.7.0-alpha.14 or later for the alpha branch
• Audit existing session records for null expiresAt values and invalidate suspicious sessions
• Review application logs for evidence of exploitation attempts

Patch Information

Parse Server maintainers have released security patches addressing this vulnerability. The fix modifies the conditional checks in RestWrite.js to use the in operator for property existence verification instead of truthy/falsy evaluation. Organizations should apply the appropriate patch based on their deployment:

• Stable branch: Commit 90802969fc713b7bc9733d7255c7519a6ed75d21
• Alpha branch: Commit ebccd7fe2708007e62f705ee1c820a6766178777

For detailed security information, refer to the GitHub Security Advisory GHSA-f6j3-w9v3-cq22.

Workarounds

• Implement API gateway rules to reject PUT requests to session endpoints containing null values for protected fields
• Deploy a reverse proxy filter to sanitize incoming session modification requests
• Enable strict input validation at the network layer to prevent null value injection
• Consider implementing additional session validation logic at the application level until patches can be applied

# Example: Database query to identify potentially exploited sessions
# Run this against your Parse Server MongoDB instance
mongo parse_database --eval '
db._Session.find({
  expiresAt: null,
  createdAt: { $exists: true }
}).forEach(function(session) {
  print("Suspicious session found: " + session._id + " for user: " + session._p_user);
});
'