GHSA-r899-h629-j84r: Parse Server vulnerable to stored XSS via malformed Content-Type bypassing file upload extension blocklist

Published Oct 29, 2026
·
Updated

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

Affected Software

3 affected componentsFixes available
npm/parse-server<=8.6.83
8.6.84
npm/parse-server>=9.0.0<9.10.0-alpha.2
9.10.0-alpha.2
npm/parse-server<8.6.84
8.6.84

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/parse-server to a version that resolves this vulnerability.

    Fixed in 8.6.84
  2. Upgrade

    Upgrade npm/parse-server to a version that resolves this vulnerability.

    Fixed in 9.10.0-alpha.2
  3. Configuration

    Configure the storage or CDN layer to send the X-Content-Type-Options: nosniff response header for uploaded files.

    Storage/CDN layer X-Content-Type-Options = nosniff
  4. Configuration

    Configure fileUpload.fileExtensions as a strict allowlist containing only the extensions required by the application; for example, ["^(png|jpe?g|gif|pdf)$"].

    Parse Server fileUpload.fileExtensions = ["^(png|jpe?g|gif|pdf)$"]
  5. Compensating control

    Serve uploaded files from a domain separate from the application so rendered content is isolated from the application's origin.

Event History

Oct 29, 2026
Advisory Published
via GitHub·04:33 PM
Data Sourced
via GitHub·04:33 PM
DescriptionWeaknessAffected Software
Data Sourced
via OSV·04:33 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which Parse Server deployments are exposed?

Deployments using storage adapters that persist and serve the uploaded Content-Type, including Amazon S3, Google Cloud Storage, or Azure Blob Storage, are exposed. The default GridFS storage adapter is not affected because it recomputes the Content-Type.

2

What does an attacker need to exploit this issue?

The attacker must have permission to upload files and must cause another user to open the uploaded file URL. They can upload content beginning with HTML markup while supplying a malformed Content-Type such as "image", "image/", or "image//svg+xml".

3

Does the default file extension blocklist prevent exploitation?

No. Although fileUpload.fileExtensions is enabled by default with a blocklist, malformed Content-Type values can bypass that validation when the file extension is not recognized by the mime package and the storage adapter serves the supplied Content-Type unchanged.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203