Attachment thumbnail decision uses filename extension instead of server-verified MIME type #60

New Issue

2026-08-31T21:40:12-04:00

jared commented

2026-08-31 21:40:12 -04:00

Severity: Low (cosmetic, not exploitable)

assets/js/ticket.js (~line 1050), renderAttachments() computes isImage via a regex against att.original_filename rather than checking att.mime_type, which the API already returns and which reflects the real, finfo-verified type set at upload time (per models/AttachmentModel.php).

Impact: A file whose true type differs from its display filename (e.g. a PDF a user named photo.png — the server correctly stores it as a PDF but preserves the original display name) renders a broken <img> thumbnail instead of falling back to the file-type icon.

Fix: Use att.mime_type (already returned by the API) to decide whether to render an image thumbnail, instead of pattern-matching the filename.

**Severity:** Low (cosmetic, not exploitable) `assets/js/ticket.js` (~line 1050), `renderAttachments()` computes `isImage` via a regex against `att.original_filename` rather than checking `att.mime_type`, which the API already returns and which reflects the real, `finfo`-verified type set at upload time (per `models/AttachmentModel.php`). **Impact:** A file whose true type differs from its display filename (e.g. a PDF a user named `photo.png` — the server correctly stores it as a PDF but preserves the original display name) renders a broken `<img>` thumbnail instead of falling back to the file-type icon. **Fix:** Use `att.mime_type` (already returned by the API) to decide whether to render an image thumbnail, instead of pattern-matching the filename.

jared added the priority/low ux labels 2026-09-08 10:15:46 -04:00

jared referenced this issue from a commit

2026-09-08 11:59:38 -04:00

Use server-verified mime_type for attachment thumbnail detection (#60)

jared referenced this issue from a commit

2026-09-08 15:39:42 -04:00

Merge development into main: 15-issue triage + fix batch

Sign in to join this conversation.