Audit pinned dependencies for known-unfixed CVEs on their reachable API surface

[crippledgeek]

Summary

mediaforge pins ~110 dependencies at fixed versions, and nothing checks whether any of those
versions carries a known, unfixed vulnerability. #27 found one only because libaom happened to be
the recipe under change: the pinned aom predated the fix for CVE-2026-56208, a heap overflow
reachable through FFmpeg's default lag-in-frames. Nothing would have surfaced that if av1 had not
been touched for an unrelated reason.

The same blind spot covers every other pin.

Why this is not just "bump things"

Two properties of this tree make a naive audit produce the wrong answer, and both were established
during #27:

Affectedness often is not published. All three libaom CVEs are "Awaiting Analysis" in NVD with
no CPE version ranges. The only way to answer "is our pin affected" was to read the source and find
that ctrl_set_layer_id gains its bounds check at v3.14.0 and lacks it at 3.8.2, 3.10.0 and 3.13.1.

Reachability decides severity here. Of those three CVEs, two (CVE-2026-56209/-56210, SVC
layer-id) are not reachable through mediaforge at all, because FFmpeg's libaomenc.c never calls
AV1E_SET_SVC_LAYER_ID. Only the LAP one matters. An audit that stops at "our version is below the
fixed version" would have produced three findings where one is real, and would eventually train
everyone to ignore it.

So the useful unit of work is: for each pinned dependency, which API surface does FFmpeg (or the
consuming recipe) actually call, and does a known unfixed flaw sit on that path.

Suggested scope

Start where the exposure is highest rather than alphabetically:

• The TLS/crypto arms (openssl, gnutls, libressl, mbedtls, gmp, nettle). These terminate TLS for
  every https:// input the built FFmpeg opens.
• The demuxer/decoder-side libraries that parse untrusted input (libbluray, libopenmpt, libxml2 via
  dav1d/librist, libwebp, libtiff, libpng).
• The other two fetch_git recipes, librtmp and libplacebo, which is where this suggestion
  originated.

Conflict this will surface

Profiles pin dependencies contemporary with each FFmpeg release. #27 established that this rule and
"do not ship a known reachable vulnerability" can be in direct conflict, and resolved it there by
pinning forward with the reason recorded in recipes/video/av1.sh and a pointer from each profile.
Whatever this audit finds will hit the same conflict repeatedly, so it is worth deciding once
whether that per-recipe exception is the standing pattern or whether the contemporaneity rule needs
restating.

Acceptance

• A recorded pass over the prioritised set above, with a per-dependency verdict of affected /
  not-affected / not-reachable, and the evidence for each
• Pins bumped where a reachable unfixed flaw is found, with the reason recorded at the pin the way
  av1.sh does it
• A decision on whether this becomes a recurring check (a check-updates extension is the obvious
  home, since it already walks every recipe) or stays a one-off

Follow-up to #27 (closed via #30). Related: #19, which would give the pins integrity but says
nothing about their currency.