Recent reports about Anthropic’s Claude Mythos model autonomously discovering 16-year-old zero-days in legacy C/C++ libraries like FFmpeg highlight a fundamental shift in systems security.

Years ago while building a multimedia engine and an MP4 composer for a video editing suite I realized something that stayed with me. An MP4 is never just a video file. It is a highly structured container built from hierarchical data boxes. I noticed then that the format’s udta and free atoms could easily be misused to hide massive amounts of arbitrary data right in plain sight.

I did not chase the security implications at the time but the recent AI news brought those memories rushing back. Because no one suspects a simple video file it is the perfect camouflage. If automated models can find deeply buried parser vulnerabilities in hours rather than months relying purely on software patches is no longer a viable defense.

This accelerates the need to re-evaluate how system architectures handle untrusted external inputs. Here is how this container structure is exploited and why strict process isolation is now a mandatory architectural decision.

Hiding in Plain Sight

A media file is not executable by itself. To compromise a system an attacker first has to get their malicious data into the target’s memory and wait for a parsing bug to trigger it.

The MP4 standard makes delivering that data incredibly easy. The ISO Base Media File Format dictates that every box starts with a length field and a four-character type. Crucially the specification allows parsers to ignore and skip any unknown box types they encounter.

This means an attacker can take arbitrary machine code, shellcode or Return-Oriented Programming (ROP) gadgets and stash them inside a custom udta (User Data) or free (Free Space) box. A standard parser will read this attacker-controlled data as opaque information and skip it during playback.

The video plays perfectly. The container simply acts as a delivery vehicle ensuring the parser processes the attacker-controlled bytes during normal operation.

The Parser Trap: Memory Corruption

Having the payload in memory accomplishes nothing on its own. The attacker needs to trigger a vulnerability to force the system to mishandle that data.

Media players rely on parsing engines like FFmpeg or GStreamer. These are incredibly complex C/C++ libraries that require manual memory management. When the parser reads an MP4 box it looks at the 32-bit size header to allocate the appropriate memory buffer.

Attackers craft intentionally malformed boxes to trigger mathematical errors during this allocation phase. The most common trap is an integer overflow.

  • The attacker provides a massive size value that causes the parser’s allocation calculation to wrap around to a tiny number.
  • The parser allocates an undersized buffer.
  • The parser then tries to copy the massive box payload into that tiny space.

This is a well-documented pattern. The infamous Android Stagefright vulnerability (CVE-2015-1538) was a heap overflow triggered by an integer overflow in the MP4 tx3g atom. More recently GStreamer’s MP4/MOV demuxer suffered a similar vulnerability (CVE-2024-47537) where an integer overflow in the sample table parser led to out-of-bounds writes.

Hijacking the Player

A buffer overflow is a catastrophic failure of the application’s boundaries.

In the past an attacker could simply overflow the buffer, overwrite the instruction pointer and direct the computer to execute the payload stashed in the custom udta box. Modern operating systems deploy mitigations like Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) so an attacker usually cannot just jump straight into the udta box and execute raw bytes like it is an .exe file.

Instead modern exploits use techniques such as Return-Oriented Programming (ROP) and in some JIT-heavy environments JIT spraying. Rather than executing the MP4 data directly the attacker uses the out-of-bounds write to corrupt control-flow data (like return addresses, vtables or function pointers). They use this corrupted flow to chain together tiny instruction snippets already present in executable code or JIT-generated regions effectively scripting the program’s own instructions against itself.

In practice the MP4 payload is used to shape the memory layout and supply the attacker-controlled gadgets. The media player ends up following this malicious control flow rather than playing the video file.

The Mythos Threat: An Automated Adversary

Legacy media parsers have always been an attractive hunting ground for these types of bugs but the timeline for discovering them is shrinking.

Anthropic recently launched Project Glasswing to test an unreleased frontier AI model called Claude Mythos Preview specifically for defensive cybersecurity research. Early testing indicates a highly compressed timeline for vulnerability discovery.

According to public reporting Mythos autonomously discovered a 27-year-old memory corruption bug in OpenBSD and a 16-year-old flaw in FFmpeg that previous automated analysis tools had missed. When tested against Firefox 147’s JavaScript engine the model successfully turned existing vulnerabilities into working shell exploits over 180 times.

Models like Mythos demonstrate that automated exploit-finding systems are becoming highly capable reducing the time from vulnerability discovery to exploit generation from weeks down to hours.

Defense in Depth: The Case for Process Isolation

We can no longer rely purely on patching C/C++ parsers. If we accept that legacy parsers will inevitably contain zero-days our architecture must assume compromise from the start.

The most resilient defense when building media frameworks or applications is strict process isolation. Best practice dictates you do not run a media parser in the same process as your core application logic.

Industry leaders already mandate this approach:

  • Apple uses out-of-process XPC services for ImageIO parsing on macOS.
  • Modern browsers use highly restricted multi-process renderer sandboxes.
  • Android isolates media parsing into dedicated low-privilege services (such as the mediaserver family) protected by strict SELinux policies and Binder IPC to communicate with the rest of the OS.

This is especially critical for modern on-device ML frameworks. Before an edge AI model can perform computer vision tasks a parser (like OpenCV or an FFmpeg wrapper) must decode the user’s MP4 into raw frames. If that media ingest pipeline runs in the same process as the inference runtime a maliciously crafted video can hijack the control flow before the neural network even sees the first frame. The model logic and hardware access must reside in a completely different trust domain than the raw parsing code.

By decoupling the parser you contain the blast radius. Even if a malformed MP4 successfully triggers an integer overflow and hijacks the execution flow the attacker finds themselves trapped in a dead-end low-privilege environment with zero network access and no path to exfiltrate user data.

The Takeaway

Media formats are not safe by default.

If you are building platforms that ingest, process or serve user-uploaded media you must treat every file as hostile. The MP4 container is a historically attractive attack surface for parser bugs so process isolation is the safest default. Understanding this architecture is no longer just about optimizing streaming bitrates; it is a fundamental security requirement.