Submit #840159: GPAC <= 26.02.0 Uncontrolled Resource Consumption

# GPAC has an uncontrolled decompression vulnerability in gf_gz_decompress_payload_ex

## Supplier

GPAC is an open-source multimedia framework.

- Website: https://gpac.io/
- Source code: https://github.com/gpac/gpac

## Affected Versions

- GPAC 26.02.0: affected
- GPAC master: affected at the time of testing

The vulnerability is present in both the current GPAC 26.02.0 release and the current master branch.

## Vulnerability File

```text
src/utils/base_encoding.c
src/isomedia/box_funcs.c
```

## Vulnerability Description

GPAC contains an uncontrolled decompression issue in `gf_gz_decompress_payload_ex`. The function inflates attacker-controlled compressed data into a heap buffer that starts at 4096 bytes and is repeatedly doubled with `gf_realloc` until the zlib stream ends or the buffer approaches `GF_UINT_MAX`. The API does not accept a maximum output size and does not enforce a compression-ratio limit.

In the ISOBMFF parser, compressed top-level boxes such as `!mov`, `!mof`, `!six`, and `!ssx` are automatically decompressed before the decompressed payload is parsed as the corresponding normal box. An attacker can therefore provide a small MP4 file containing a compressed box that expands to a very large in-memory payload, causing excessive memory consumption and denial of service.

The vulnerable decompression loop is:

https://github.com/gpac/gpac/blob/v26.02.0/src/utils/base_encoding.c#L252

https://github.com/gpac/gpac/blob/v26.02.0/src/utils/base_encoding.c#L283

```c
while (d_stream.total_in < data_len) {
err = inflate(&d_stream, Z_NO_FLUSH);
if (err < Z_OK || err == Z_NEED_DICT) {
e = GF_NON_COMPLIANT_BITSTREAM;
break;
}
if (err==Z_STREAM_END) break;

if (size >= GF_UINT_MAX/2 - 1)
size = GF_UINT_MAX - 1;
else
size *= 2;
*uncompressed_data = (char*)gf_realloc(*uncompressed_data, sizeof(char)*(size+1));
if (!*uncompressed_data) return GF_OUT_OF_MEM;
d_stream.avail_out = (u32) (size - d_stream.total_out);
d_stream.next_out = (Bytef*) ( *uncompressed_data + d_stream.total_out);
}
```

The ISOBMFF compressed-box path is:

https://github.com/gpac/gpac/blob/v26.02.0/src/isomedia/box_funcs.c#L207

https://github.com/gpac/gpac/blob/v26.02.0/src/isomedia/box_funcs.c#L236

```c
else if (type==GF_ISOM_BOX_TYPE_CSIX) {
do_uncompress = 1;
type = GF_ISOM_BOX_TYPE_SIDX;
}
...
e = gf_gz_decompress_payload_ex(compb, compressed_size, &uncomp_data, &osize, GF_FALSE);
```

There is a limit on the compressed input size in the ISOBMFF parser, but no limit on the decompressed output size. As a result, a small compressed payload can force the process to allocate tens or hundreds of megabytes, or more, depending on available memory.

• Source: ⚠️ https://github.com/gpac/gpac/issues/3588
• User: Fantasy (UID 69897)
• Submission: 05/28/2026 04:15 (1 month ago)
• Moderation: 06/28/2026 09:47 (1 month later)
• Status: Accepted
• VulDB entry: 374531 [GPAC up to 26.02.0 ISOBMFF Parser base_encoding.c data amplification]
• Points: 20