2vulnerabilities
- Critical0 (0.0%)
- High0 (0.0%)
- Medium0 (0.0%)
- Moderate1 (50.0%)
- Low1 (50.0%)
uploadfs
Ecosystem: npm
Downloads:
- 0CriticalAffects 0 versions
- 0HighAffects 0 versions
- 0MediumAffects 0 versions
- 1ModerateAffects 1 version
- 1LowAffects 1 version
Monthly breakdown
- 2 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 1
- Low: 1
Vulnerabilities (2)
Known vulnerabilities affecting uploadfs, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-gmfx-5g6x-rr72 | Low | ApostropheCMS: Path traversal in uploadfs## Summary The `uploadfs` library's local storage backend does not validate or sanitize user-supplied paths. The `prefixPath()` helper only strips double slashes (`//`) and the backend performs direct string concatenation (`uploadsPath + path`). An attacker can inject `../` sequences to escape the intended uploads directory, resulting in arbitrary file read, write, and delete on the host filesystem. --- ## Details ### Root Cause `packages/uploadfs/uploadfs.js:652-655` https://github.com/apostrophecms/apostrophe/blob/main/packages/uploadfs/uploadfs.js#L652-L655 ```javascript function prefi |
| GitHub (opens in a new tab) | |
| GHSA-hhph-8536-gfq5 | Moderate | ApostropheCMS uploadfs Azure backend leaks account-level SAS token into every public attachment URL (sas: true)## Summary When uploadfs is configured with the Azure backend and `sas: true` (a supported configuration introduced in uploadfs 1.25.0), `createContainer()` builds the `BlobServiceClient` from a URL that embeds the full SAS query string, and Azure SDK v12 derived clients inherit that query string. As a result, `getUrl()` returns a base URL carrying the complete account/container SAS signature (`?sv=...&sig=...`), and Apostrophe's `attachment.url()` prepends it to every public attachment link — broadcasting a container-level SAS credential (commonly `sp=rwdlac`, full read/write/delete/list) to |
| GitHub (opens in a new tab) |
## Summary The `uploadfs` library's local storage backend does not validate or sanitize user-supplied paths. The `prefixPath()` helper only strips double slashes (`//`) and the backend performs direct string concatenation (`uploadsPath + path`). An attacker can inject `../` sequences to escape the intended uploads directory, resulting in arbitrary file read, write, and delete on the host filesystem. --- ## Details ### Root Cause `packages/uploadfs/uploadfs.js:652-655` https://github.com/apostrophecms/apostrophe/blob/main/packages/uploadfs/uploadfs.js#L652-L655 ```javascript function prefi
CVE: CVE-2026-113651
- GHSA-hhph-8536-gfq5ModerateApostropheCMS uploadfs Azure backend leaks account-level SAS token into every public attachment URL (sas: true)
>= 1.25.0, < 1.28.0
## Summary When uploadfs is configured with the Azure backend and `sas: true` (a supported configuration introduced in uploadfs 1.25.0), `createContainer()` builds the `BlobServiceClient` from a URL that embeds the full SAS query string, and Azure SDK v12 derived clients inherit that query string. As a result, `getUrl()` returns a base URL carrying the complete account/container SAS signature (`?sv=...&sig=...`), and Apostrophe's `attachment.url()` prepends it to every public attachment link — broadcasting a container-level SAS credential (commonly `sp=rwdlac`, full read/write/delete/list) to
CVE: CVE-2026-113652