GHSA-v8x7-r927-cc93 parse-server: Stored XSS via non-standard file extension bypassing file upload extension blocklist

• npm parse-server: >= 9.0.0, < 9.9.1-alpha.11 → fixed in 9.9.1-alpha.11 • npm parse-server: < 8.6.81 → fixed in 8.6.81

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.