FFmpeg zero-days show how parser bugs become remote code execution

At a glance

What this is: depthfirst says its autonomous security agent found 21 zero-day vulnerabilities in FFmpeg, including a remotely reachable AV1 RTP path that can lead to code execution.

Why it matters: For IAM and security teams, this is a reminder that parser exposure in widely deployed infrastructure creates high-impact runtime risk even when access paths look ordinary and unauthenticated.

By the numbers:

• depthfirst says its agent discovered 21 zero-day vulnerabilities in FFmpeg.
• 183-byte packet was enough to trigger the AV1
• The flaws had been latent for 15 to 20 years in some cases, according to depthfirst.

👉 Read depthfirst's analysis of 21 FFmpeg zero-days and the AV1 RTP exploit path

Context

FFmpeg is a media parsing engine, so its security posture depends on how safely it handles attacker-controlled input at runtime. When a library parses complex file formats and network streams for browsers, ingest pipelines, and streaming infrastructure, memory-safety mistakes become exposure points rather than isolated coding defects. This article focuses on that parser risk, and the fact that some of the failures survived for years shows how difficult deep code audit remains.

The identity angle is indirect but real: systems that ingest remote media often rely on service accounts, API keys, and pipeline credentials to reach content sources. If those credentials are exposed through a parser exploit path, the issue becomes both a software vulnerability and an access-governance problem. That combination is typical of modern media and platform infrastructure, not an unusual edge case.

Key questions

Q: What breaks when a media parser loses sync between input and output pointers?

A: The parser can write attacker-controlled bytes outside the allocated buffer because it no longer knows which input has already been consumed and which output space has been reserved. That turns a normal processing branch into memory corruption, and in some layouts it can overwrite control data such as callbacks or object metadata.

Q: Why do network-exposed parsers create outsized exploitation risk?

A: They turn content handling into a remote attack surface. If a service processes untrusted streams automatically, the attacker does not need credentials or interactive access, only a payload that reaches the vulnerable code path. That makes parser bugs especially dangerous in ingest, transcode, and media relay workflows.

Q: How can teams tell whether a parser bug is likely to be exploitable?

A: Look for three signals: the attacker controls the input shape, the corrupted write reaches adjacent heap objects, and the overwritten data influences a later dereference or free operation. If all three are present, the issue is more likely to be a real exploitation primitive than a simple crash.

Q: What should security teams do first when a parser flaw affects a reachable service?

A: Contain the reachable path by restricting input, disabling unnecessary parsing features, and prioritising internet-facing services that automatically process untrusted content. Then validate the active binary and redeploy any application that carries its own OpenSSL copy before returning the service to normal operation.

Technical breakdown

How parser state drift turns skipped input into memory corruption

The AV1 RTP depacketizer maintains a write cursor that must stay aligned with allocated output space. In the reported flaw, the code skips a Temporal Delimiter OBU by advancing the cursor without allocating matching memory or moving the input pointer forward. That breaks the core invariant of packet assembly: every output byte should be backed by allocated space and every consumed input byte should be accounted for once. When the next OBU is processed, the write begins far beyond the buffer boundary.

Practical implication: Treat parser cursor integrity as a security property and test every skip, continue, and length-handling branch for desynchronisation.

Why heap layout makes a buffer overflow exploitable

A heap overflow becomes dangerous when the overwrite can reach metadata or function pointers adjacent to the data buffer. The article describes FFmpeg’s allocator placing the packet buffer near AVBuffer bookkeeping structures, including a free callback pointer. Because the overflow begins at a predictable offset and the data written is attacker-controlled, the corruption is not just a crash risk. It can become a control-flow primitive if the overwritten pointer is later dereferenced during cleanup or reallocation.

Practical implication: Review allocator adjacency and object lifetime together, then prioritise overwrite paths that can influence callback fields or reference-counted metadata.

Why long-lived media parsers accumulate latent attack surface

FFmpeg has absorbed decades of format support, refactors, and performance optimisations. That kind of codebase tends to accumulate subtle length, sign, and bounds errors in demuxers, depacketisers, and decoder paths where attacker input is highly structured and difficult to fuzz exhaustively. The article’s mix of old and recent flaws shows that security maturity in a parser does not eliminate risk once it becomes a stable dependency in many downstream systems.

Practical implication: Use continuous fuzzing, targeted code review, and dependency triage for parser-heavy components instead of assuming age equals safety.

Threat narrative

Attacker objective: The attacker wants to execute code remotely through a media stream that appears normal to the consumer application.

1. Entry occurs when an attacker supplies a crafted RTSP stream or packet sequence to FFmpeg through an ordinary media ingestion path.
2. Escalation happens when the AV1 depacketizer advances its output cursor without allocating matching memory, letting attacker-controlled bytes overwrite adjacent heap objects.
3. Impact is achieved when the corrupted free callback is invoked during buffer release, producing control-flow hijack and potential remote code execution.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Media parsers are now part of the exposure surface, not just the application stack. When a library like FFmpeg processes untrusted remote content, the security boundary moves into the parser itself. That means a simple media fetch can become an attack path even when the surrounding service is otherwise well governed. Practitioners should treat parser dependencies as externally reachable attack surfaces, not passive utilities.

The named concept here is parser cursor desynchronisation. This is the failure mode where an output pointer, input pointer, and allocation boundary no longer move together. Once that happens, every later assumption about safe write location becomes unreliable. The article’s AV1 case shows how one skipped branch can create a controlled overwrite from ordinary network input, so teams need code review and fuzzing that specifically target skip logic and length handling.

Exploitability depends on memory layout as much as on the bug itself. A buffer overflow becomes materially worse when it can reach a function pointer, refcounted object, or cleanup callback nearby in memory. That is why parser hardening cannot stop at “no crash in testing.” Security teams should ask whether a flaw can reach control data, not just whether it can be reproduced.

Long-lived infrastructure software needs a governance model for latent defects. The mix of old and recent FFmpeg issues shows that age does not eliminate vulnerability density in complex parsers. For identity and platform teams, the practical lesson is to include third-party parser libraries in dependency risk reviews, especially where service accounts or ingestion credentials expose the parsing path to the internet.

This kind of issue validates security testing that proves reachability, not just theory. The value in the article is not only that bugs were found, but that they were driven to reproducible proof-of-concept inputs. Practitioners should prioritise validation methods that separate theoretical code smell from actually exploitable runtime paths, because that is where remediation effort belongs.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• For a broader view of machine identity governance, see Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

Parser-heavy infrastructure now needs the same governance discipline as exposed identity workflows. When untrusted media reaches shared services, the real question is not whether the code compiles cleanly but whether the surrounding access path is tightly bounded. That is where identity and runtime controls intersect, because a parser exploit becomes more damaging when the service identity has broad downstream reach.

The operational signal is clear: teams should review who can point production workloads at external streams, who can update ingest destinations, and which service identities can reach parser-backed systems. Least privilege, network isolation, and stronger approval around external content sources reduce the blast radius when a memory-safety flaw appears.

Parser cursor desynchronisation: this is the class of defect where input consumption and output allocation fall out of step, creating a controlled write path from otherwise normal traffic. In practice, that means fuzzing and code review need to focus on branches that skip, truncate, or reparse attacker input, because those are the places where reachability turns into compromise.

For practitioners

• Harden remote media ingestion paths Inventory every place FFmpeg or similar parsers consume external streams, files, or uploaded media, then classify those paths as internet-reachable attack surfaces rather than routine dependencies.
• Fuzz skip and length branches Build test cases around continue paths, length fields, negative sizes, and nested OBU or packet parsing logic, because desynchronisation bugs often hide in branches that appear to discard input safely.
• Review callback adjacency in heap objects Check whether parser buffers can overflow into function pointers, refcounted metadata, or cleanup hooks, and prioritise remediation where overwrite distance reaches executable control data.
• Gate external stream access with identity controls Restrict which service accounts, API keys, and pipeline credentials can reach untrusted media sources, and pair that with least privilege so a parser exploit cannot reuse broad access.

Key takeaways

• FFmpeg’s zero-days show that widely deployed parser code can still hide remote code execution paths in ordinary workflows.
• The exploitable pattern is not just a buffer overflow but a parser state failure that lets attacker-controlled data overrun adjacent memory.
• Security teams should combine dependency review, fuzzing, and identity scoping so a parser defect cannot turn external content into broad runtime compromise.

Key terms

• Parser Cursor Desynchronisation: A parser cursor desynchronisation happens when the code that reads attacker-controlled input and the code that writes output stop advancing together. The result is often an out-of-bounds write or read because the parser no longer has a correct view of what has already been consumed and what space is actually allocated.
• Heap Buffer Overflow: A heap buffer overflow happens when a process writes past the end of a memory buffer allocated on the heap. In NGINX-style worker processes, that corruption can crash the process, corrupt adjacent state, or, in the right conditions, become a route to code execution.
• Remote Code Execution Primitive: A remote code execution primitive is a flaw or exploit condition that gives an attacker a building block for running code on a target system from a remote input source. It may not be a complete exploit by itself, but it provides a reliable path to control flow or memory corruption.
• Attack Surface Code: Attack surface code is the part of a system that directly handles untrusted input, such as parsers, protocol handlers, and decoders. These components deserve special scrutiny because they sit at the boundary between external data and internal trust, where small mistakes can have large security consequences.

What's in the full report

depthfirst's full article covers the exploit mechanics and proof-of-concept detail this post intentionally leaves at a higher level:

• The exact packet construction and heap-shaping sequence used to turn the AV1 RTP flaw into a control-flow primitive
• The per-vulnerability breakdown across the 21 findings, including the older latent issues and the newly introduced regressions
• The reproducible proof-of-concept inputs and the command-line context that make the remote path reachable in practice
• The exploitability discussion around adjacent allocator objects and why the callback overwrite was reliable

👉 depthfirst's full article includes the PoC reasoning, heap layout discussion, and the broader vulnerability set across FFmpeg components.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect runtime exposure to access control decisions across modern programmes.