A 250-char multipart filename is accepted and stored verbatim, echoed in full in Content-Disposition. Render-side chip truncation contains it in the UI, so impact is storage/DB-field bloat only.
Proposed: reject or truncate filenames over ~128/255 chars server-side in internal/api (attachmentExtName parsing path, internal/api/server.go).
Repro: curl -F "file=@/tmp/$(python3 -c "print(chr(98)*250)+.txt")" POST /api/pastes -> 201.
Pre-release pentest (v0.4.0 prep) low finding.
A 250-char multipart filename is accepted and stored verbatim, echoed in full in Content-Disposition. Render-side chip truncation contains it in the UI, so impact is storage/DB-field bloat only.
Proposed: reject or truncate filenames over ~128/255 chars server-side in internal/api (attachmentExtName parsing path, internal/api/server.go).
Repro: curl -F "file=@/tmp/$(python3 -c "print(chr(98)*250)+.txt")" POST /api/pastes -> 201.
QA PASS (fix attempt 1, PR #253). Merged to dev, CI docker green, deployed to palette-dev and verified live: multipart create with a 250-char filename returns 201 with a 128-byte stored filename; GET /f/... Content-Disposition echoes only the 128-byte name. Note: truncation is byte-based, so a >128-byte name can lose its extension (e.g. 246 b's + .txt -> 128 b's). Acceptable for this finding.
QA PASS (fix attempt 1, PR #253). Merged to dev, CI docker green, deployed to palette-dev and verified live: multipart create with a 250-char filename returns 201 with a 128-byte stored filename; GET /f/... Content-Disposition echoes only the 128-byte name. Note: truncation is byte-based, so a >128-byte name can lose its extension (e.g. 246 b's + .txt -> 128 b's). Acceptable for this finding.
fen
added spent time 9 minutes2026-09-17 19:19:46 +00:00
fen
removed the QA label 2026-09-17 19:19:46 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Pre-release pentest (v0.4.0 prep) low finding.
A 250-char multipart filename is accepted and stored verbatim, echoed in full in Content-Disposition. Render-side chip truncation contains it in the UI, so impact is storage/DB-field bloat only.
Proposed: reject or truncate filenames over ~128/255 chars server-side in internal/api (attachmentExtName parsing path, internal/api/server.go).
Repro: curl -F "file=@/tmp/$(python3 -c "print(chr(98)*250)+.txt")" POST /api/pastes -> 201.
QA PASS (fix attempt 1, PR #253). Merged to dev, CI docker green, deployed to palette-dev and verified live: multipart create with a 250-char filename returns 201 with a 128-byte stored filename; GET /f/... Content-Disposition echoes only the 128-byte name. Note: truncation is byte-based, so a >128-byte name can lose its extension (e.g. 246 b's + .txt -> 128 b's). Acceptable for this finding.