CVE-2026-107696: 
Ffmpeg vulnerability analysis and mitigation

CVE-2026-107696 is an infinite loop (Denial of Service) vulnerability in FFmpeg's RTSP client handler, specifically in the ff_rtsp_connect() function within libavformat/rtsp.c. The flaw affects FFmpeg through version 9.0.2 and allows an attacker controlling a malicious RTSP server to respond to every connection request with a 302 redirect — pointing back to itself or to a second colluding server — causing FFmpeg to reconnect indefinitely and saturate a CPU core. It was published on October 8, 2026, with a CVSS v3.1 score of 6.5 (Medium) and a CVSS v4.0 score of 7.1 (High) (Github Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-835 (Loop with Unreachable Exit Condition / Infinite Loop). In ff_rtsp_connect(), when a 3xx redirect response is received, the code updates the target URL and jumps back to a redirect: label via goto redirect — but no redirect counter is ever incremented or checked, making the loop unbounded. This contrasts with FFmpeg's HTTP client (libavformat/http.c), which enforces a configurable max_redirects limit. The vulnerable code path is confirmed by the absence of any max_redirect, redirect_count, or nb_redirect variable in libavformat/rtsp.c. Exploitation requires only that the victim FFmpeg process open an attacker-controlled rtsp:// URL, with no special options or authentication needed (PoC Gist, FFmpeg Source).

Successful exploitation causes the FFmpeg process to enter an endless reconnect loop, saturating approximately one full CPU core and never terminating without an external signal (e.g., SIGTERM). There is no confidentiality or integrity impact — the vulnerability is purely an availability (DoS) issue. In deployment scenarios where a backend service or SaaS platform (e.g., cloud NVR, transcoder, video-analytics ingest) opens user-supplied rtsp:// URLs, a small number of malicious URLs can exhaust the worker process pool, resulting in a service-level denial of service (PoC Gist, Github Advisory).

A public proof-of-concept exploit is available as a Python script (rogue.py) published on GitHub Gist by researcher OxBat, demonstrating two scenarios: a self-redirect loop and a two-server ping-pong redirect. The PoC was published on September 27, 2026, and confirmed to produce thousands of redirects per second with sustained CPU saturation on tested FFmpeg builds. The EPSS score is approximately 0.325% (27th percentile), and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing at this time (PoC Gist, Github Advisory).

1. Set up a rogue RTSP server: Deploy the rogue.py Python server on an attacker-controlled host. The server listens on a chosen port and responds to every RTSP request with RTSP/1.0 302 Moved Temporarily and a Location header pointing back to itself (self-loop) or to a second rogue server (ping-pong).

   python3 rogue.py 8554 "rtsp://127.0.0.1:8554/loop" &

2. Lure the victim FFmpeg instance: Cause the target FFmpeg process to open the attacker-controlled RTSP URL. In backend/SaaS contexts, this may be achieved by submitting a malicious rtsp:// URL as user input to a transcoding or streaming service.

   ffmpeg -i rtsp://<attacker-ip>:8554/loop -f null -

3. Trigger the redirect loop: The rogue server responds to each RTSP OPTIONS/DESCRIBE request with a 302 redirect. FFmpeg's ff_rtsp_connect() updates the URL and jumps back to the redirect: label unconditionally, re-issuing RTSP requests without limit.

4. Sustain CPU exhaustion: The FFmpeg process enters an infinite reconnect loop, generating thousands of redirects per second (measured: ~5,065 in 8 seconds in Scenario 1), keeping the process in state R and consuming ~100% of one CPU core until externally killed.

5. (Optional) Scale for service-level DoS: Submit multiple such malicious URLs to exhaust the worker pool of a backend service, preventing legitimate jobs from being processed (PoC Gist).

• Process: FFmpeg process persistently in state R (running) with no progress on media processing; CPU usage pinned at ~100% of one core for an extended period with no output produced.
• Network: High-frequency, rapid TCP connection attempts from the FFmpeg host to an RTSP server IP/port; thousands of short-lived RTSP connections in a short time window; repeated RTSP/1.0 302 responses observed in network captures.
• Logs: FFmpeg log output showing repeated Status 302: Redirecting to rtsp://... messages in rapid succession with no eventual success or error termination; absence of normal stream negotiation log entries (e.g., SDP parsing, codec detection).
• System: Worker processes that never complete or release resources when processing user-supplied RTSP URLs; job queue buildup in transcoding/streaming services handling RTSP inputs (PoC Gist).

The recommended fix is to upgrade FFmpeg to a version that includes the redirect limit patch introduced via FFmpeg pull request #24902, which adds a redirect counter to ff_rtsp_connect() (analogous to the existing max_redirects control in the HTTP client). As a network-level workaround, restrict FFmpeg processes from connecting to untrusted or user-supplied RTSP servers using firewall rules or allowlists. For applications that cannot be immediately patched, implement application-level timeouts and process watchdogs to detect and terminate stalled FFmpeg workers. Avoid exposing FFmpeg's RTSP client to arbitrary user-supplied URLs in backend services until the patch is applied (Github Advisory, Red Hat Bugzilla, FFmpeg PR #24902).

Red Hat has tracked this vulnerability via Bugzilla (Bug 2548115) and assigned it medium priority/severity, with dependent bugs filed for multiple Red Hat products. The GitHub Advisory Database published the advisory on October 8, 2026, though it remains unreviewed with no package-level fix version listed. No significant public researcher commentary or broad media coverage beyond the original PoC disclosure and standard vulnerability database entries has been observed at this time (Red Hat Bugzilla, Github Advisory).