CVE-2026-9572: Gpac MP4Box Information Disclosure Flaw

CVE-2026-9572 Overview

CVE-2026-9572 is a memory leak vulnerability [CWE-401] in GPAC up to version 2.4.0. The flaw resides in the Media_GetSample function within src/isomedia/media.c, a component of the MP4Box utility. Manipulation of the cat argument triggers improper memory release, leading to a memory leak condition. The attack requires local access and authenticated low-privilege execution. A public exploit has been disclosed, and upstream maintainers have committed patch e79c5cbe8b3fed27f4854ec229457d30c96206f1 to address the issue.

Critical Impact

Local attackers with low privileges can trigger memory exhaustion in GPAC's MP4Box utility by supplying crafted input to the Media_GetSample function, degrading availability over time.

Affected Products

• GPAC up to and including version 2.4.0
• MP4Box component within GPAC distributions
• Applications and pipelines embedding the GPAC isomedia library

Discovery Timeline

• 2026-05-26 - CVE-2026-9572 published to NVD
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-9572

Vulnerability Analysis

The vulnerability lives in Media_GetSample inside src/isomedia/media.c, which is responsible for retrieving media samples from MP4 container structures. When processing a crafted input through the cat argument path, the function allocates memory without releasing it under specific control-flow conditions. The underlying issue is a malloc(0) boundary case where data_size + padding_bytes evaluates to zero, producing undefined behavior in the allocator and orphaning previously held resources.

The issue is classified under [CWE-401] (Missing Release of Memory after Effective Lifetime). Repeated invocation of the vulnerable code path causes incremental memory growth in the calling process. While the immediate confidentiality and integrity impact is none, sustained exploitation results in availability degradation of the MP4Box process or any long-running service that links against libgpac.

Root Cause

The patch introduces an explicit check on the computed allocation size before invoking gf_malloc, gf_realloc, or the registered sample_alloc_cbk. Prior to the fix, the code path proceeded with allocation requests of size zero, which the C standard treats as implementation-defined behavior. This led to inconsistent state tracking between (*samp)->data and (*samp)->alloc_size, resulting in leaked allocations and undefined behavior in the fuzzed code path identified in GitHub Issue #3557.

Attack Vector

Exploitation requires local access to a system running a vulnerable GPAC build. An attacker supplies a malformed MP4 file or crafted concatenation input through the cat argument of MP4Box. No user interaction is needed beyond invoking the tool against attacker-supplied input. The attack does not yield code execution; it produces resource exhaustion that can disrupt media processing workflows, batch transcoding services, or fuzzing harnesses linking the library.

// Patch excerpt from src/isomedia/media.c - prevents UB malloc(0)
		if (! (*samp)->data)
			(*samp)->alloc_size = 0;

		size_t size_to_alloc = data_size + mdia->mediaTrack->padding_bytes;
		if (!size_to_alloc)
			return GF_IO_ERR;

		/*and finally get the data, include padding if needed*/
		if (ext_realloc) {
			(*samp)->data = mdia->mediaTrack->sample_alloc_cbk(size_to_alloc, mdia->mediaTrack->sample_alloc_udta);
		} else if ((*samp)->alloc_size) {
			(*samp)->data = (char *) gf_realloc((*samp)->data, size_to_alloc );
			if ((*samp)->data) (*samp)->alloc_size = data_size + mdia->mediaTrack->padding_bytes;
		} else {
			(*samp)->data = (u8 *) gf_malloc(size_to_alloc);
		}
		if (! (*samp)->data) return GF_OUT_OF_MEM;

Source: GitHub Commit e79c5cb. The fix introduces size_to_alloc and returns GF_IO_ERR when the computed size is zero, eliminating the leak path.

Detection Methods for CVE-2026-9572

Indicators of Compromise

• Sustained memory growth in MP4Box processes or services linking libgpac when handling untrusted MP4 inputs.
• Process termination by the OOM killer on hosts performing automated media processing.
• Presence of GPAC binaries reporting version 2.4.0 or earlier on systems exposed to user-supplied media files.

Detection Strategies

• Inventory installed GPAC versions across endpoints and build servers, comparing against the patched commit e79c5cbe8b3fed27f4854ec229457d30c96206f1.
• Run AddressSanitizer or LeakSanitizer builds of GPAC against suspect inputs to confirm leak signatures in Media_GetSample.
• Monitor invocations of MP4Box with the -cat argument in shell history and process audit logs.

Monitoring Recommendations

• Establish baseline resident set size (RSS) metrics for media processing workers and alert on anomalous linear growth.
• Enable process accounting (auditd on Linux) to capture command-line arguments passed to MP4Box.
• Correlate file upload events with subsequent GPAC invocations in centralized logging.

How to Mitigate CVE-2026-9572

Immediate Actions Required

• Apply commit e79c5cbe8b3fed27f4854ec229457d30c96206f1 from the upstream GPAC repository, or upgrade to a release containing the fix.
• Restrict MP4Box execution to trusted local users and remove the SUID bit if present.
• Run media processing workloads under resource-limited containers or systemd units with MemoryMax enforced.

Patch Information

The fix is published as commit e79c5cbe8b3fed27f4854ec229457d30c96206f1 in the GPAC GitHub repository. The patch is referenced in GitHub Issue #3557 and tracked as VulDB Vulnerability #365631. Rebuild downstream packages and container images after pulling the patched source.

Workarounds

• Avoid processing untrusted MP4 inputs with the cat operation until the patch is deployed.
• Wrap MP4Box invocations with ulimit -v or cgroup memory limits to bound the impact of a leak.
• Validate input files with a stricter parser before passing them to GPAC in automated pipelines.

# Build patched GPAC from source
git clone https://github.com/gpac/gpac.git
cd gpac
git checkout e79c5cbe8b3fed27f4854ec229457d30c96206f1
./configure
make -j$(nproc)
sudo make install

# Verify the installed version
MP4Box -version

# Optional: constrain runtime memory for media workers
systemd-run --scope -p MemoryMax=512M MP4Box -cat input.mp4 -out output.mp4