parse-server: Stored XSS via trailing-dot filename bypassing file upload extension blocklist

Impact

The default file upload extension blocklist can be bypassed by appending a trailing dot to a filename whose extension would otherwise be blocked (e.g. poc.svg.). The trailing dot causes the extension parser to extract an empty string, which short-circuits the blocklist check, and the attacker-controlled Content-Type is forwarded to the storage adapter unchanged. Storage adapters that persist and serve the provided Content-Type (such as S3 or GCS) then serve the file with an active type such as image/svg+xml, enabling stored XSS when a victim opens the file URL. The default GridFS adapter is not affected because it sets X-Content-Type-Options: nosniff on responses.

Patches

A filename ending in a dot is now treated as extensionless. When the parser produces an empty extension, the request handler falls back to validating the Content-Type subtype against the configured extension blocklist, matching the path that already catches truly extensionless uploads with a dangerous Content-Type. This is a follow-up to the previous fix GHSA-vr5f-2r24-w5hc.

Workarounds

Configure the storage adapter or CDN to derive Content-Type from the filename extension instead of using the stored Content-Type, or replace the default blocklist with an explicit allowlist of needed file extensions.