Public mode

No access to your tenant or devices. Every item links to its source. What this means

Some sources, documents or advisories need attention: 275/275 feeds/APIs · 469/469 docs · 8/9 advisories · checked 05:48 UTC Customize Public modeDiscuss ChangeIntel on Discord

Parse Server vulnerable to stored XSS via malformed Content-Type bypassing file upload extension blocklist

Exact source revision recorded 29 Oct 2026 17:12:42 UTC. It does not establish the source's current position. Latest evidence.

osv · GHSA-r899-h629-j84r

Published

### Impact Parse Server's file upload validation uses the `fileUpload.fileExtensions` option (enabled by default with a blocklist) to reject files that browsers may render as active content, mitigating stored cross-site scripting (XSS). When an uploaded file's extension is not recognized by the `mime` package, Parse Server preserves the client-supplied `Content-Type` and passes it to the storage adapter. A malformed `Content-Type` that is not a valid `type/subtype` media type — for example `image` (no subtype), `image/` (empty subtype), or `image//svg+xml` (invalid token) — bypassed the blocklist and was stored unchanged. On storage adapters that persist and serve the uploaded `Content-Type` (such as Amazon S3, Google Cloud Storage, or Azure Blob Storage), a browser cannot parse the malformed `Content-Type` and falls back to MIME-sniffing the file content; a file whose body begins with HTML markup is then rendered as HTML, executing any embedded script in the application's origin. This allows a user permitted to upload files to store content that executes as script against other users who open the file URL. The default GridFS storage adapter is not affected, as it recomputes the `Content-Type` from the filename and serves files with `X-Content-Type-Options: nosniff`. ### Patches The file upload handler now validates that the client-supplied `Content-Type` is a well-formed media type (`type/subtype` with non-empty tokens per RFC 9110 §5.6.2) whenever the filename extension is not recognized by `mime`. Malformed values are rejected instead of being stored, while well-formed types — including custom or vendor types that the `mime` package does not recognize — continue to be accepted; only blocklisted subtypes are rejected. ### Workarounds Configure `fileUpload.fileExtensions` as a strict allowlist of only the extensions the application needs (for example `["^(png|jpe?g|gif|pdf)$"]`). Additionally, serve uploaded files from a domain separate from the application so that any rendered content is isolated from the application's origin, and configure the storage/CDN layer to send `X-Content-Type-Options: nosniff`. ### References - GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-r899-h629-j84r - Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10521 - Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10523

Source published
29 Oct 2026 16:33:48 UTC
Source modified
29 Oct 2026 16:45:04 UTC
Observed here
29 Oct 2026 17:12:42 UTC
Source terms
GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V4 · 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

Publisher rating · LOW

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 7 Nov 05:48 UTC · 275 of 275 readable · 274 fully read · documentation 469/469 current