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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions