No CVE Is Not the Same as Patched
A HEIC upload became remote code execution at four of the biggest names in tech because the fix shipped upstream with no advisory for anyone's scanner to match.
The chain no advisory describes
The path is pure transitive trust. OpenAI's forum runs Discourse, Discourse hands HEIC uploads to ImageMagick, ImageMagick links a libheif build whose upstream fix never received a CVE, and Debian therefore never backported it. The bug that put remote code execution on the forum was public and fixed months ago upstream. It simply never entered the tracking system your tooling reads.
Hacktron's "HEIF Heist" reproduced the same exposure at Slack, Meta and GitHub Enterprise for under $3,000 in model tokens, and only Shopify's pipeline detected the thousands of crash-inducing images the work generated. That is the uncomfortable part: the shops most likely to run current dependency discipline still missed it, because the missing input was never a CVE to alert on.
Why "no known CVEs" reads as a lie
Vulnerability scanners key off CVE identifiers. No ID, no match, green result. The vulnerable .so stays on disk regardless, and a Discourse web-update — the upgrade path most teams reach for — patches the application while leaving the vulnerable shared library untouched underneath it.
| Signal | What it reports | What it misses |
|---|---|---|
| CVE-keyed scan | "No known vulnerabilities" | Any upstream fix that shipped without a CVE |
| Discourse web-update | Application updated | The linked libheif .so on disk |
| Binary / SBOM version check | Actual library version present | Nothing — this is the ground truth |
In your stack
Treat "clean scan" as an unproven claim for any decoder in your image-ingest path. The verification that actually holds is the binary version of libheif linked into every service that touches user-uploaded HEIC or HEIF — pulled from the SBOM or the running artifact, compared against the current upstream release. Where it trails, rebuild the base image; a package-manager or web update alone doesn't replace a vendored or transitively pulled library.
Prioritize by exposure: any service that decodes images from untrusted users — forums, avatar uploads, document ingest, an AI agent that fetches and renders images — is in scope first, and internal-only pipelines can wait. But do the inventory now, because the research that found this cost its authors pocket change to run, so the barrier to others reproducing it is effectively gone.
The broader lesson generalizes past this one bug: upstream projects fix security issues without a CVE routinely, and every such fix is invisible to a CVE-only pipeline. The durable answer is a version-truth check in CI, not a bigger CVE feed.
A green vulnerability scan means no CVE matched — it does not mean the vulnerable code left your disk.
What to do
Inventory every service that decodes user-uploaded images through ImageMagick or libheif (HEIC/HEIF paths first) this sprint, and verify the linked libheif by binary or SBOM version rather than trusting CVE-scan output.
Rebuild — do not web-update — affected Discourse and container images from a base carrying a current libheif this sprint.
Add a CI gate that fails builds when an image-decoding dependency's binary version trails upstream this quarter, so 'no known CVE' can never again read as 'patched.'