### 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](https://github.com/parse-community/parse-server/security/advisories/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.
### 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](https://github.com/parse-community/parse-server/security/advisories/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.
Update parse-server to 9.9.1-alpha.4; parse-server to 8.6.79 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 trailing-dot filename bypassing file upload extension blocklist affects parse-server (npm), parse-server (npm). Severity is low. ### 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](https://github.com/parse-community/parse-server/security/advisories/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.
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.4 | 9.9.1-alpha.4 |
| parse-servernpm | <=8.6.78 | 8.6.79 |
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.4; parse-server to 8.6.79 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 trailing-dot filename bypassing file upload extension blocklist affects parse-server (npm), parse-server (npm). Severity is low. ### 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](https://github.com/parse-community/parse-server/security/advisories/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.
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.4 | 9.9.1-alpha.4 |
| parse-servernpm | <=8.6.78 | 8.6.79 |
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