CVE-2026-73433

The 106/107-byte trigger condition for this AVI strd parser vulnerability isn't a sign of sophisticated attacker engineering — it's a structural fingerprint of how sequential parse-without-validate patterns fail. The counter starts with the strd chunk size, decrements by 98 bytes (the FUJIFILM header structure), then another 10 bytes (date field normalization), and underflows only at that precise boundary. The arithmetic does this automatically; any fuzzer or valid file near the boundary would eventually hit it. This is a timebomb, not a targeted weapon. What makes this more dangerous than CVSS 6.6 suggests is the heap information disclosure path. The underflow enables a read overflow that continues until null-termination — which in GStreamer's buffer allocation model means the disclosure window extends to the next heap boundary, not the next metadata field. Combined with aggressive buffer reuse in media pipelines, the adjacent data may contain parsed content from previously processed files in the same session. Open a crafted AVI after processing something sensitive, and the heap disclosure carries that content. The auto-plugging behavior is the critical exposure factor. When any application uses playbin or decodebin (the default pipelines for media playback), avidemux gets instantiated automatically with zero user interaction. This means file browsers generating thumbnails, chat platforms creating previews, and backup tools validating media libraries all expose this attack surface invisibly. The CVSS model assumes a single-file, single-user paradigm that doesn't account for how many downstream processes treat AVI parsing as a trusted, invisible subroutine. The read/write dual overflow should not be treated as separate CVEs — they're the same structural failure (sequential parse without prior bounds validation) expressing itself through different code paths. More importantly, this parsing pattern almost certainly exists elsewhere in GStreamer's demuxer ecosystem. The gst-plugins-good codebase contains multiple avi/mp4/mov parsers that decrement running counters against fixed struct sizes without pre-validation. Historical CVE patterns (CVE-2021-3492, CVE-2021-3493, CVE-2022-2127) all followed the same counter-arithmetic-into-underflow trajectory across different format parsers — each patched in isolation, never prompting a systematic audit of this class. Defenders should treat this as a canary. The practical priority isn't just patching this instance — it's identifying every other demuxer element that follows the same fixed-offset decrement pattern without bounds checking upfront. The FUJIFILM metadata extension itself is essentially dead code: a vendor-specific format from a company that exited consumer cameras, parsed by plugin code that nobody maintains. That maintenance abandonment is itself a risk factor — security assumptions coded years ago have rotted while the code kept compiling.

Reviewed through automated stages and approved by a human before publication.