Skip to content

Untrusted file upload: multer trusts client mimetype; EXIF/image decode runs on attacker-crafted bytes #65

Description

@cybermax4200

Why this matters now: Proof photos are the core trust anchor; a malicious upload can CPU/memory-exhaust the process or crash the worker.

Problem / What: upload.ts:43-46 fileFilter accepts based solely on the client-supplied file.mimetype (trivially spoofable). The file is then handed to ExifReader.load and image-size in photoService.ts:112-147, which parse raw bytes. Although MAX_EXIF_SCAN_BYTES bounds the EXIF scan, the full buffer is still read and the header decode is unbounded; a crafted file can spike CPU or throw in ways the surrounding catch swallows (see #15).

Key Challenges: Detecting the real format via magic bytes / file-type, enforcing a hard CPU/memory budget per upload (worker thread or size caps), and deciding acceptable formats defensively.

Acceptance Criteria:

  • A renamed non-image (or malicious) upload is rejected before decode, not after a CPU spike.
  • A fuzzed corpus of malformed images cannot crash or hang the upload/decode path (test).

Relevant files/functions: src/middleware/upload.ts:40-47, src/services/photoService.ts:112-147, src/controllers/proofController.ts:113-145.

Out of scope: Virus scanning.

Labels: advanced, security

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions