When the robots came for our parsers

GStreamer security in the age of LLMs

GStreamer Conference 2026

11 October 2026

Sebastian Dröge <sebastian@centricular.com>

The current situation

LLMs are actively looking for CVEs

  • A flood of security vulnerability reports this year affecting
    many open source projects
    • LLM-based tooling easily finds dozens of security issues
    • Well-known victims: Linux kernel and curl

  • Lots of discussions about their usefulness, validity, and how to handle them

  • GStreamer is a natural target too

    • Used in safety-critical areas
    • Parses complex data formats from untrusted sources

And indeed, we are affected

center

So what changed?

Past Present
Written by Humans: organizations*, individuals LLMs: mostly individuals, security companies,
sometimes supported by AI companies
Report Manually confirmed, concise Verbose, noisy, inaccurate
PoC Rare, just a description Almost always
Amount Couple per year Couple per week
Severity Usually minor Same
Process Usually 90-day responsible disclosure Same

* e.g. GitHub Security Lab (GHSL), the Zero Day Initiative (ZDI)

But aren't the LLM reports all garbage?

  • Contrary to common belief: almost all are valid

    • Bonus: they usually come with a minimal PoC

  • But: verbose reports full of noise and inaccuracies

    • E.g. 3000 words for a 1-line fix, or lower severity than reported
    • Sometimes contain bonus issues in the middle

  • In summary: real issues, but the volume is immense

Types of issues

  • Almost all OOB accesses and integer overflows in untrusted data parsers

    • Demuxers, bitstream parsers, decoders, RTP depayloaders
    • Together ~85% of the reports

  • Rarely anything else: 1 use-after-free, few resource exhaustion, 5 logic bugs

  • Almost everything minor (DoS), with one RCE

    • Not particularly interesting: mostly what a fuzzer would find
  • Both in ancient and new code
    • H.266/VVC parser (2024): 8, qtdemux (2002): 6, wavparse (2001): 3

What about Rust?

  • So far, no security reports against any of our Rust code

    • Not even logic bugs in the rewritten elements

  • Most of these bugs would not exist in Rust code

    • Memory safety issues and data races
    • Of course, there's still the possibility of issues!
  • We're fixing old code that is going away, sometimes with
    safer and better alternatives already available
    • Side note: distros don't ship most of our Rust code yet

Why don't you run your own fuzzers or LLM-based tooling?

  • We've been running OSS-Fuzz for years
    • Recently increased coverage considerably
    • Also: started experimenting with LLMs for code review

  • It finds issues regularly, fixed as normal bugfixes

    • All minor, no CVE bureaucracy
    • Adds to the workload but has lower priority

  • Doesn't find the same issues as the incoming LLM reports

The cost and the incentives

What each report costs

  • The work we'd do for any bug report
    • Validate: extract info, reproduce with PoC, understand the problem
    • Fix, check for regressions and similar code
  • Plus security overhead: advisory, CVE bureaucracy, last-minute merge
  • Plus security pressure: disclosure deadline & inflated importance
  • A lot of urgent work for mostly minor issues

Opportunity cost

  • Time spent on security issues takes away time from other work

    • New features, user-facing defects, Rust rewrites, general improvements

  • Security work is always urgent and visible, other work is not

  • Ironically, the flood of issues starves work that prevents many of them

Asymmetric efforts

  • Finding and reporting something: easy and low-effort
    • Point LLM at code, get PoC and issue report text

  • Handling one report: a lot of work

    • Validate, fix, advisory, CVE bureaucracy

  • Finding and fixing everything: not realistic

Perverse incentives

  • Nobody cares about security! CVEs became a marketing tool

  • Many security researchers care about CVEs for their CV

  • Security companies care about advertising their services and products

  • Distros care about compliance: no open CVEs

  • AI companies care about marketing their product

  • Big Tech support researchers for findings, not projects for fixes

  • ... and we get to do the actual work everybody else benefits from

Our process

What counts as security-relevant

  • If reported as such: almost anything
    • DoS or worse, triggerable in normal usage (e.g. file playback)

  • If found by us: almost nothing unless major issue

    • Otherwise: normal bugfix, no bureaucracy

  • Why: almost any bug is potentially a security bug

    • Treating them all as security would leave no time for anything else

  • Should security-relevance depend on who found the issue?

Contrast: the Linux kernel

  • The kernel approach: everything is potentially security-relevant and gets a CVE

  • Each release fixes 100+ CVEs

  • Basically a DoS on downstream, but forces people to update

  • If everybody did the same, the whole system would just collapse

  • So where do we draw the line?

The process

center

Distros and downstream patch problem

  • Distros usually only patch for CVEs
    • But bugfix releases fix lots of bugs of similar severity all the time
      • And many more user-visible bugs!

  • Example: a maintainer asked which fix in our advisory was for the CVE

  • A second change in the same advisory fixed the same issue elsewhere

    • No CVE: (initially) considered not relevant and too risky to patch

  • Checking the compliance box instead of fixing the bug

The way forward

So what do we do?

  • This is taking a lot of time away from other important work
    • Including the work that would prevent such issues

  • The flood is not going away anytime soon

    • LLM-based tooling only gets better
    • Once the low-hanging fruits are gone: more severe, harder to fix

  • Something has to change

What we are already doing

  • More OSS-Fuzz coverage and proactive issue searching
    • Takes time, no end in sight, but saves time on bureaucracy

  • LLM-based issue, code and changeset reviews

    • Fighting fire with fire
    • In addition to mandatory human reviews
    • Not centralized, done by individual developers

  • Avoid a whole class of bugs: moving more components to Rust

What else could we do?

  • Adopt the Linux kernel model?

  • Declare security issue bankruptcy?

  • Stop considering minor issues as security-relevant?

  • Status quo?

  • I don't like any of these options!

My proposal

  • Stop accepting new parsing and network code in C

    • And port more existing code over to Rust
    • Maybe require a good justification for any new C code
    • We're on it with funding from the German Sovereign Tech Agency!

  • Try finding more LLM-assisted workflows to automate issue handling

    • Humans are the bottleneck, but they make the final decision

My proposal, continued

  • Consistent automated code review, especially in security-relevant areas
    • LLM-based, maybe static analyzers (do they still have value?)
    • Project-hosted opt-in review platform (like Sashiko), not just individuals
    • Open: how to handle the noise overhead?
  • Funding for maintenance / security work?
    • From companies shipping GStreamer, e.g. in safety-critical areas
    • Public funding is hard: needs to be ongoing

Questions? Comments?

Let me know about your opinions and experiences!

Feel free to also talk to me later!