CVE-2026-107696: FFmpeg RTSP Infinite Loop DoS Vulnerability

CVE-2026-107696 Overview

CVE-2026-107696 is an infinite loop vulnerability in FFmpeg versions through 9.0.2. The flaw resides in the ff_rtsp_connect() function in libavformat/rtsp.c, which processes Real-Time Streaming Protocol (RTSP) 3xx redirect responses without enforcing a redirect limit. An attacker who controls or impersonates an RTSP server can return a 302 redirect pointing back to itself or another malicious endpoint. FFmpeg follows the redirect chain indefinitely, saturating a CPU core and causing a denial-of-service condition. The weakness is classified under CWE-835 (Loop with Unreachable Exit Condition).

Critical Impact
A malicious RTSP server can trigger an infinite reconnect loop in any FFmpeg-based client that opens an attacker-supplied RTSP URL, exhausting CPU resources and degrading availability of media pipelines.

Affected Products

FFmpeg versions up to and including 9.0.2
Applications and services embedding libavformat for RTSP ingestion
Media servers, transcoders, and surveillance tools built on FFmpeg

Discovery Timeline

2026-10-08 - CVE-2026-107696 published to NVD
2026-10-14 - Last updated in NVD database

Technical Details for CVE-2026-107696

Vulnerability Analysis

The vulnerability lies in how ff_rtsp_connect() in libavformat/rtsp.c handles RTSP redirect responses. When the function receives a 3xx status code, it extracts the new Location header value and reconnects to the specified URL. The implementation does not track the number of redirects performed or enforce a maximum hop count. If the destination server returns another 3xx response, FFmpeg repeats the connect sequence without limit.

Exploitation requires user interaction, as the victim must open an attacker-controlled RTSP URL in an FFmpeg-based client such as ffplay, ffmpeg, or any application linked against libavformat. Once the connection is initiated, the loop executes entirely on the client side and consumes a full CPU core. In automated pipelines that process untrusted stream URLs, the condition can degrade service availability across many concurrent workers.

Root Cause

The root cause is a missing redirect-depth check in the RTSP client logic. HTTP clients typically cap redirect chains at a small integer, but the RTSP path in ff_rtsp_connect() lacks the equivalent safeguard. The relevant code is located around libavformat/rtsp.c line 2225.

Attack Vector

An attacker hosts an RTSP server that answers every DESCRIBE or SETUP request with a 302 Found response whose Location header points to itself or another cooperating endpoint. When a victim client connects, FFmpeg follows the redirect, issues a new request, receives another 302, and repeats the sequence indefinitely. See the VulnCheck security advisory and proof-of-concept gist for technical details.

Detection Methods for CVE-2026-107696

Indicators of Compromise

FFmpeg or libavformat-linked processes sustaining 100% CPU utilization on a single core without producing output.
Repeated outbound RTSP connections from the same process to one or more external hosts within a short interval.
Network traffic showing a continuous sequence of RTSP 3xx responses to a client.

Detection Strategies

Monitor process-level CPU usage for FFmpeg binaries and flag long-running sessions pinned to a single core.
Inspect RTSP traffic for repeated 302 responses or Location headers that resolve back to the same endpoint.
Correlate media worker crashes, timeouts, or queue backlogs with recently ingested RTSP URLs.

Monitoring Recommendations

Alert on FFmpeg-based worker processes that exceed a defined CPU-time threshold without completing a job.
Log and review every RTSP URL submitted to transcoding or ingestion services to identify attacker-controlled endpoints.
Instrument network sensors to count RTSP redirects per session and raise alerts above a reasonable baseline.

How to Mitigate CVE-2026-107696

Immediate Actions Required

Restrict FFmpeg clients from connecting to untrusted RTSP URLs, especially in automated media pipelines.
Enforce per-process CPU and wall-clock limits on FFmpeg workers to contain runaway loops.
Apply the upstream FFmpeg fix once it is merged and included in a tagged release.

Patch Information

The fix is tracked in the upstream FFmpeg Pull Request #24902, which introduces a redirect limit in ff_rtsp_connect(). Users should rebuild FFmpeg from a revision that incorporates this change or upgrade to a release later than 9.0.2 once available. Distribution-provided packages should be updated as vendor patches are published.

Workarounds

Wrap FFmpeg invocations with resource limits such as ulimit -t, cgroups CPU quotas, or container --cpus constraints.
Validate and allow-list RTSP hostnames and ports before passing URLs to FFmpeg.
Terminate FFmpeg sessions after a maximum runtime using a supervisor or systemd RuntimeMaxSec directive.

bash

# Example: constrain ffmpeg CPU time and wall-clock via systemd-run
systemd-run --scope \
  -p CPUQuota=50% \
  -p RuntimeMaxSec=60 \
  ffmpeg -rtsp_transport tcp -i "rtsp://trusted-host/stream" -t 30 out.mp4