Severity by source
Network-delivered file triggers crash on user action (UI:R); read-only overflow limits impact to heap disclosure (C:L) and crash (A:L), with no write capability (I:N).
Lifecycle Timeline
1Description PRE-NVD
AnalysisAI
Heap-based buffer overflow in GPAC's MP4Box Opus packet parser exposes file-processing pipelines to heap memory disclosure and application crash when handling a crafted MP4 containing a malformed Opus audio track. Processing a specially constructed file via MP4Box's XML dump mode (-dxml) triggers an out-of-bounds READ of 1 byte beyond a 3-byte heap allocation inside gf_opus_parse_packet_header() at av_parsers.c:11326, with adjacent heap memory potentially leaked as a secondary consequence. No public exploitation has been confirmed (not in CISA KEV), but a functional PoC MP4 file is publicly available on GitHub, lowering the barrier for targeted abuse in automated media-ingestion workflows.
Technical ContextAI
GPAC is an open-source multimedia framework widely used for MP4 file analysis, packaging, and inspection; its MP4Box command-line tool is the primary attack surface here. The vulnerable function gf_opus_parse_packet_header() in media_tools/av_parsers.c is responsible for parsing the Opus codec's Table of Contents (TOC) byte and subsequent header fields in an Opus audio packet embedded within an ISOBMFF/MP4 container. The root cause (CWE-122, Heap-based Buffer Overflow) is insufficient validation of the input buffer length before indexing into header fields when the Opus TOC code is 3 - a value that encodes a variable-length packet count and implies a larger header footprint than a minimal 3-byte heap region. The sample allocated by Media_GetSample() is too small, and the read at offset +3 goes one byte beyond the end of that allocation. The execution path is: MP4Box -dxml → dump_isom_opus (filedump.c:1501) → gf_inspect_dump_opus_internal (filters/inspect.c:1830) → gf_opus_parse_packet_header (av_parsers.c:11326). The issue is confirmed reproducible with AddressSanitizer on the master branch at the time of discovery.
Affected ProductsAI
All versions of GPAC (MP4Box) prior to the fix commit ff8249a407685d00ceb5f4d2a798b9cad195140e on the gpac/gpac repository are affected. No CPE string or discrete version boundary was provided in the available intelligence; the vulnerability was present on the master branch at the time of discovery. The issue is specific to the MP4Box tool within the GPAC framework when the -dxml dump path is exercised on MP4 files containing Opus audio tracks. The oss-security advisory is available at https://seclists.org/oss-sec/2026/q2/913 and the upstream GitHub issue is tracked at https://github.com/gpac/gpac/issues/3160.
RemediationAI
The upstream fix is available as commit ff8249a407685d00ceb5f4d2a798b9cad195140e in the gpac/gpac repository; however, a versioned tagged release incorporating this fix has not been independently confirmed at time of analysis. Users should build GPAC from source at or after this commit, or monitor the official GPAC release channel for a patched version. As a compensating control for automated pipelines, avoid invoking MP4Box with the -dxml flag on untrusted or externally sourced MP4 files until a patched release is available - this directly removes the vulnerable code path (dump_isom_opus → gf_inspect_dump_opus_internal → gf_opus_parse_packet_header). Sandboxing MP4Box invocations (e.g., via seccomp, bubblewrap, or container isolation) will limit the blast radius of a successful crash or heap leak. Input validation at ingestion - rejecting MP4 files with Opus tracks from untrusted sources - is a further compensating measure. References: https://github.com/gpac/gpac/issues/3160 and https://seclists.org/oss-sec/2026/q2/913.
Share
External POC / Exploit Code
Leaving vuln.today