CVE-2026-107696 in FFmpeg
Summary
by MITRE • 10/08/2026
FFmpeg through 9.0.2 contains an infinite loop vulnerability in ff_rtsp_connect() in libavformat/rtsp.c that follows RTSP 3xx redirects without any redirect limit. Attackers controlling an RTSP server can answer every request with a 302 redirect to itself or another server, causing endless reconnects that saturate a CPU core.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in FFmpeg versions up to and including 9.0.2 represents a significant denial of service risk within the RTSP client implementation found in libavformat/rtsp.c. Specifically, the function ff_rtsp_connect lacks an upper bound on the number of HTTP redirects it will process when handling RTSP responses that indicate redirection via status codes such as 301 or 302. This architectural oversight allows a malicious actor controlling an RTSP server to exploit this logic flaw by continuously responding with redirect instructions, thereby forcing the client into an infinite loop of reconnection attempts. The absence of a counter or limit mechanism means that each received redirect triggers another connection attempt without any termination condition based on the number of hops taken.
From a technical perspective, this issue stems from improper input validation and state management within the network handling logic. When FFmpeg receives a 3xx response code indicating that the requested resource resides temporarily under a different URI, it is designed to follow these redirects as per standard web protocols adapted for RTSP streams. However, because there is no safeguard against circular references or excessive redirect chains, an attacker can configure their server to return a 302 redirect pointing back to itself or another controlled endpoint indefinitely. This creates a scenario where the client software enters a tight loop of network operations, consuming system resources at a high rate without making meaningful progress toward establishing a stable media stream session.
The operational impact of this vulnerability is primarily characterized by resource exhaustion leading to denial of service conditions. As described in industry standards such as CWE-835, which covers loops that consume excessive CPU or memory cycles due to missing exit conditions, this flaw fits squarely within that classification. The continuous cycle of connection establishment and teardown saturates a single CPU core on the affected system. For applications relying on FFmpeg for real-time media processing, video conferencing, or surveillance systems, this can result in complete unresponsiveness, freezing of user interfaces, or crashes if other threads are blocked waiting for resources held by the hung process. In distributed environments where multiple streams might be processed concurrently, a single exploited instance could contribute to broader system instability depending on resource allocation policies.
This vulnerability aligns with MITRE ATT&CK technique T1496, Resource Hijacking, specifically under sub-technique T1496.001, which involves using compromised systems for computational resources or denial of service through exhaustion. An attacker leveraging this flaw does not need to execute arbitrary code or gain persistent access; they simply need the ability to serve RTSP responses that trigger the redirect loop. This makes it an attractive vector for low-effort disruption attacks against media servers, streaming clients, or any application integrating FFmpeg as a library without adequate sandboxing or resource limits enforced at the operating system level.
Mitigation strategies should focus on both immediate patching and architectural hardening. The primary remediation is to upgrade FFmpeg to version 9.0.3 or later, where this logic flaw has been addressed by implementing proper redirect counting mechanisms that terminate connections after a reasonable number of hops. In the interim, organizations deploying vulnerable versions can implement network-level controls such as rate limiting on incoming RTSP traffic from untrusted sources and configure firewalls to block excessive connection attempts from single IP addresses. Additionally, applying resource limits via operating system tools like cgroups or ulimits can restrict the CPU time available to FFmpeg processes, thereby containing the impact of any potential exploitation attempt until a permanent fix is deployed.