EUVD-2026-42414
GHSA-v8x7-r927-cc93
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Requires authenticated upload (PR:L) and victim must open file URL (UI:R); XSS executes in victim browser session crossing scope boundary (S:C) with no server-side confidentiality or availability impact.
Primary rating from Vendor (https://github.com/parse-community/parse-server).
CVSS VectorVendor: https://github.com/parse-community/parse-server
Lifecycle Timeline
3DescriptionCVE.org
Impact
Parse Server's default fileUpload.fileExtensions blocklist is intended to prevent uploading files that browsers render as active content (such as HTML and SVG), which can be used to perform stored cross-site scripting (XSS) attacks against other users. The blocklist could be bypassed by uploading a file whose extension is not an exact match of a blocked extension (for example a non-standard or compound extension) together with a dangerous content type. On storage adapters that persist and serve the uploaded content type (such as S3 and GCS), the file is then served with the attacker-supplied content type, enabling stored XSS against users who open the file URL.
This affects the default configuration, in which authenticated users are allowed to upload files. The default GridFS/filesystem adapter sets the X-Content-Type-Options: nosniff response header, which mitigates browser rendering on that adapter, but the upload restriction itself is still bypassed. This is an incomplete-fix follow-up of GHSA-vr5f-2r24-w5hc and GHSA-7wqv-xjf3-x35v.
Patches
The file upload extension validation now also evaluates the request content type against the configured blocklist whenever the filename's extension is not a recognized type. As a result, a dangerous content type can no longer be preserved by uploading a file with a non-standard extension, and such uploads are rejected.
Workarounds
Configure fileUpload.fileExtensions as a strict allowlist of only the file extensions your application needs (for example ["^(png|jpe?g|gif|pdf)$"]) instead of relying on the default blocklist. Additionally, serve uploaded files from a separate domain than the application, so that any executed content is isolated from the application's origin.
AnalysisAI
Stored XSS in Parse Server's file upload handler enables authenticated users to bypass the fileUpload.fileExtensions blocklist by pairing a non-standard or compound filename extension (e.g., malicious.svg~, malicious.html.bak) with a dangerous Content-Type header such as image/svg+xml or text/html. On S3 and GCS storage adapters, which persist and serve the client-supplied Content-Type, the uploaded file is subsequently delivered to browsers with attacker-controlled content, executing arbitrary JavaScript against any victim who opens the file URL. This is the third incomplete-fix iteration of the same vulnerability class (following GHSA-vr5f-2r24-w5hc and GHSA-7wqv-xjf3-x35v), with patches confirmed in versions 8.6.81 and 9.9.1-alpha.11 and no public exploit or CISA KEV listing identified at time of analysis.
Technical ContextAI
Parse Server (npm package parse-server) is an open-source Node.js backend framework providing file upload capabilities through pluggable storage adapters. The fileUpload.fileExtensions configuration maintains a blocklist of extensions associated with browser-executable content (HTML, SVG, XHTML, XML). The vulnerable validation logic extracted only the final filename extension token and compared it against the blocklist; a compound or non-standard extension such as .svg~, .svg.tmp, or .html.bak produces a final token (~, tmp, bak) that matches nothing on the blocklist, allowing the upload to proceed. CWE-434 (Unrestricted Upload of File with Dangerous Type) is the root cause: the server failed to enforce content-type restrictions when the filename extension was unrecognized by the mime library but the client submitted a dangerous Content-Type. S3 and GCS adapters preserve the original client-supplied Content-Type when serving files, making them the primary exploitation path. The default GridFS and filesystem adapter appends X-Content-Type-Options: nosniff, which prevents browser rendering and partially mitigates the stored XSS impact, though the upload restriction bypass itself still occurs on all adapters. The patch (PRs #10505 and #10506) resolves this by additionally validating the Content-Type subtype against the blocklist whenever the mime library does not recognize the filename extension.
RemediationAI
Upgrade Parse Server to version 8.6.81 (for the 8.x release line) or 9.9.1-alpha.11 (for the 9.x release line); both versions extend blocklist validation to check the Content-Type subtype whenever the mime library does not recognize the filename extension, closing the compound-extension bypass. The fixes are implemented in pull requests https://github.com/parse-community/parse-server/pull/10505 and https://github.com/parse-community/parse-server/pull/10506. Note that 9.9.1-alpha.11 is a pre-release version - evaluate stability and test coverage before deploying to production. As an interim workaround prior to patching, replace the default blocklist approach with a strict allowlist by configuring fileUpload.fileExtensions to only the extensions your application requires, for example ["^(png|jpe?g|gif|pdf)$"]; this eliminates the entire bypass surface regardless of filename or content-type combinations, with the trade-off that any extension not in the pattern is rejected and application behavior must be verified. Additionally, serve uploaded files from a separate origin domain isolated from the main application domain; this limits XSS impact to the file-serving origin's cookie and storage scope, preventing session hijacking against the primary application even if a bypass occurs.
Share
External POC / Exploit Code
Leaving vuln.today