Reading the patch[0] for libheif the bug which lead to the vuln was around bounds checking for image overlays. the container can have multiple images and you can compose them in the output.

heif also supports rotating, cropping, alpha channels, thumbnails and a ton of other features that a web forum where a user is uploading photos or screenshots doesn't need.

It's a much, much larger attack surface than plain old school JPEG.

I'd suggest rather than wait for the next bug to appear in this or another image lib to keeping things simple - stick to plain JPEG and handle image conversion in the client (wasm in the browser) if you really need to support users uploading iphone images.

Media decoding is so hard - there have been tons of bugs in ffmpeg and imagemagick and the core libs. You really need to think about how much of it you expose via a web server

[0] https://github.com/strukturag/libheif/commit/85e21ad44eba931...

Or OpenAI can adequately sandbox / access control the backend compute so RCE isn’t a path to lateral movement

Defense in depth here would have been adequate

I agree, but imagemagick is kind of the worst of the bunch, graphicsmagick is a lot better and libvips significantly so. Ffmpeg primarily suffers a lot from “we need to support the video format used on a washing machine display used in 1981 and only sold ten units”. It’s quite a large vector for attacks.