Severity by source
File delivered remotely triggers crash only when user invokes MP4Box on it; PR:N and UI:R appropriate; A:L for process crash; no C or I impact.
Lifecycle Timeline
1Description PRE-NVD
AnalysisAI
Divide-by-zero crash in GPAC's MP4Box tool allows denial of service when processing a crafted MP4 file containing a malformed Opus audio track header. The function gf_opus_parse_packet_header() in media_tools/av_parsers.c:11479 fails to validate that nb_frames is non-zero before performing arithmetic (max = header->nb_frames - 1), triggering a SIGFPE along the Opus dump path. A public proof-of-concept file is available, and no authentication or special privileges are required - only the ability to supply a crafted file to the tool. No confirmed active exploitation (not in CISA KEV); impact is limited to process crash with no code execution potential identified.
Technical ContextAI
GPAC is an open-source multimedia framework; MP4Box is its primary ISO Base Media File Format (ISOBMFF/MP4) command-line processing tool. The vulnerable function gf_opus_parse_packet_header() parses Opus audio codec packet headers embedded within MP4 container tracks. CWE-369 (Divide by Zero) manifests because the function computes arithmetic on the nb_frames field - specifically max = header->nb_frames - 1 - without first asserting nb_frames > 0. When the field is zero or malformed in a crafted file, this produces a Floating Point Exception (SIGFPE) caught by AddressSanitizer at av_parsers.c:11479. The full call chain is: dump_isom_opus (applications/mp4box/filedump.c:1501) → gf_inspect_dump_opus_internal (filters/inspect.c:1830) → gf_opus_parse_packet_header (media_tools/av_parsers.c:11479), meaning the crash is reached via the Opus inspection/dump path invoked by flags such as -dxml. No CPE strings were provided in the input; affected versions are those prior to commit ff8249a407685d00ceb5f4d2a798b9cad195140e on the GPAC master branch.
Affected ProductsAI
GPAC MP4Box versions built from the master branch prior to commit ff8249a407685d00ceb5f4d2a798b9cad195140e are confirmed affected. The crash was reproduced on the master branch at the time of discovery as noted in the oss-security disclosure. No specific released version range (e.g., 2.x.x through 2.y.z) is independently confirmed from the available data - affected version bounds are inferred from the upstream commit reference alone. No CPE strings were included in the provided input. The GitHub issue tracker at https://github.com/gpac/gpac/issues/3159 and the oss-security advisory at https://seclists.org/oss-sec/2026/q2/920 are the primary public references.
RemediationAI
Build GPAC from a source revision at or after commit ff8249a407685d00ceb5f4d2a798b9cad195140e from the upstream repository at https://github.com/gpac/gpac. A released patched version with an official tag is not independently confirmed at time of analysis - consult the GPAC releases page and the GitHub issue at https://github.com/gpac/gpac/issues/3159 for confirmation of a tagged release incorporating this fix. As a compensating control, avoid invoking MP4Box with -dxml or other Opus-dump-path flags on untrusted or user-supplied MP4 files containing Opus audio tracks; this eliminates the specific code path that reaches the vulnerable function. If automated pipelines must process untrusted MP4 files with GPAC, isolate MP4Box invocations within a sandboxed environment (e.g., seccomp profile, unprivileged container) to contain crash impact and prevent crash-loop amplification. Pre-filtering input files for Opus tracks is not a reliable mitigation since it requires parsing the same MP4 container that may contain malformed data.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today