This is why compilation flags exist. You can compile software to not include features, and the code is removed, decreasing the attack surface. But it’s not really ffmpegs job to tell you which compilation flags you should pick, that is the responsibility of the people integrating and deploying it into the systems (Google).
ffmpeg in fact comes with a default makefile that excludes a bunch of modules for various reasons, some for license incompatibility issues and some because they're not considered to be of production grade (so theyre released for testing etc.). It's nuts to suggest continuing to ship something with known vulnerabilities without, at minimum, removing it from the default build and labelling it as having known issues. If you don't have the resources to fix the bug that's understandable, but own up to it and tell people to be careful with that module.
AI generated
AI tools were apparently used for locating the bugs but the reports were real and legit.
But it really should have been fixed by Google, since they brought it up.
It would be great if Google could fix it, but ffmpeg is very hard to work in, not just because of the code organization but because of the very specialized knowledge needed to mess around inside a codec. It would be simpler and probably better for Google to contribute development funding since they depend on the software so heavily.
You might remember libav, a now long dead ffmpeg fork from some years back. It was well intentioned and had good programmers involved, but it just couldn't handle the technical demands of developing something like ffmpeg. ffmpeg is a messed up project in some ways but it's extremely impressive. Being able to find bugs (say by fuzzing) is much different from being able to fix them sanely. If you're google and have infinite hardware like they do, you can do more fuzzing than anyone else, and that's valuable to any project with this type of exposure.
It’s not really ffmpeg’s job to pick a sandboxing software (docker, seccomp, selinux, k8s, borg, gvisor, kata),
Those approaches would be ridiculous bloat, the idea is just supply some kind of wrapper that runs the codec in a chrooted separate process communicating through pipes under ptrace control or however that's done these days.
but instead the responsibility of the people integrating and deploying the software.
The ffmpeg CLI tool is in fact an integration of the software and should probably use the wrapper, at least for suspect modules. Note that all major web browsers already do something like this and have done it for years, for exactly this reason.