PT-2026-47173 · Undefined · Undefined

Published

2026-06-07

·

Updated

2026-06-07

·

CVE-2026-39218

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
Posting this because I think it deserves more technical discussion than it's been getting.
depthfirst (a security startup) ran an autonomous AI agent against FFmpeg's ~1.5M lines of C. It returned 21 confirmed zero-days, each with a reproducible PoC. Nine CVEs assigned so far (CVE-2026-39210 through CVE-2026-39218). The rest are fixed but unnumbered. Total cost: approximately $1,000 for the run.
Most are heap or stack overflows in parsers and demuxers — TS demuxer, VP9 decoder, service-description-table parser (that last one dates to 2003, 23 years undetected). The FFmpeg maintainers have been responsive and fixes are shipping.
Technical concerns I'm sitting with:
  1. If a startup can produce 21 PoCs for $1,000, what's the equivalent capability for a well-resourced threat actor running this at scale across hundreds of OSS projects simultaneously?
  2. The 23-year dormancy issue — these bugs survived decades of fuzzing campaigns. What does that tell us about the fundamental limits of traditional SAST/DAST against memory corruption in C codebases?
  3. Disclosure pipelines — the FFmpeg project is handling this well, but what happens when AI agents start generating hundreds of PoC disclosures per week across the ecosystem? The CVE numbering system is already slow.
I previously covered Microsoft's MDASH agentic AI system finding 16 Windows zero-days here if you want more background on the enterprise side of this trend: https://www.techgines.com/post/microsoft-mdash-agentic-ai-security-windows-vulnerabilities
Curious what people think, especially anyone who's worked on FFmpeg's codebase or on AI-assisted vuln research. Is the cost curve the thing we should be most focused on here?

Related Identifiers

CVE-2026-39218

Affected Products

Undefined