# File type trusted from attacker headers

Upload or fetch handlers deciding file type from headers, URL suffix, or SDK params that may be silently dropped

_Area: Web business logic and race conditions. Seen in 3 disclosed reports; latest 2022-06-30. Updated 2026-10-24._

## How it works
A handler decides what a file *is* from something the attacker controls — a response `Content-Type`/`Content-Disposition`, a URL suffix, or a parameter it believes the SDK signed — instead of from the bytes or from a constraint it verified actually took effect. The assumption that breaks: "the type/size I checked is the type/size that will be delivered." When the classifier input is attacker-supplied, the check and the use disagree.

## Where it shows up
- Download/import handlers branching on `Content-Type`, `Content-Disposition`, or filename extension [E2](https://bugbountylibrary.com/r/h1%3A963155.md)[E3](https://bugbountylibrary.com/r/h1%3A975514.md)
- Custom protocol or extension handlers accepting any URL ending in a known suffix, or following redirects before validating content [E3](https://bugbountylibrary.com/r/h1%3A975514.md)
- Presigned-URL code passing `content_length`/`content_type` to an SDK presigner without confirming the value appears in the signed URL [E1](https://bugbountylibrary.com/r/h1%3A789579.md)
- Server behavior that varies by `Referer`/`User-Agent`, so the same URL returns different content to the validator vs. the consumer [E2](https://bugbountylibrary.com/r/h1%3A963155.md)

## How to review
Identify the exact input that classifies the file, then ask whether an attacker can set it independently of the content. The invariant: the type/size enforced at validation must be the same value enforced at delivery, and it must derive from content or from a signature the verifier checks. For presigned URLs, decode the signed URL and confirm the constraint (length, type) is actually present in the signature — do not trust that passing a parameter to the SDK signed it [E1](https://bugbountylibrary.com/r/h1%3A789579.md). For download handlers, confirm classification uses parsed content, not headers or suffix, and that redirects are resolved before any type decision [E2](https://bugbountylibrary.com/r/h1%3A963155.md)[E3](https://bugbountylibrary.com/r/h1%3A975514.md).

## Variants seen
- SDK silently drops a security-relevant header from the signature, so a size limit never binds [E1](https://bugbountylibrary.com/r/h1%3A789579.md)
- Client trusts response headers to classify a download, enabling a non-torrent executable to be treated as a torrent [E2](https://bugbountylibrary.com/r/h1%3A963155.md)
- Handler trusts URL suffix/scheme and mishandles redirects, fetching attacker content [E3](https://bugbountylibrary.com/r/h1%3A975514.md)

## Impact and severity
Led to arbitrary file download and client-side RCE (E2, E3) and bypass of upload size limits (E1). Severity rises when the misclassified file is later executed or opened by the client, and when header-varying tricks defeat the validator's own view of the content [E2](https://bugbountylibrary.com/r/h1%3A963155.md).

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A789579.md
- E2: https://bugbountylibrary.com/r/h1%3A963155.md
- E3: https://bugbountylibrary.com/r/h1%3A975514.md