Security Advisory: CVE-2025-52293 - Memory Safety Violation in GPAC MP4Box HEVC SPS Parser
Processing a crafted MP4 file containing malformed HEVC SPS data with `MP4Box` can trigger a segmentation fault in `gf_hevc_read_sps_bs_internal()`, causing a Denial of Service.
Summary:
The `gf_hevc_read_sps_bs_internal()` function in `media_tools/av_parsers.c` does not safely handle crafted HEVC SPS data while parsing video configuration from a malicious MP4 file. During import and split processing, malformed SPS data reaches the HEVC parser and causes an invalid memory read.
AddressSanitizer reports a `SEGV` caused by a `READ` memory access at `media_tools/av_parsers.c:9309`. The crash occurs while MP4Box processes the crafted file through the isomedia input and NAL replacement/configuration path.
CWE:
CWE classification was not specified in the local MITRE data. This issue is best described as a memory safety violation in HEVC SPS parsing, with an observed out-of-bounds/invalid read leading to SIGSEGV.
Affected Component:
```
media_tools/av_parsers.c:9309
Function: gf_hevc_read_sps_bs_internal()
```
Affected Product:
MP4Box (GPAC Multimedia Open Source Project)
Affected Version:
MP4Box versions 2.4 and earlier (GPAC build at commit: 8a0d5b43c242fe4befb88530e4c9afef37114161)
Attack Conditions:
An attacker supplies a crafted MP4 file containing malformed HEVC SPS NAL units. The issue can be reproduced locally with:
```
./MP4Box -add 3_poc.mp4 -new /dev/null -split-size 5000000
```
No elevated privileges are required. User interaction is required when the victim manually processes the malicious MP4 file, or an automated workflow invokes MP4Box on attacker-controlled media.
Impact:
The immediate observed impact is Denial of Service due to process termination. The local CVE request classifies the issue as a buffer overflow / memory safety violation. The observed ASAN trace shows an invalid read; no evidence of arbitrary code execution was observed.
Fix / mitigation status:
The issue was fixed in GPAC commit:
```
d091c7e92ef0b6497b808e243501f500135f69c4
```
Users should update to a GPAC build containing this commit or later. The parser should validate HEVC SPS bitstream boundaries and reject malformed SPS/NAL data before reading fields from the bitstream.
References:
- Issue: https://github.com/gpac/gpac/issues/3146
- PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/3/3_poc.mp4
- Fix: https://github.com/gpac/gpac/commit/d091c7e92ef0b6497b808e243501f500135f69c4
Credit
@sigdevel
#fuzzing #infosec #security #afl #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media
Winners Announced in 2026's 'International Obfuscated C Code Competition' https://developers.slashdot.org/story/26/06/07/1730236/winners-announced-in-2026s-international-obfuscated-c-code-competition?utm_source=rss1.0mainlinkanon
Oh! Damn. I missed this:
RIP Marcia Lucas, the woman who saved Star Wars in the edit.
For all you AI haters out there đż https://garymarcus.substack.com/p/ais-black-friday
Imagine if they hired a human person who made regular mistakes and the boss just went "Hey... they will learn to do it well if you give it time. It's an investment in the future!"
It is okay to release a F/OSS project where the expected set of users is you.
It is okay to declare that a F/OSS project that you maintain is feature complete and stop.
It is okay to stop writing new code in a F/OSS project and just review patches from other people.
It is okay to stop reviewing patches once other people are familiar enough with the codebase to do so.
It is okay to admit that a F/OSS project that you created has so much technical debt that people would be better off reimplementing it than depending on it (especially if you write down the lessons that they should learn).
It is okay if your F/OSS project doesn't meet the requirements of some potential group of users, as long as no one applies pressure to force them to adopt it.
It is okay to tell a company that depends on your F/OSS project that it's unsupported and they can pay developers to contribute if they really need it.
It's okay to say 'I created this F/OSS project to meet my personal needs, but someone else made something that meets those needs better and so I'll use theirs instead'.
It's okay to say 'I made this F/OSS project as an experiment, and the result was that I learned that this approach is a bad idea'.
New release: #PEbear 0.7.2: https://github.com/hasherezade/pe-bear/releases/
- with important bugfixes and new features:
Almost 25 years ago, I wrote a blog post with the title âjumping ship slowlyâ about leaving Windows (XP was awful, it was mind boggling to me that Vista managed to make people nostalgic for XP). My advice remains the same:
Donât try switching OS first. The OS is the most easily replaceable bit in the stack. Switch applications first. Most âLinuxâ apps are cross platform. Theyâll run on Windows, and the few that donât will run in WSL2. You can switch out apps one at a time, and take the time to get comfortable with the alternatives.
Once youâre comfortable not using any Windows-only apps, changing the OS but using all of the same applications is very easy to do. Changing OS and application stack at the same time is an enormous obstacle.
I believe this is also why a lot of corporate and government Linux migrations fail: they try to change everything at the same time and thatâs too steep a learning curve.
Wired: Meta Silently Added Face-Recognition Code for Its Smart Glasses to Millions of Phones
Code reviewed by WIRED uncovered an unreleased face-recognition system embedded in Metaâs smart glasses platform. Itâs designed to identify people via biometric data stored on usersâ phones.
https://www.wired.com/story/meta-smart-glasses-face-recognition-nametag-connections/
From prompt đto pwned đ˘:
Implementing an LLM in your org? Useful.
Trusting its output? That's how a low-priv user became admin.
Ship the feature, don't extend it your trust.
https://blog.quarkslab.com/from-prompt-to-pwned-chaining-llm-and-web-bugs-to-admin.html
This was a fun Linux kernel bug (though it only existed on >=6.10 and requires access to network namespaces): https://project-zero.issues.chromium.org/496923375
One of those rare bugs where, if you pass a kernel address in the right place, with the right setup, the kernel will just read from that kernel address as if it was userspace memory, and give you the data that was read.
Somebody released a PoC for Firefox CVE-2026-8389, and it works.
The PoC doesn't include a sandbox escape, and claims that poc-win-sbx.html includes the escape. This file was not shared in the repo.
The python server on localhost seems unnecessary, as the exploit web server can surely serve up primer.js the first time that payload.js is requested, and the actual payload.js the second time. đ¤