CVE-2026-35200: Parse Server File Upload Vulnerability

CVE-2026-35200 Overview

CVE-2026-35200 is a Content-Type mismatch vulnerability in Parse Server, an open source backend that can be deployed to any infrastructure that can run Node.js. This vulnerability allows attackers to upload files with a filename extension that passes the file extension allowlist (e.g., .txt) but with a Content-Type header that differs from the extension (e.g., text/html). The Content-Type is passed to the storage adapter without consistency validation, potentially enabling stored cross-site scripting or content spoofing attacks when the file is served.

Critical Impact

Attackers can bypass file upload security controls by uploading files with mismatched extensions and Content-Type headers, potentially enabling stored XSS attacks when files are served with unvalidated Content-Type headers by cloud storage adapters like S3 or GCS.

Affected Products

• parseplatform parse-server versions prior to 8.6.73
• parseplatform parse-server versions prior to 9.7.1-alpha.4
• parseplatform parse-server versions 9.7.1-alpha1, 9.7.1-alpha2, and 9.7.1-alpha3

Discovery Timeline

• April 6, 2026 - CVE CVE-2026-35200 published to NVD
• April 7, 2026 - Last updated in NVD database

Technical Details for CVE-2026-35200

Vulnerability Analysis

This vulnerability stems from a lack of consistency validation between the file extension and Content-Type header during file uploads in Parse Server. When a user uploads a file, Parse Server validates the filename extension against an allowlist but does not verify that the Content-Type header matches the expected MIME type for that extension. This inconsistency allows an attacker to upload a file with a benign extension like .txt while specifying a potentially dangerous Content-Type such as text/html.

The security impact depends on the storage adapter in use. Cloud storage adapters like Amazon S3 or Google Cloud Storage (GCS) store and serve the provided Content-Type header without modification. When users access these files, the browser interprets them according to the Content-Type header rather than the extension, potentially executing malicious content. The default GridFS adapter is not affected because it derives the Content-Type from the filename at serving time, providing an inherent mitigation.

Root Cause

The root cause is classified under CWE-436 (Interpretation Conflict), where the system fails to validate that the file extension and Content-Type header are consistent. The file upload validation logic checks the extension against an allowlist but blindly trusts and passes through the user-supplied Content-Type header to the storage adapter. This creates a gap between what the extension implies and how the content is actually served to end users.

Attack Vector

The attack is network-based and requires authentication to the Parse Server application. An attacker with valid credentials can craft a multipart file upload request containing a file with a permitted extension (such as .txt or .png) while specifying a different Content-Type header (such as text/html or application/javascript). When the file is retrieved from an affected storage adapter like S3 or GCS, it is served with the attacker-specified Content-Type, potentially triggering script execution in the victim's browser if the content contains malicious payloads.

The attack does require user interaction, as a victim must access the uploaded file through the application for the payload to execute. This limits the severity but still presents a risk in applications where users regularly access uploaded content.

Detection Methods for CVE-2026-35200

Indicators of Compromise

• Uploaded files where the Content-Type header does not match the expected MIME type for the file extension (e.g., .txt files with text/html Content-Type)
• Unusual file upload requests with mismatched extension and Content-Type combinations in server logs
• User reports of unexpected content execution when accessing seemingly benign file types

Detection Strategies

• Implement log analysis to detect file uploads where the Content-Type header differs from the expected MIME type based on file extension
• Monitor storage bucket access patterns for files that trigger browser security warnings or unexpected rendering behavior
• Review application logs for patterns of file uploads from users attempting multiple extension/Content-Type combinations

Monitoring Recommendations

• Enable detailed logging for file upload endpoints including both filename extensions and Content-Type headers
• Configure cloud storage bucket logging to track Content-Type headers on file retrieval requests
• Set up alerts for anomalous file upload patterns, particularly files with common extensions but unusual Content-Type values

How to Mitigate CVE-2026-35200

Immediate Actions Required

• Upgrade Parse Server to version 8.6.73 or later for the 8.x branch
• Upgrade Parse Server to version 9.7.1-alpha.4 or later for the 9.x branch
• If using S3 or GCS storage adapters, audit recently uploaded files for Content-Type mismatches
• Consider temporarily using the GridFS adapter if immediate patching is not possible, as it derives Content-Type from filenames

Patch Information

Parse Server has released security patches addressing this vulnerability. The fix implements consistency validation between file extensions and Content-Type headers during the upload process. Detailed information about the patches is available in the official security advisory and pull requests:

• GitHub Pull Request #10383 - Fix for stable branch
• GitHub Pull Request #10384 - Fix for alpha branch
• GitHub Security Advisory GHSA-vr5f-2r24-w5hc - Official security advisory

Workarounds

• Switch to the GridFS storage adapter if S3 or GCS adapters are not strictly required, as GridFS derives Content-Type from the filename at serving time
• Implement a cloud function or middleware that validates Content-Type consistency before files are stored
• Configure cloud storage buckets to serve all files with a safe Content-Type like application/octet-stream and force downloads rather than inline rendering
• Apply Content-Security-Policy headers on file serving endpoints to restrict script execution