Flask's send_file() silently infers MIME type from filename extension at serving time, overriding whatever content-validation logic you ran upstream. That's the core hazard: you can validate that a file is a legitimate PDF by inspecting its bytes, then serve it through send_file() and let Flask derive application/pdf from the .pdf extension — the very signal you deemed untrustworthy during validation. The fix is straightforward (explicit MIME, force attachment, use a safe filename), but that simplicity is the warning. If the remedy is three lines, the API design failed by making the insecure path the path of least resistance.
The pattern isn't Flask-specific. Django, Express, and other frameworks have produced near-identical CVEs over the past fifteen years — CVE-2011-4140, CVE-2016-6800, CVE-2019-13095 all flag the same validation/serving split. Each got patched correctly. None changed the underlying API surface. That's not organizational failure; it's structural. Backward compatibility requirements fossilize the dangerous default, and each localized patch normalizes the shortcut as acceptable.
What you should do: audit every file-serving endpoint in your Flask applications and confirm that send_file() calls explicitly specify the mimetype parameter. Don't rely on Flask's inference even if your upload validation is rigorous — the serving layer operates on a different trust model than your validation layer. If you're serving user-uploaded content, rename files to safe identifiers (UUIDs or hashes) and set the Content-Disposition header to attachment with a trusted display name. The gap between 'we validate PDFs server-side' and 'we serve files with filename-inferred types' is where this vulnerability lives, and it's a gap you'll only find by tracing the full request lifecycle, not by auditing validation in isolation.