← Back to Feed CACHED · 2026-10-02 00:20:24 · CACHE_KEY CVE-2026-13523
CVE-2026-13523 · CWE-404 · Disclosed 2026-06-29

GPAC ISOBMFF Parser Decompression Bomb via base_encoding.c

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like handing someone a zip bomb disguised as a movie file, except the blast radius is one process on one box

CVE-2026-13523 is a decompression bomb vulnerability in GPAC's ISOBMFF parser, specifically in src/utils/base_encoding.c. The gf_gz_decompress_payload_ex function inflates compressed ISOBMFF box types (!mov, !mof, !six, !ssx) without enforcing any ratio limit between input and output size. An attacker who can feed a crafted .mp4 file to a local GPAC/MP4Box process can achieve roughly 1000:1 expansion — a 64 KB compressed payload decompresses to 64 MB — exhausting memory and causing a denial-of-service crash. All versions up to and including 26.02.0 are affected. The fix, merged into master on June 1, 2026 (commit 297f2d8d), caps inflate output at 32× the input size.

The vendor's LOW / 3.3 rating is accurate and arguably generous. This is a local-only, low-privilege, availability-only bug in an open-source multimedia CLI tool that most enterprises have never heard of, let alone deployed at scale. The CVSS 4.0 re-score to 4.8 / Medium overreaches — nothing about this vulnerability's blast radius or attack surface justifies a bump. The 1000:1 amplification ratio sounds dramatic but it only kills the gpac/MP4Box process; it does not achieve code execution, privilege escalation, or data exfiltration. Vendor severity matches reality.

"Local decompression bomb in niche media tool — vendor LOW is honest"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Attacker crafts a decompression bomb MP4

The attacker creates a minimal MP4 file containing a compressed ISOBMFF box (e.g., !six / SegmentIndex) with a payload of null bytes compressed at maximum zlib level. The PoC is a trivial 10-line Python script published in GitHub issue #3588. A 64 KB file can decompress to 64 MB or more.
Conditions required:
  • Knowledge of ISOBMFF compressed box types
  • Python or equivalent to generate the payload
Where this breaks in practice:
  • The crafted file only affects GPAC — no other media player or library is vulnerable to this specific vector
STEP 02

Attacker delivers the file to a GPAC process

The attacker must get the crafted .mp4 file processed by a local GPAC binary (MP4Box -info, gpac filter chain, or an application linked against libgpac). This requires local access or the ability to submit media to a pipeline that uses GPAC for processing.
Conditions required:
  • Local access to a host running GPAC or ability to upload media to an automated GPAC-based processing pipeline
  • GPAC ≤ 26.02.0 installed
Where this breaks in practice:
  • GPAC is a niche open-source tool — the vast majority of enterprise hosts do not have it installed
  • Automated media pipelines typically run in containers with cgroup memory limits, which contain the blast
  • The attack vector is local — there is no network-facing GPAC service listening on a port by default
Detection/coverage: Process-level OOM kills or memory spikes in containerized workloads are visible to any host monitoring agent. No CVE-specific scanner signatures exist.
STEP 03

GPAC inflates the payload, exhausting memory

The vulnerable gf_gz_decompress_payload_ex function enters its inflate loop, doubling the output buffer geometrically from 4096 bytes up to GF_UINT_MAX. The process consumes excessive memory until it is OOM-killed by the kernel or the host becomes unresponsive. Impact is limited to availability of the GPAC process and, at worst, temporary host-level memory pressure.
Conditions required:
  • Unpatched GPAC ≤ 26.02.0
  • No external memory limit (cgroup, ulimit) constraining the process
Where this breaks in practice:
  • Impact is Availability: Low per the CVSS vector — a single process crash, not a persistent condition
  • Restarting the process or killing it immediately restores service
  • No persistence, no lateral movement, no data impact
Detection/coverage: Standard host monitoring (memory usage alerts, OOM-killer logs) catches this. No specialized detection required.
03 · Compensating Control

1
LOW 3.3→IGNORE 0.0
SEVERITY REDUCED
Apply cgroup / ulimit memory caps to all GPAC processes — Set a hard memory ceiling (e.g., MemoryMax=512M in a systemd unit or Docker --memory 512m) on any GPAC worker. This prevents the decompression bomb from consuming host memory — the process is OOM-killed cleanly within its sandbox. No SLA pressure — this is a LOW finding, so treat as backlog hygiene, but if you run GPAC in production pipelines, this is good practice regardless.
2
LOW 3.3→IGNORE 0.0
SEVERITY REDUCED
Upgrade GPAC to a build containing commit 297f2d8d — The fix caps inflate output at 32× input size. Since no tagged release includes this fix yet, you'll need to build from the master branch post-June 1, 2026. Per the noisgate remediation SLA for LOW findings, this can be treated as backlog — no formal deadline, but aim to pick it up within 365 days or whenever your next GPAC version bump occurs.
3
LOW 3.3→LOW 2.0
Validate input files before GPAC processing — If your pipeline accepts user-uploaded media, add an upstream validation step (e.g., ffprobe or mediainfo sanity checks) that rejects files with suspiciously small sizes relative to declared content. This is defense-in-depth, not a direct mitigation — it raises the bar but a determined attacker can craft files that pass superficial checks.
What doesn't work
  • WAF / network IDS — GPAC has no network listener; there is no HTTP or TCP traffic to inspect. Network-layer controls are irrelevant.
  • EDR behavioral detection — The exploit manifests as a legitimate process allocating memory. No shellcode, no injection, no suspicious syscalls. EDR will not flag this as malicious unless you write a custom rule for GPAC memory spikes.
  • File-type blocking at email/web gateway — MP4 files are ubiquitous legitimate content; blanket-blocking them is impractical and the crafted file is a valid MP4 container.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. Not listed in CISA KEV. No GreyNoise or Shadowserver scanning activity. EPSS 0.0016 (bottom ~15th percentile) confirms negligible real-world interest.
Proof of ConceptPublic. A 10-line Python PoC is embedded directly in GitHub issue #3588 by reporter HMF2021. It generates a compressed !six box achieving ~1000:1 expansion. No weaponized exploit repos found on GitHub or pocindex.io — the bug is DoS-only with no code execution path.
EPSS Score0.0016 — effectively zero probability of exploitation in the next 30 days. Consistent with a local-only DoS in niche software.
KEV StatusNot listed. No CISA deadline applies.
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L — Local access, low privileges, no user interaction, unchanged scope, availability-only impact rated Low. Every dimension constrains severity. CVSS 4.0 scored 4.8 (Medium) but the v3.1 score is more representative of real impact.
Affected VersionsGPAC ≤ 26.02.0 (all branches). Component: src/utils/base_encoding.c, ISOBMFF Parser. Also affects libgpac when linked by third-party applications.
Fixed VersionMaster branch post-commit 297f2d8d (merged June 1, 2026). No tagged release yet incorporates the fix. Ubuntu/Debian packages for all supported releases are listed as *needs evaluation*. No distro backport available as of October 2026.
Scanning / ExposureGPAC has no default network listener — it is a CLI tool and library. Zero exposure on Shodan/Censys/FOFA. Attack surface is limited to hosts with GPAC installed that process untrusted media files.
Disclosure TimelineReported May 28, 2026 (GitHub issue #3588). PR #3589 merged June 1, 2026. CVE reserved June 28, 2026. Published June 29, 2026.
ReporterHMF2021 (GitHub). No affiliated organization disclosed. Responsible disclosure via GitHub issue tracker.

Sources.

  1. CIRCL Vulnerability Lookup — CVE-2026-13523
  2. GitHub Issue #3588 — GPAC decompression bomb report + PoC
  3. GitHub PR #3589 — Zip bomb protection patch
  4. Ubuntu Security — CVE-2026-13523
  5. Debian OSV — CVE-2026-13523
  6. Threat Radar — CVE-2026-13523 analysis
  7. GPAC Wiki — MP4Box documentation
05 · The Call

Final Verdict
= UNCHANGED to LOW (3.3/10)

Why this verdict

  • Local-only, low-impact DoS: The CVSS vector is AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L — every axis is constrained. No confidentiality or integrity impact. Availability impact is rated Low, meaning a transient process crash, not a sustained outage.
  • Niche installed base: GPAC is an open-source multimedia CLI tool and library. It is not a standard component on enterprise workstations, servers, or appliances. Fewer than 1% of enterprise hosts in a typical 10,000-seat fleet will have GPAC installed. This dramatically limits the reachable attack population.
  • No network attack surface: GPAC does not expose a network service. Exploitation requires local file delivery to a GPAC process. Even in automated media pipelines, the attacker must first compromise the upload path and the pipeline must specifically use GPAC (not FFmpeg, GStreamer, or other dominant alternatives).
  • Role multiplier: GPAC does not occupy any high-value deployment role. It is not an identity provider, hypervisor, CI/CD component, backup system, kernel-mode agent, database engine, or network edge appliance. (a) *Low-value role (developer workstation, hobbyist):* most common deployment — DoS kills one CLI invocation, zero blast radius. (b) *Typical role (media processing server):* process crash in a containerized pipeline, auto-restarts, blast radius limited to one transcoding job. (c) *High-value role:* no plausible high-value-role mapping exists for GPAC. The worst realistic outcome is a transient service disruption of a single media processing worker. No domain/fleet/supply-chain/safety impact. No severity floor applies.
  • PoC is trivial but impact ceiling is hard: The public PoC confirms exploitability but the maximum achievable outcome is process-level OOM — there is no path to code execution, privilege escalation, or persistence from this bug.

Why not higher?

The bug is DoS-only with Low availability impact, requires local access, affects niche software with near-zero enterprise footprint, and has no path to code execution or lateral movement. No high-value deployment role maps to GPAC, so no severity floor overrides apply. Upgrading to MEDIUM would overstate the risk to any realistic enterprise environment.

Why not lower?

A working public PoC exists and the decompression bomb technique is well-understood — any attacker with local access to a GPAC installation can trivially trigger the bug. In the narrow scenario of an automated media ingest pipeline using GPAC without container memory limits, the DoS could disrupt a production workflow. IGNORE would understate the risk for the small population of organizations that actually run GPAC in processing roles.

06 · Verification

Crowdsourced verification payload.

Run this on any host where GPAC/MP4Box may be installed. No special privileges required — it checks the installed version and, if present, inspects the patched source function. Execute as: bash check_cve_2026_13523.sh

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-13523 Checker — GPAC decompression bomb (base_encoding.c)
# Output: VULNERABLE / PATCHED / UNKNOWN
set -euo pipefail

VULN_CVE="CVE-2026-13523"
FIXED_COMMIT="297f2d8d"

# Check if gpac or MP4Box is installed
if command -v MP4Box >/dev/null 2>&1; then
    GPAC_BIN="MP4Box"
elif command -v gpac >/dev/null 2>&1; then
    GPAC_BIN="gpac"
else
    echo "UNKNOWN — GPAC/MP4Box not found on this host"
    exit 2
fi

# Get version
VERSION=$($GPAC_BIN -version 2>&1 | head -5 || true)
echo "Detected: $GPAC_BIN"
echo "$VERSION"
echo "---"

# Extract version number (e.g., 26.02.0)
VER_NUM=$(echo "$VERSION" | grep -oP '\d+\.\d+\.\d+' | head -1 || echo "")

if [ -z "$VER_NUM" ]; then
    echo "UNKNOWN — could not parse GPAC version string"
    exit 2
fi

# Compare version: 26.02.0 and below are vulnerable
# But patch is only in master (no tagged release yet), so any released version is vulnerable
MAJOR=$(echo "$VER_NUM" | cut -d. -f1)
MINOR=$(echo "$VER_NUM" | cut -d. -f2)

if [ "$MAJOR" -lt 26 ] || ([ "$MAJOR" -eq 26 ] && [ "$MINOR" -le 2 ]); then
    # Check if running a patched build from master
    # Try to find if the binary contains the ZLIB_INFLATE_MAX_MULTIPLIER constant
    if strings "$(command -v $GPAC_BIN)" 2>/dev/null | grep -qi "inflate.*multiplier\|inflate_max_mult"; then
        echo "PATCHED — $VULN_CVE: GPAC $VER_NUM appears to contain the inflate multiplier fix"
        exit 0
    fi
    echo "VULNERABLE — $VULN_CVE: GPAC $VER_NUM (affected: <= 26.02.0, fix commit $FIXED_COMMIT not in any tagged release)"
    exit 1
else
    echo "PATCHED — $VULN_CVE: GPAC $VER_NUM is newer than affected range"
    exit 0
fi