You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 4e490b7
Browse filesBrowse the repository at this point in the historyBrowse files
fix(#379): Security (low): names containing U+FFFD are created by every write path but hidd
Home paths now refuse U+FFFD with PATH_INVALID through a new normalizeHomePath used by resolveInRoot and the whole local backend (PUT, tus, mkdir, move/copy/rename, WebDAV, transfers, archive import, share writes), and file-request visitor and uploader names drop it, so nothing can be planted that the listing, the ZIP export or the reindex hide; cloud sources keep such names addressable (adversarial review found the global regex broke cloud reads). The web's rename, new-folder, name-rules and migration name checks refuse U+FFFD through a shared hasUnsafeChar with the reworded inline message in all three locales; DECISIONS.md amended. Reviews run: adversarial (led to the home-only scope and the name-rules/migrate checks) and test adversary (no blocking findings; added on-disk and no-request assertions).
Refs #379
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: DECISIONS.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,6 +42,8 @@ File content is served inline only for images (not SVG), video, audio, PDF and `
42
42
43
43
On-disk names that are not canonical (NFD-normalised, containing control characters, or invalid UTF-8) are skipped in listings. They cannot round-trip through the API's path rules, so showing them would offer entries the user cannot open.
44
44
45
+
Amended 2026-10-19 (#379): a name containing U+FFFD is treated as invalid UTF-8 and hidden too, so the path rules of a home (`normalizeHomePath`, used by `resolveInRoot` and the local backend) refuse U+FFFD like a control character (`PATH_INVALID` on every write path), and a file request visitor's file or uploader name loses it like a control character. Otherwise any member with write access, or a visitor, could plant files the listing, the ZIP download and the reindex never show. A file whose name contains U+FFFD and was put on the disk outside the app (a restored backup) stays unaddressable, as other non-canonical names do. Cloud sources keep U+FFFD: their listings show such names, so they must stay addressable there; a transfer of one into a home fails that item with `PATH_INVALID`, as a control character does. The web's name dialogs refuse U+FFFD everywhere, a simpler rule than one per source.
46
+
45
47
## 2026-10-14: upload content-type gate before body parsing
46
48
47
49
The upload route checks the content type (`application/octet-stream`) in `onRequest`, before any body parser runs. Otherwise a JSON or text content type would make Fastify buffer the whole body in memory, which is a denial of service.
0 commit comments