CVE-2026-107698: 
Ffmpeg vulnerability analysis and mitigation

CVE-2026-107698 is a Server-Side Request Forgery (SSRF) vulnerability in FFmpeg's RTSP handler that allows malicious RTSP servers to redirect FFmpeg to arbitrary internal hosts and ports. The flaw exists in ff_rtsp_connect() within libavformat/rtsp.c, where RTSP 3xx redirect responses are followed without validating the Location URL's protocol scheme, effectively bypassing the -protocol_whitelist security control. Affected versions include FFmpeg before 7.1.4 and 8.0.x before 8.0.2. It carries a CVSS v3.1 base score of 5.4 (Medium) and a CVSS v4.0 base score of 5.3 (Medium) (GitHub Advisory, VulnCheck Advisory).

The root cause is classified as CWE-918 (Server-Side Request Forgery). In vulnerable versions, when ff_rtsp_connect() receives an RTSP 3xx redirect response, it blindly follows the Location header URL without verifying that the redirected URL uses an allowed protocol scheme. This allows a malicious RTSP server to supply a Location header pointing to an arbitrary scheme (e.g., file://, http://, gopher://) and internal network address, bypassing the -protocol_whitelist restriction that is intended to limit which protocols FFmpeg may use. The fix, applied in commits ea9e85e, 7c01199, and f9aa872, adds an explicit protocol check that returns AVERROR_INVALIDDATA if the redirect target is not an rtsp:// URL; a complementary fix in commit 2326bc5 uses ff_format_check_set_url() to validate redirect URLs against the whitelist before following them (FFmpeg Commit ea9e85e, FFmpeg Commit 2326bc5).

An unauthenticated attacker operating a malicious RTSP server can exploit this vulnerability when a user or application connects FFmpeg to that server, causing FFmpeg to issue requests to arbitrary internal hosts and ports on behalf of the victim system. This enables internal network reconnaissance (port scanning, service probing) from the host running FFmpeg, with limited confidentiality and integrity impact (CVSS VC:L/VI:L). Availability is not directly impacted, but the ability to probe internal services could facilitate further lateral movement or targeted attacks against internal infrastructure (VulnCheck Advisory, GitHub Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time. The vulnerability requires user interaction — a user or application must connect FFmpeg to a malicious RTSP server — which limits its automatable attack surface. The EPSS score is approximately 0.0027 (low probability of exploitation in the near term). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been reported (VulnCheck Advisory, GitHub Advisory).

1. Set up a malicious RTSP server: The attacker deploys a server that speaks the RTSP protocol and is reachable by the target FFmpeg instance (e.g., publicly accessible or via social engineering).
2. Lure the victim to connect: The attacker tricks a user or automated pipeline into opening an RTSP stream from the malicious server (e.g., via a crafted URL shared in a media player, script, or application).
3. Issue a 3xx redirect response: When FFmpeg connects and sends an RTSP DESCRIBE or OPTIONS request, the malicious server responds with an HTTP/RTSP 3xx redirect (e.g., 301 Moved Permanently) and a Location header pointing to an internal target using a non-RTSP scheme, such as http://192.168.1.1:8080/ or file:///etc/passwd.
4. FFmpeg follows the redirect: Vulnerable FFmpeg versions follow the redirect without validating the protocol scheme, issuing a request to the internal address under the specified scheme, bypassing -protocol_whitelist.
5. Probe internal services: By varying the Location header across multiple connections, the attacker can enumerate open ports and services on internal hosts accessible from the FFmpeg host, using response timing or error behavior as an oracle (VulnCheck Advisory, FFmpeg Commit ea9e85e).

• Network: Outbound connections from the FFmpeg host to unexpected internal IP addresses or ports (especially non-RTSP ports such as 80, 443, 22, 8080) shortly after connecting to an external RTSP server; DNS lookups for internal hostnames initiated by the FFmpeg process.
• Logs: Application or system logs showing FFmpeg connecting to URLs with non-RTSP schemes (e.g., http://, file://, gopher://) following an initial RTSP connection; RTSP redirect log entries (Status 3xx: Redirecting to ...) pointing to internal addresses.
• Process: Unusual network socket activity from the FFmpeg process to RFC 1918 address ranges (10.x.x.x, 172.16.x.x–172.31.x.x, 192.168.x.x) or localhost (127.0.0.1) on non-standard ports.

Upgrade FFmpeg to version 7.1.4 or later (for the 7.x branch) or 8.0.2 or later (for the 8.0.x branch), which include fixes that explicitly validate redirect protocol schemes and use ff_format_check_set_url() to enforce whitelist checks on redirect targets. As a workaround where upgrading is not immediately possible, restrict network access of FFmpeg processes to only trusted, known-good RTSP servers using firewall rules or network segmentation, and avoid processing RTSP streams from untrusted sources. Enforcing strict -protocol_whitelist flags alone is insufficient to mitigate this vulnerability in unpatched versions (GitHub Advisory, VulnCheck Advisory, Red Hat Bugzilla).