It started with a bug report that led somewhere unexpected.

Our AI had flagged something in GStreamer’s MIDI parser. Valgrind was reporting invalid memory reads. The pipeline was dying with “Internal data stream error.” We had found something worth investigating.

The First Report

We filed a confidential security report to GStreamer: “MIDI Parser Buffer Overflow.” Within hours, one of the core maintainers responded.

“That’s not a crash but expected error behaviour on a broken file,” they wrote. “I can’t reproduce this here. There’s no OOB read with git main or 1.26.8.”

Interesting. The latest version seemed clean. But then they added something that caught our attention: “Also there are clear possibilities for OOB reads in the code though, none of which should be triggered by your exploit file. I’ll provide a fix for those later here.”

They couldn’t reproduce our specific issue on the latest version, but they’d spotted other potential bugs while reviewing the code.

Down the Version Rabbit Hole

We went back to our test environment. Something wasn’t adding up. We ran the same exploit against different GStreamer versions:

• 1.24.2 (shipped in Ubuntu LTS): Valgrind showed OOB reads

• 1.26.0: Valgrind showed OOB reads

• 1.26.8: Clean. No warnings.

The bug was real. It just wasn’t new. Someone had already fixed it between 1.26.0 and 1.26.8.

We reported back with our findings. The response: “The second commit in !8396 fixes the problem here... That fix is included in 1.26.2 and 1.24.13.”

So the bug had been patched upstream six months ago. But here’s the thing: we weren’t testing on bleeding-edge GStreamer. We were testing on Ubuntu 24.04 LTS, the version most people actually use. And Ubuntu 24.04 ships GStreamer 1.24.2, not 1.24.13.

The upstream fix existed. But millions of Ubuntu users were still running vulnerable code.

That was worth digging deeper.

And then came the interesting part.

The Patch That Found More Bugs

The maintainer had attached a patch to our bug report. Not just a fix for the issue we reported, but fixes for other OOB reads they’d spotted while reviewing the code. Our report had prompted them to audit the MIDI parser more carefully.

“Your report at least helped improving other parts of the code,” they wrote.

We decided to test the patch. Could we trigger those “other” OOB reads they’d identified?

Yes. Yes we could.

Within minutes, we had proof-of-concept files that triggered the new vulnerabilities on GStreamer 1.26.8. We shared them back. The maintainer confirmed they worked and that the patch caught them.

“I wonder if you can also get it to read more than 1 byte after the end,” they asked. Challenge accepted.

The Final Count

The back-and-forth with the GStreamer team led us to four distinct Out-of-Bounds Read vulnerabilities:

• CVE-2025-67326: Missing event data length validation

• CVE-2025-67327: Off-by-one error in the variable-length parser

• CVE-2025-67328: Missing boundary check in SysEx event parsing

• CVE-2025-67329: Missing boundary check in meta-event handling

Two of them (67326 and 67327) affect GStreamer 1.26.x and are fixed in 1.26.10. The other two (67328 and 67329) were already fixed in 1.24.13 and 1.26.2, but we requested CVEs anyway because Ubuntu LTS is still shipping 1.24.2.

We’ve published full technical write-ups for each vulnerability, including proof-of-concept scripts you can use to reproduce them:

• https://cve.vyprsec.ai/cve-2025-67326/

• https://cve.vyprsec.ai/cve-2025-67327/

• https://cve.vyprsec.ai/cve-2025-67328/

• https://cve.vyprsec.ai/cve-2025-67329/

Each page includes the exact Python script to generate a malicious MIDI file, the commands to run, and the Valgrind output showing the memory violation.

Why Should You Care?

You might be thinking: “Who even uses MIDI files anymore?”

Fair question. But GStreamer doesn’t care what file you meant to open. If your file manager tries to generate a thumbnail, if your media player scans your library, if any application auto-processes media files, GStreamer’s MIDI parser might get invoked.

GStreamer is everywhere:

• GNOME and KDE desktops

• Media players like Totem and Rhythmbox

• Video editors like Pitivi and OpenShot

• Embedded systems and IoT devices

The attack is trivial: drop a 30-byte file somewhere it’ll get processed. That’s it.

What This Proves

This was a story of persistence and collaboration.

We didn’t stop at the first response. We dug deeper, tested across multiple versions, and when the maintainer shared a patch for related issues, we built proof-of-concept exploits (autonomously) that confirmed the vulnerabilities were real and exploitable. Within minutes…

In the end, we:

• Identified that Ubuntu LTS was shipping a vulnerable version

• Created working PoC exploits for four separate code paths

• Handled the CVE registration process with MITRE

• Published detailed technical write-ups so others can learn and verify

The GStreamer team was responsive and professional throughout. They handled the code fixes. We handled the research, documentation, and disclosure coordination. That’s how security research should work.

The Practical Takeaway

If you’re running Linux, check your GStreamer version:

gst-launch-1.0 --version

Fixed versions:

• 1.24.13 or later

• 1.26.2 or later (1.26.10 for all four CVEs)

As of late December 2025, most distributions haven’t shipped these updates. Track them here:

• Ubuntu: https://ubuntu.com/security/cves

• Debian: https://security-tracker.debian.org/tracker/

• Fedora: https://bodhi.fedoraproject.org/

References

• GStreamer Security Advisory SA-2025-0008: https://gstreamer.freedesktop.org/security/sa-2025-0008.html

• GStreamer Security Advisory SA-2025-0009: https://gstreamer.freedesktop.org/security/sa-2025-0009.html

• Our CVE write-ups with PoC scripts: https://cve.vyprsec.ai

About VyPr AI

We build AI that finds security vulnerabilities. Every report starts a conversation, and sometimes that conversation leads somewhere unexpected.

These four CVEs came from following a trail of clues across multiple GStreamer versions. That’s security research: persistent, collaborative, and always evolving.

Interested in what we might find in your software? Reach out at contact@vyprsec.ai