A vulnerability was determined in GPAC 26.03-DEV. This affects the function vobsubreadidx of the file /src/mediatools/vobsub.c of the component MP4Box. Executing a manipulation of the argument numlangs can lead to out-of-bounds read. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized. This patch is called 532097084729a936bcdf6a27c41003f3bd7dc3ff. It is best practice to apply a patch to resolve this issue. Two different commits were applied to fix this issue.
A vulnerability was identified in GPAC up to b40ce70f5. This issue affects the function sgpddelentry of the file src/isomedia/boxcodebase.c of the component MP4Box. Such manipulation of the argument data leads to heap-based buffer overflow. Local access is required to approach this attack. The exploit is publicly available and might be used. The name of the patch is f29f955f2a3b5e8e507caad3e52319f961bf37bf. It is advisable to implement a patch to correct this issue.
A vulnerability was determined in GPAC up to 2.5-DEV. This vulnerability affects the function gfisomnalusamplerewrite of the file src/isomedia/avcext.c of the component MP4Box. This manipulation of the argument naluoutbs causes double free. It is possible to launch the attack on the local host. The exploit has been publicly disclosed and may be utilized. Patch name: f29f955f2a3b5e8e507caad3e52319f961bf37bf. To fix this issue, it is recommended to deploy a patch.
Product: GPAC (MP4Box) Affected: gpac/gpac prior to fix commit (see References) CVE: CVE-2025-60473 CWE: CWE-476 (NULL Pointer Dereference) CVSS 3.1: 4.3 MEDIUM (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L) Reporter: sigdevel <https://infosec.exchange/@sigdevel>
Description: The gffilterinparentchain() function in GPAC's filter session core (filtercore/filterpid.c:2145) walks the filter parent chain to determine whether a given filter is an ancestor of another, and is called during PID initialization from gffilterpidinittask(). When MP4Box inspects a crafted MPEG-2 TS file containing corrupted PMT descriptors, reused PIDs, and malformed PES headers that produce an abnormal PID chain state, the function is reached with a NULL or uninitialized parent filter pointer.
The function dereferences the parent pointer without validating it, attempting a READ at address 0x000000000008 (null+0x8 field offset), resulting in a segmentation fault and process crash (Denial of Service).
Crash is reproducible on the current master branch at the time of discovery. No authentication or special privileges required beyond ability to provide a crafted file.
Reproduction: -Build-opts: --static-build --static-bin --static-modules --enable-debug --extra-cflags="-g -O0" ; -Command: ./MP4Box -info 36gffilterinparentchainfiltercorefilterpidc2145
Asan-log: ==2015443==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f7ec2e52c65 bp 0x519000016d80 sp 0x7fffe9ee7390 T0) ==2015443==The signal is caused by a READ memory access. #0 0x7f7ec2e52c65 in gffilterinparentchain filtercore/filterpid.c:2145 #1 0x7f7ec2e7a796 in gffilterpidinittask filtercore/filterpid.c:4932 #2 0x7f7ec2ec3465 in gffsthreadproc filtercore/filtersession.c:2420
PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/36/36gffilterinparentchainfiltercorefilterpidc2145
References: https://github.com/gpac/gpac/issues/3285 https://www.cve.org/CVERecord?id=CVE-2025-60473 https://infosec.exchange/@sigdevel/116780471059317580
—— Best regards, Alexander A. Shvedov @sigdevel
Product: GPAC (MP4Box) Affected: gpac/gpac prior to fix commit (see References) CVE: CVE-2025-60466 CWE: CWE-825 (Expired Pointer Dereference) CVSS 3.1: 4.3 MEDIUM (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L) Reporter: sigdevel <https://infosec.exchange/@sigdevel>
Description: The gffilterpidgetpacket() function in GPAC's filter session core (filtercore/filterpid.c:6827) retrieves the next available packet from a filter PID for processing by downstream filters such as the inspect filter. When MP4Box inspects a crafted MPEG-2 TS file with corrupted PMT descriptors and abnormal PCR discontinuities that drive the pipeline through PID deletion and re-enqueue paths, gffilterpiddel() frees the 336-byte PID instance at filtercore/filterpid.c:5933.
The inspect filter subsequently calls gffilterpidgetpacket() on the invalidated PID without checking whether the PID object has been released, performing a READ of 8 bytes at address 0x513000002dc0 (start of the freed allocation) and crashing the process (Denial of Service).
Crash is reproducible on the current master branch at the time of discovery. No authentication or special privileges required beyond ability to provide a crafted file.
Reproduction: -Build-opts: --static-build --static-bin --static-modules --enable-debug --extra-cflags="-g -O0" ; -Command: ./MP4Box -info 35gffilterpidgetpacketfiltercorefilterpidc6827
Asan-log: ==1994506==ERROR: AddressSanitizer: heap-use-after-free on address 0x513000002dc0 at pc 0x7fdaa268b8b7 bp 0x7fff42a43b80 sp 0x7fff42a43b78 READ of size 8 at 0x513000002dc0 thread T0 #0 0x7fdaa268b8b6 in gffilterpidgetpacket filtercore/filterpid.c:6827 #1 0x7fdaa2906374 in inspectprocess filters/inspect.c:5218 #2 0x7fdaa26ef401 in gffilterprocesstask filtercore/filter.c:3180
PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/35/35gffilterpidgetpacketfiltercorefilterpidc6827
References: https://github.com/gpac/gpac/issues/3284 https://www.cve.org/CVERecord?id=CVE-2025-60466 https://infosec.exchange/@sigdevel/116780402249845037
—— Best regards, Alexander A. Shvedov @sigdevel
Product: GPAC (MP4Box) Affected: gpac/gpac prior to fix commit 62714f27c64a3d1eb7e880f9eed2d38673cb43ce CVE: CVE-2025-60464 CWE: CWE-476 (NULL Pointer Dereference) CVSS 3.1: 4.3 MEDIUM (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L) Reporter: sigdevel <https://infosec.exchange/@sigdevel>
Description: The gfseiloadfromstateinternal() function in GPAC's SEI loader (filters/seiload.c:225) processes Supplemental Enhancement Information payloads embedded in HEVC and VVC bitstreams transported over MPEG-2 TS. When MP4Box inspects a crafted TS file containing HEVC/VVC streams with malformed NAL units and corrupted PMT descriptors, the NALU demuxer naludmxconfigurepid() frees the codec state buffer at filters/reframenalu.c:370 during PID reconfiguration.
The function subsequently reads 1 byte from the freed 529,176-byte codec state region at address 0x7f7518dceb04 (529,156 bytes inside the freed allocation) without validating whether the buffer has been released, resulting in a heap-use-after-free and process crash (Denial of Service).
Crash is reproducible on the current master branch at the time of discovery. No authentication or special privileges required beyond ability to provide a crafted file.
Reproduction: -Build-opts: --static-build --static-bin --static-modules --enable-debug --extra-cflags="-g -O0" ; -Command: ./MP4Box -info 32filtersseiloadc225ingfseiloadfromstateinternal
Asan-log: ==33468==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f7518dceb04 at pc 0x7f751b19dbf5 bp 0x7ffc77f69500 sp 0x7ffc77f694f8 READ of size 1 at 0x7f7518dceb04 thread T0 #0 0x7f751b19dbf4 in gfseiloadfromstateinternal filters/seiload.c:225 #1 0x7f751b19dbf4 in gfseiloadfromstate filters/seiload.c:265 #2 0x7f751b0ffd02 in naludmxfinalizeauflags filters/reframenalu.c:2360
PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/32/32filtersseiloadc225ingfseiloadfromstateinternal
References: https://github.com/gpac/gpac/issues/3278 https://www.cve.org/CVERecord?id=CVE-2025-60464 https://infosec.exchange/@sigdevel/116778370895014131
—— Best regards, Alexander A. Shvedov @sigdevel
A use-after-free in the gffilterpidinstswap function (/filtercore/filterpid.c) of GPAC Project/MP4Box before 26.02.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted media file.
A use-after-free in the gffilterpidreconfiguretaskdiscard function (/filtercore/filterpid.c) of GPAC Project/MP4Box before 26.02.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted media file.
GPAC Multimedia Open Source Project GPAC Project/MP4Box 2.5-DEV-rev1593-gfe88c3545-master is affected by: Buffer Overflow. The impact is: cause a denial of service (local). The component is: filtercore/filterpid.c (L:574-580): function gffilterpidinstswapdeletetask() improperly accesses freed objects during PID instance swap/delete cleanup, leading to heap use-after-free. The attack vector is: Local (AV:L): a local, authenticated user who processes a specially crafted MPEG-2 TS/MP4 file with MP4Box can trigger the bug during filter teardown (PID instance swap/delete), causing a crash. ¶¶ In GPAC s MP4Box, gffilterpidinstswapdeletetask() in filtercore/filterpid.c may dereference objects after they have been freed when cleaning up PID instances after a swap/delete operation. Crafted inputs (e.g., malformed MPEG-2 TS) can trigger a heap use-after-free and crash; exploitation may be possible.
A use-after-free in the gffilterpidinstswapdeletetask function (/filtercore/filterpid.c) of GPAC Project/MP4Box before 26.02.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted media file.
A NULL pointer dereference in the gffilterinparentchain function (/filtercore/filterpid.c) of GPAC Project/MP4Box before 26.02.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted file.
GPAC MP4Box v2.4 was discovered to contain a NULL pointer dereference in the gfisomaddtrackkind() function at isomedia/isomwrite.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted MP4 file.
A heap buffer overflow in the gfcencsetpssh function (isomedia/drmsample.c) of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
A NULL pointer dereference in the TrackWriter handling component (filters/muxisom.c) of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
Hi David,
On Mon, Jun 08, 2026 at 07:46:07PM -0400, David A. Wheeler wrote: All: I propose that we create a separate mailing list, say "oss-security-vulnerability-reports", for run-of-the-mill vulnerability reports about open source software (OSS). Run-of-the-mill reports would then go there and not to this mailing list "oss-security". This would leave this oss-security" mailing list for general discussions about the topic of OSS security, including discussions about specific publicly known vulnerabilities that are especially noteworthy in some way. Tools that want the full flood could monitor "oss-security-vulnerability-reports".
Here's my rationale.
In short: There are so many OSS projects that it's already dubious to have a single mailing list for OSS vulnerability reports. However, I believe the coming AI vulnpocalypse will make it completely absurd. If we don't do this, I think the human participants will need to unsubscribe from this list sooner or later, and that would be sad. Thank you for bringing this up.
I do indeed see the problem, but I don't like the proposal. Also, for now the increased volume on this list hasn't exceeded its historical pre-AI peak: we had 485 messages in October 2014, but 455 in May 2026. I'm not seeing a mass exodus of subscribers either. There's greater churn - more people are leaving, but at the same time more are joining.
Just by saying to no longer send run-of-the-mill vulnerability reports in here, we won't instantly achieve that. Sure the moderators can stop and re-route them, but that's not an easy job. It's tricky to draw the line between run-of-the-mill and noteworthy.
Rather than tell people to send something to the other list, I ask this:
Whenever practical, please group related vulnerability disclosures into fewer messages (like security advisories) and use helpful Subject lines. Include the project name in a fixed place near the beginning of Subject, and make the Subject specific to the one disclosure rather than generic shared between multiple disclosures.
Example problems:
We got 25 messages on GPAC/MP4Box vulnerabilities in June so far. The Subject lines for them have GPAC/MP4Box in various places after the vulnerability type, whereas someone getting through this would first care what project is affected (is it even relevant to them) and would likely want messages grouped by project - if they have to be separate messages. Ideally, it would be just 2 messages - one on June 1st disclosing 6 issues, and one today disclosing 19 issues.
Conversely, some projects do group related issues, but then what goes into the Subject? We just had another "OpenSSL Security Advisory" a few days ago. It's the same generic Subject line every time. I think it'd be preferable to include some identifying information in there, at least "OpenSSL Security Advisory [9th June 2026]" as the first line says. Many other projects get this right, e.g. with Subject lines containing fixed release version numbers or identifying numbers for advisories or lists of CVEs. This is NOT a dig at Eric Covener (Apache). In fact, I want to praise Eric Covener (Apache) for his effort Indeed.
I greatly appreciate that Apache projects post their CVE disclosures in here, but it does sometimes result in a lot of messages for the same project on the same day. Also sometimes individual CVEs are missed - like for the previous (not the latest) Apache httpd set of CVEs, I spent some time to ensure all were eventually brought in here, as initially some were not. If some CVE disclosures are similarly missed for a less popular Apache project, this would remain unnoticed (maybe already was).
I understand it took time and effort to get the current system working well, but maybe it's time for someone at Apache to start looking into updating the system to group CVE disclosures by project and release.
Ditto for Perl CPAN.
Alexander
A stack overflow in the gfopusreadlength function (mediatools/avparsers.c) of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
A segmentation violation in the TrackSetStreamDescriptor function (isomedia/track.c) of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
A heap buffer overflow in the Opus audio stream parser component of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
A heap use-after-free in the gfnodegettag function (scenegraph/basescenegraph.c) of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
A NULL pointer dereference in the gfmediamapesd function (mediatools/isomtools.c) of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
A heap buffer overflow in the gfopusparsepacketheader function (mediatools/avparsers.c) of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
A NULL pointer dereference in the gfisomcopysampleinfo function (isomedia/isomwrite.c) of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
GPAC MP4Box v2.4 was discovered to contain a floating point exception in the avidmxprocess function (isomedia/isomwrite.c).
An Out-of-Memory in the mp4muxcencinsertpssh function (filters/muxisom.c) of GPAC MP4Box v2.4 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.
Product: GPAC (MP4Box) Affected: gpac/gpac prior to fix commit (2.5-DEV-rev1174-g3017379f1-master) CVE: CVE-2025-52292 CWE: CWE-121 (Stack-based Buffer Overflow) CVSS 3.1: 8.8 HIGH (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) Reporter: sigdevel <https://infosec.exchange/@sigdevel>
Description: When MP4Box processes a crafted MP4 file during DASH segmentation, the fileinprocess() function in filters/infile.c builds a status string for the current file/track using sprintf() into a fixed-size 1024-byte stack buffer (szStatus). If the source path/basename or the values derived from ctx->src expand into an overly long status string, the formatted output exceeds the destination buffer.
AddressSanitizer reports a stack-buffer-overflow at filters/infile.c:700, a WRITE of size 1811 into the szStatus object allocated in the fileinprocess() stack frame. The crash is reachable while MP4Box processes a crafted MP4 file through DASH/file-list handling.
Crash is reproducible on the current master branch at the time of discovery. No authentication or special privileges required beyond ability to provide a crafted file.
Reproduction: -Build-opts: CC="gcc -fsanitize=address -g" CXX="g++ -fsanitize=address -g" ; -Command: ./MP4Box -dash 1000 /dev/null 1poc.mp4
Asan-log: ==2331746==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f37a4e18bf0 at pc 0x56076a64df94 bp 0x7ffc2cb8d280 sp 0x7ffc2cb8ca20 WRITE of size 1811 at 0x7f37a4e18bf0 thread T0 #0 0x56076a64df93 in vsprintf (/home/user/target/mp4boxdyn/gpac/bin/gcc/MP4Box+0x9bf93) (BuildId: 654ddade294ab0279dd2744403a0c06a089af997) #1 0x56076a64f18e in sprintf (/home/user/target/mp4boxdyn/gpac/bin/gcc/MP4Box+0x9d18e) (BuildId: 654ddade294ab0279dd2744403a0c06a089af997) #2 0x7f37a908bec7 in fileinprocess /home/user/target/mp4boxdyn/gpac/src/filters/infile.c:700:3
PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/1/1poc.mp4
References: https://github.com/gpac/gpac/issues/3129 https://www.cve.org/CVERecord?id=CVE-2025-52292 https://infosec.exchange/@sigdevel/116707273214520860
—— Best regards, Alexander A. Shvedov https://github.com/sigdevel
Product: GPAC (MP4Box) Affected: gpac/gpac prior to fix commit (46be5f928660530d5332cd2f1d177208737558ef) CVE: CVE-2025-55651 CWE: CWE-476 (NULL Pointer Dereference) CVSS 3.1: 4.3 MEDIUM (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L) Reporter: sigdevel <https://infosec.exchange/@sigdevel>
Description: When MP4Box imports a truncated or malformed MP4 file, the isomedia channel-setup path can pass a NULL UUID pointer into gfisomgetuserdatacount() in isomedia/isomread.c. The function does not check the pointer for NULL before using it in a comparison against stored user-data UUIDs.
AddressSanitizer reports a SEGV caused by a READ memory access at address 0x000000000000 (the zero page) at isomedia/isomread.c:2754, reached via isorsetupchannel() while MP4Box declares tracks from the crafted file.
Crash is reproducible on the current master branch at the time of discovery. No authentication or special privileges required beyond ability to provide a crafted file.
Reproduction: -Build-opts: CC="gcc -fsanitize=address -g" CXX="g++ -fsanitize=address -g" ; -Command: ./MP4Box -add 4poc.mp4 -new /dev/null -split-size 5000000
Asan-log: ==37461==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f113ed946fc bp 0x7f113be5fd00 sp 0x7ffef7913440 T0) ==37461==The signal is caused by a READ memory access. #0 0x7f113ed946fc in gfisomgetuserdatacount isomedia/isomread.c:2754 #1 0x7f113f6ff701 in isorsetupchannel filters/isoffinload.c:731 #2 0x7f113f70c220 in isordeclaretrack filters/isoffinload.c:1180
PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/4/4poc.mp4
References: https://github.com/gpac/gpac/issues/3155 https://www.cve.org/CVERecord?id=CVE-2025-55651 https://infosec.exchange/@sigdevel/116710512103919834
—— Best regards, Alexander A. Shvedov https://github.com/sigdevel
Product: GPAC (MP4Box) Affected: gpac/gpac prior to fix commit (ff8249a407685d00ceb5f4d2a798b9cad195140e) CVE: CVE-2025-55659 CWE: CWE-476 (NULL Pointer Dereference) CVSS 3.1: 4.3 MEDIUM (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L) Reporter: sigdevel <https://infosec.exchange/@sigdevel>
Description: When MP4Box splits/remuxes a crafted, truncated MP4 file, invalid negative-timestamp handling during range estimation can leave the composition-time-to-sample entries pointer in an invalid or NULL state. cttsboxwrite() in isomedia/boxcodebase.c does not check this pointer before dereferencing it while writing the ctts box during final muxing.
AddressSanitizer reports a SEGV caused by a READ memory access at address 0x000000000000 (the zero page) at isomedia/boxcodebase.c:464, reached via the box-writing chain (gfisomboxwritelisting / gfisomboxwrite) while MP4Box closes the output file.
Crash is reproducible on the current master branch at the time of discovery. No authentication or special privileges required beyond ability to provide a crafted file.
Reproduction: -Build-opts: CC="gcc -fsanitize=address -g" CXX="g++ -fsanitize=address -g" ; -Command: ./MP4Box -add 5poc.mp4 -new ./test -split-size 500
Asan-log: ==1926241==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7faf284d6c18 bp 0x511000015bc0 sp 0x7fff5c0b2210 T0) ==1926241==The signal is caused by a READ memory access. #0 0x7faf284d6c18 in cttsboxwrite isomedia/boxcodebase.c:464 #1 0x7faf28565469 in gfisomboxwritelisting isomedia/boxfuncs.c:2154 #2 0x7faf28565469 in gfisomboxwrite isomedia/boxfuncs.c:2204
PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/5/5poc.mp4
References: https://github.com/gpac/gpac/issues/3156 https://www.cve.org/CVERecord?id=CVE-2025-55659 https://infosec.exchange/@sigdevel/116710743410087676
—— Best regards, Alexander A. Shvedov https://github.com/sigdevel
Product: GPAC (MP4Box) Affected: gpac/gpac prior to fix commit (ff8249a407685d00ceb5f4d2a798b9cad195140e) CVE: CVE-2025-55657 CWE: CWE-476 (NULL Pointer Dereference) CVSS 3.1: 4.3 MEDIUM (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L) Reporter: sigdevel <https://infosec.exchange/@sigdevel>
Description: When MP4Box imports a crafted MP4 file containing an unsupported vvc16 sample description box inside stsd, the VVC configuration write path can receive a NULL configuration pointer. gfodfvvccfgwritebs() in odf/descriptors.c does not validate that this pointer to the VVC configuration NAL unit data is non-NULL before dereferencing it.
AddressSanitizer reports a SEGV caused by a READ memory access at address 0x000000000000 (the zero page) at odf/descriptors.c:1267, reached via gfodfvvccfgwrite() / isorreadercheckconfig() while MP4Box checks the track configuration of the crafted file.
Crash is reproducible on the current master branch at the time of discovery. No authentication or special privileges required beyond ability to provide a crafted file.
Reproduction: -Build-opts: CC="gcc -fsanitize=address -g" CXX="g++ -fsanitize=address -g" ; -Command: ./MP4Box -add 6poc.mp4 -new ./test -split-size 500
Asan-log: ==1913270==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f04ff48fdda bp 0x511000011fc0 sp 0x7ffe2aad65b0 T0) ==1913270==The signal is caused by a READ memory access. #0 0x7f04ff48fdda in gfodfvvccfgwritebs odf/descriptors.c:1267 #1 0x7f04ff49094b in gfodfvvccfgwrite odf/descriptors.c:1284 #2 0x7f04ffd3a75d in isorreadercheckconfig filters/isoffinreadch.c:1114
PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/6/6poc.mp4
References: https://github.com/gpac/gpac/issues/3157 https://www.cve.org/CVERecord?id=CVE-2025-55657 https://infosec.exchange/@sigdevel/116710754169365223
—— Best regards, Alexander A. Shvedov https://github.com/sigdevel
Product: GPAC (MP4Box) Affected: gpac/gpac prior to fix commit (ff8249a407685d00ceb5f4d2a798b9cad195140e) CVE: CVE-2025-55660 CWE: CWE-121 (Stack-based Buffer Overflow) CVSS 3.1: 4.3 MEDIUM (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L) Reporter: sigdevel <https://infosec.exchange/@sigdevel>
Description: When MP4Box dumps a crafted MP4 file containing a malformed, non-self-delimited Opus packet (e.g. an invalid odd packet length), gfopusreadlength() in mediatools/avparsers.c does not sufficiently validate the Opus packet size before writing the computed length back into the packet header structure.
AddressSanitizer reports a stack-buffer-overflow at mediatools/avparsers.c:11140, a WRITE of size 2 overflowing the pckh stack object (offset 568) allocated in gfinspectdumpopusinternal(), reached via gfopusparsepacketheader() while MP4Box dumps the crafted Opus track.
Crash is reproducible on the current master branch at the time of discovery. No authentication or special privileges required beyond ability to provide a crafted file.
Reproduction: -Build-opts: CC="gcc -fsanitize=address -g" CXX="g++ -fsanitize=address -g" ; -Command: ./MP4Box -add 7poc.mp4 -dxml -out /dev/null
Asan-log: ==24222==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7efe3c106638 at pc 0x7efe3ef07226 bp 0x7fff9e395ff0 sp 0x7fff9e395fe8 WRITE of size 2 at 0x7efe3c106638 thread T0 #0 0x7efe3ef07225 in gfopusreadlength mediatools/avparsers.c:11140 #1 0x7efe3ef6e128 in gfopusparsepacketheader mediatools/avparsers.c:11411 #2 0x7efe3f6ce40f in gfinspectdumpopusinternal filters/inspect.c:1830
PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/7/7poc.mp4
References: https://github.com/gpac/gpac/issues/3161 https://www.cve.org/CVERecord?id=CVE-2025-55660 https://infosec.exchange/@sigdevel/116733892068649310
—— Best regards, Alexander A. Shvedov https://github.com/sigdevel