A Platform Mitigation Does Not Patch Every Dependency

Summary

Blocking an exposed image-processing route can contain a vulnerability while a library fix moves through downstream dependencies. Vercel’s September 18 account of the libheif incident shows why teams need separate evidence that a mitigation is active and that the deployed dependency is repaired.

Key Updates

• The exposure crossed several dependencies. Vercel describes reproducing remote code execution through Next.js image optimization, which called sharp, libvips and then libheif. The upstream advisory lists libheif 1.22.0 through 1.23.1 as affected by a buffer overflow when decoding crafted images.
• Containment depended on the deployment path. Vercel says it disabled AVIF optimization in its managed Image Optimization Service on August 13. The August 25 Next.js security release also disabled AVIF optimization while the upstream fix propagated, providing a mitigation for affected self-hosted applications. Its release notes identify 15.5.24 and 16.3.3 as patched Next.js releases for this issue.
• The library fix was a separate release. The libheif advisory, published August 25, lists 1.23.2 as the patched version. Vercel’s September 18 article looks back at that incident and its coordinated response. A released fix does not establish that every downstream build has incorporated it.

Why It Matters

A framework feature can expose native code several dependencies away from the application. A managed service may block the vulnerable route while a self-hosted deployment or another image-processing service follows a different path. The package name alone does not establish whether an application is exposed.

Containing a reachable path and repairing the underlying dependency are different outcomes. Both can reduce risk, but they require different evidence. This incident makes the deployed runtime the useful place to check remediation. The sources do not establish how widely the issue was exploited, and a successful upgrade cannot rule out earlier compromise.

Builder Takeaway

Trace one deployed image-processing route to its decoder.

Record where untrusted images enter, which service handles them, and the framework and native-library versions in the deployed artifact. Check current advisories for your supported release line; the August versions above are historical fixes for this issue, not a complete security baseline. Verify the relevant update or mitigation in a safe environment, including expected image behavior and the versions actually deployed. Record whether the evidence establishes containment, a dependency fix, or both.