Low Level’s recent video, AI Did This., lands on a headline that is easy to repeat and easy to misunderstand: an AI-assisted system found 21 zero-day vulnerabilities in FFmpeg, one of the most deployed multimedia codebases on the internet. That part is true. The more important part is what made it true.
This was not a chatbot casually glancing at a repository and pronouncing judgment. It was a tightly scoped vulnerability research workflow aimed at a codebase that has already been hammered for years by human auditors, fuzzers, and serious security programs. The breakthrough was not just model quality. It was the combination of model capability, attack-surface selection, staged validation, and concrete proof generation.
That distinction matters because “AI found bugs” can sound like marketing copy, and “AI can now find bugs cheaply in old C code” sounds like a change in the economics of software security. The second framing is much closer to reality.
Why FFmpeg Is Such a Useful Test Case
FFmpeg is not some toy parser sitting in a forgotten GitHub repo. It is foundational plumbing. It handles transcoding, playback, demuxing, muxing, streaming, and media parsing across platforms, products, and services that most users interact with every day. If a browser, streaming platform, media pipeline, or camera workflow touches audio or video, FFmpeg or code very much like it is often somewhere in the chain.
That makes it a particularly important security target. FFmpeg routinely parses complex, attacker-controlled input. That is exactly where memory-unsafe languages become dangerous. As Anthropic notes in its Mythos Preview write-up, this class of work naturally gravitates toward memory safety flaws because critical systems are still built in C and C++, and memory corruption issues remain both consequential and relatively straightforward to validate with tooling such as AddressSanitizer. In other words, this is not an arbitrary benchmark. It is where real risk lives.
Depthfirst’s June 2, 2026 research post makes clear how hostile this environment is for any new vuln-discovery system. FFmpeg spans roughly 1.5 million lines of heavily optimized C, includes decades of parser logic, and has already been subjected to aggressive fuzzing and manual review. Google had already disclosed 13 FFmpeg vulnerabilities through Big Sleep. Anthropic had already reported security findings using Mythos. If you can still produce new bugs here, you are not merely scraping low-hanging fruit.
That is why the Low Level video is worth taking seriously. The story is not that AI can find an occasional crash in a neglected project. The story is that AI-assisted workflows are now demonstrating useful results in a hardened codebase after major defenders have already had a turn.
What Depthfirst Actually Found
According to depthfirst, its production autonomous security agent found 21 zero-day vulnerabilities in FFmpeg at an approximate run cost of $1,000. The published write-up lists a mix of heap buffer overflows, stack buffer overflows, integer overflows, an integer underflow, and a heap underflow spread across demuxers, decoders, protocol handlers, and parsing logic. Several had been present for years. One stack buffer overflow in the service description table implementation dated back to 2003 and had remained latent for 23 years.
That alone should reset a few assumptions.
Security teams sometimes speak as if mature open source infrastructure has already been searched so thoroughly that only exotic nation-state-grade bugs remain. The FFmpeg findings argue for something more uncomfortable. There is still plenty of dangerous code hiding in old, performance-sensitive, memory-unsafe paths, especially where parsing logic, historical compatibility, and protocol complexity intersect.
The standout example from both the Low Level video and the depthfirst write-up is a heap buffer overflow in FFmpeg’s AV1 RTP depacketizer. The trigger path is ugly precisely because it is ordinary. A victim only needs FFmpeg to ingest an attacker-controlled RTSP stream. No bizarre flags. No contrived local lab setup. The published proof-of-concept path is basically ffmpeg -i rtsp://attacker/stream.
The root cause, as depthfirst explains, sits in rtpdec_av1.c. FFmpeg tracks an output cursor while reconstructing AV1 Open Bitstream Units, or OBUs, from RTP packets. The code depends on a simple invariant: if the output cursor advances, the backing packet buffer must have been grown to match. In the temporal delimiter case, that invariant breaks. The code advances the logical write position when skipping one special OBU type, but it does not grow the underlying packet storage before later writes resume. The next write can therefore land well past the end of the heap allocation.
Low Level walks through the same flaw in plainer language. The packet-processing cursor moves forward, but the buffer does not. Later code writes to the new cursor position as if storage had been reserved. It had not. That gap is the vulnerability.
Depthfirst’s write-up goes further and shows why this is not just a theoretical parser bug. With a crafted packet sequence, the overflow yields a fully controlled out-of-bounds write primitive. The researchers then demonstrate a path to program-counter control by grooming the heap so the overwrite reaches a structure containing a function pointer. That is a crucial point. Many AI bug reports die in the valley between “this might crash” and “this is a real security finding.” Here, the published research explicitly crosses that valley.
Not every one of the 21 findings is that severe in practice, and not every media bug instantly becomes remote code execution. But the collection as a whole is enough to establish a trend: even in code that has already lived under fuzzing and review pressure, AI-assisted systems are now surfacing real memory safety issues with reproducible proofs.
The Important Correction: AI Did Not Do This Alone
The title of the video is directionally correct, but incomplete. The more precise claim is that an agentic vulnerability research system, using publicly accessible model capabilities, found the bugs because the humans operating it shaped the work into something models can actually execute.
This is exactly where the Low Level video is strongest. The commentary pushes back on the lazy takeaway that the only thing that matters is access to Anthropic’s gated Mythos model or a five-figure spend budget. The argument is that good results depend less on mystical prompt wording and more on scoping, process, and proof.
That argument is not hand-wavy. It lines up with what Cloudflare and Anthropic both published about their own systems.
Anthropic’s Mythos post describes a relatively simple scaffold: isolate the target project in a container, let the model inspect and run the code, ask multiple parallel agents to focus on different files, and then run a final validation pass to check whether a report is real and interesting. Even that “simple” version is already more than asking a single model session to find bugs in a repo.
Cloudflare’s Project Glasswing post is even more explicit. It says using a model directly as a coding agent is fine when a researcher already has a lead and wants help investigating. It is the wrong shape for high-coverage vulnerability discovery. Their answer was a harness with distinct stages: recon, hunt, validate, gapfill, dedupe, trace, feedback, and report.
Each of those stages addresses a real model failure mode.
Recon gives later agents a coherent architecture view so they do not wander blind through a large codebase. Hunt narrows the task to a specific attack class and scope hint instead of issuing the useless command, “find vulnerabilities in this repository.” Validate introduces adversarial review by using a separate agent whose job is to disprove the original finding. Gapfill compensates for the model’s tendency to repeatedly chase the same classes of bug. Trace asks the operational question that static analysis so often dodges: can attacker-controlled input actually reach this flaw from outside the system? Report turns the result into structured output rather than a blob of vibes.
That is the real story.
If you read the depthfirst post, Cloudflare’s Glasswing lessons, and Anthropic’s Mythos write-up together, a pattern emerges. The model matters. Obviously it matters. But the system wrapped around the model matters just as much, and often more. Narrow scope beats broad aspiration. Independent validation beats self-confidence. Concrete harnesses beat general prompts. Reachability analysis beats crash counts. Many small parallel tasks beat one heroic all-knowing agent.
This should sound familiar to anyone who has done serious engineering work. The magic, once again, is mostly in the discipline.
Why the Economics Just Changed Anyway
None of that should be read as a dismissal. Quite the opposite. If the harness is the story, the economics are still the consequence.
Depthfirst says it found 21 FFmpeg zero-days for roughly $1,000 in compute. Its post explicitly compares that figure to Anthropic’s reported Mythos spend on comparable FFmpeg work. The Low Level video uses that comparison to make a broader point: access to cutting-edge offensive-security-tuned models may improve outcomes, but the cost floor for useful AI-assisted vulnerability research is dropping fast.
That matters because software security has always been shaped by labor economics. Traditional vuln research is expensive, specialized, and slow to scale. Good researchers are scarce. The number of high-risk native codebases is not. If capable systems can now perform recon, code triage, hypothesis generation, harness creation, crash validation, and even early exploitability analysis at much lower marginal cost, more code gets searched more often.
That does not mean every report will be good. In fact, one of the biggest practical risks is the opposite: a flood of false positives and low-value findings that waste maintainer time. Anthropic’s FFmpeg case is a partial exception because its ASan-backed crash oracle gave it unusually clean validation in that specific workflow. Cloudflare, by contrast, is explicit about needing validation and deduplication stages to cut noise at scale, and Low Level calls out the same issue when describing why the proof harness matters. A bug-finding system that cannot prove reachability or reproduce corruption is just a better hallucination engine.
But once those controls are in place, the cost curve changes. The question stops being whether a single elite team can afford to spend weeks manually auditing a parser. The question becomes how many code paths an organization can afford to keep under continuous machine-assisted review.
That is a very different world.
What This Means for Defenders
The easiest reaction to stories like this is to focus only on patch velocity. Patch faster. Triage faster. Compress the window. There is truth in that, but Cloudflare’s write-up makes a useful corrective point: faster is not enough if the architecture around the vulnerable code stays soft.
Cloudflare argues that the hard problem is not merely getting a patch out sooner. It is making exploitation harder even when a bug exists. That means controls in front of the application that reduce reachability. It means segmentation so a flaw in one component does not automatically become a compromise of everything else. It means deployment patterns that let you roll out remediations everywhere a shared component runs, instead of waiting on fragmented ownership and uneven release cycles.
That emphasis on reachability is easy to miss, but it is one of the most useful ideas in the Glasswing write-up. A shared library flaw is not the same thing as an exploitable path in every consumer. Cloudflare’s trace stage exists specifically to answer that question per downstream system. For defenders, that is a reminder not to stop at “we use FFmpeg somewhere.” The real question is where attacker-controlled input crosses into it, under what privileges, and with what containment around the process that handles it.
That advice becomes particularly relevant with FFmpeg because media parsing is so often treated as mundane utility work. It should not be. Any system that ingests untrusted files or remote streams is processing attacker-supplied input. In practice, that means security teams should treat media handling the way they treat every other high-risk parser boundary: inventory where it exists, understand which products or jobs expose it to external input, and put isolation around it proportionate to the blast radius.
If your product accepts user-supplied videos, screen recordings, webcam uploads, or network streams, the parser is part of your attack surface whether or not your application developers remember it exists. If your surveillance stack or broadcast workflow pulls RTSP feeds, your trust assumptions deserve another look. If your organization ships native code that parses complex formats, AI-assisted offensive research is now one more reason to invest in sanitizer-backed testing, fuzzing, and aggressive review of legacy parsing paths before someone else does it for you.
None of this means panic. It means a more adult threat model.
Anthropic’s own conclusion is that these capabilities will likely benefit defenders more than attackers in the long run, much as fuzzers eventually did. That is plausible. But Anthropic also says the transition period may be turbulent, and that is the part most teams should focus on right now. During a transition, the winning side is usually not the one with the best slogan. It is the one that adapted its workflows first.
The Strategic Lesson Is Bigger Than FFmpeg
The Low Level video frames the FFmpeg story as a preview of where vulnerability research is heading, and that framing holds up. The main lesson is not that one company found 21 bugs in one multimedia library. The lesson is that vulnerability discovery is becoming more operationalized.
For years, the mystique around offensive research came from the individual expert: the person with rare intuition, deep systems knowledge, and endless patience for hostile code. That person still matters. But the emerging pattern in these publications is that capability increasingly comes from the combination of expert-designed workflows and machine-scaled execution.
The system does the wide reconnaissance, repetitive code triage, candidate generation, crash confirmation, and proof scaffolding. Humans decide where to point it, how to validate it, what to disclose, how to reason about severity, and which findings actually matter in the real world. This is not the replacement of vulnerability researchers. It is the industrialization of parts of their method.
That shift has an uncomfortable implication for organizations that rely on obscurity, backlog, or assumed attacker cost as informal defenses. If the cost of meaningful bug hunting keeps falling, more targets become worth scanning. More niche protocol handlers become reachable research territory. More old parser code becomes economically interesting again.
FFmpeg is a warning because it is familiar infrastructure. When a codebase that mature still yields 21 new bugs to an AI-assisted system, the safer assumption is that many other mature codebases will too.
So yes, AI did this. But that sentence is too small for what actually happened.
What happened is that a disciplined agentic workflow used current-generation models to search a large, security-critical, memory-unsafe codebase, generate reproducible findings, and demonstrate that the marginal cost of serious vulnerability research is dropping. That is the part defenders, maintainers, and platform teams should remember after the headline wears off.
If there is any comfort here, it is the same comfort the industry eventually found with fuzzing: the tools that accelerate discovery can also accelerate defense, provided the defenders are willing to build the harnesses, workflows, and deployment discipline to use them well. The problem, as usual, is that reality does not wait for the slower side to finish planning.