### 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.
### 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.
Update parse-server to 9.9.1-alpha.11; parse-server to 8.6.81 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanparse-server: Stored XSS via non-standard file extension bypassing file upload extension blocklist affects parse-server (npm), parse-server (npm). Severity is low. ### 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.
AI coding agents often install or upgrade packages automatically in npm. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| parse-servernpm | >=9.0.0,<9.9.1-alpha.11 | 9.9.1-alpha.11 |
| parse-servernpm | <=8.6.80 | 8.6.81 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate parse-server to 9.9.1-alpha.11; parse-server to 8.6.81 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanparse-server: Stored XSS via non-standard file extension bypassing file upload extension blocklist affects parse-server (npm), parse-server (npm). Severity is low. ### 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.
AI coding agents often install or upgrade packages automatically in npm. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| parse-servernpm | >=9.0.0,<9.9.1-alpha.11 | 9.9.1-alpha.11 |
| parse-servernpm | <=8.6.80 | 8.6.81 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard