Vulnerabilidades do Ffmpeg Ffmpeg

FFmpeg before 7.1.4 and 8.0.x before 8.0.2 contains a server-side request forgery vulnerability in ff_rtsp_connect() in libavformat/rtsp.c that follows RTSP 3xx redirects without validating the Location URL. Malicious RTSP servers can redirect FFmpeg to internal hosts and ports under other schemes, bypassing -protocol_whitelist, to probe internal network services.

FFmpeg before 8.1.3 contains a protection mechanism failure in the HLS demuxer that allows attackers to bypass protocol and allowed_extensions restrictions when opening child playlists. Attackers can supply a crafted master playlist whose child playlists use disallowed protocols or non-multimedia local files, making parse_playlist() open resources the HLS security policy should block.

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.

FFmpeg before 8.1.3 contains an infinite loop vulnerability in the HLS demuxer that allows remote attackers to cause denial of service because parse_playlist() accepts Master Playlist tags inside Media Playlists. Attackers can trick victims into opening a crafted self-referencing playlist that endlessly adds variants in hls_read_header(), causing unbounded CPU and I/O consumption.

FFmpeg through 9.0.2 contains a stack exhaustion vulnerability in av_encryption_init_info_free() in libavutil/encryption_info.c, which recursively frees AVEncryptionInitInfo linked lists built by the MOV demuxer's mov_read_pssh(). Attackers can supply a crafted MP4 file with tens of thousands of small pssh boxes to exhaust the stack and crash the process, while also causing quadratic CPU consumption.

FFmpeg through 9.0.2 contains a denial of service vulnerability in the DASH demuxer that allows attackers to trigger an infinite loop by supplying an empty SegmentTemplate media URL. Attackers can craft an .mpd manifest declaring SegmentTemplate media="" so get_current_fragment() calls av_strireplace() with an empty search string, consuming CPU indefinitely.

FFmpeg through 9.0.2 contains a missing host key verification vulnerability in the libssh-based sftp protocol handler that allows network attackers to impersonate SFTP servers. Attackers performing man-in-the-middle, DNS, or ARP spoofing can capture passwords supplied in sftp URLs, serve forged media, or receive uploaded output.

FFmpeg before 8.1.3 and 9.x before 9.0.2 contains an improper certificate validation vulnerability in tls_open() of libavformat/tls_mbedtls.c, which skips hostname checks for IP-address hosts. Network attackers can intercept https, rtmps, or tls connections to IP-literal URLs with any trusted CA-issued certificate to read and tamper with streams.

FFmpeg versions from 0.5 up to, but not including, 9.0 contain an uninitialized heap memory disclosure vulnerability in the native TIFF decoder in libavcodec/tiff.c. An attacker who can cause FFmpeg to decode a crafted TIFF file can supply a valid Deflate-compressed strip that terminates successfully after producing fewer bytes than the declared strip requires. The tiff_unpack_zlib() function allocates a heap buffer sized for the full declared strip but copies all declared rows via memcpy() regardless of how many bytes zlib actually decompressed, causing unwritten bytes that can contain stale data from prior heap allocations to be incorporated into decoded image output and potentially exposing sensitive data in persistent services.

FFmpeg versions from 3.0 up to, but not including, 9.0 contain an uninitialized heap memory read vulnerability in the native Screenpresso decoder (libavcodec/screenpresso.c) that allows attackers to recover sensitive memory contents by supplying a crafted SPV1 packet with a valid zlib stream that decompresses fewer bytes than the full frame requires. The screenpresso_decode_frame() function fails to validate the produced byte count before calling av_image_copy_plane() to copy the complete frame dimensions from the persistent ctx->inflated_buf buffer, causing unwritten heap memory from prior allocations or prior frames to be copied into decoded output and potentially exposing sensitive data such as userspace addresses from persistent decoding services.

FFmpeg versions from 3.0 up to, but not including, 9.0 contain an uninitialized heap memory read vulnerability in the native RSCC decoder (libavcodec/rscc.c) that allows attackers to disclose heap memory contents by supplying a crafted video file with a compressed tile that decompresses fewer bytes than the declared tile geometry requires. When rscc_decode_frame() calls av_image_copy_plane() without validating the decompressed byte count against the tile dimensions, the unwritten suffix of the persistent intermediate buffer ctx->inflated_buf is copied into the decoded frame, potentially exposing data from prior heap allocations or previous decoded frames in persistent decoding services.

FFmpeg through 8.1.2, fixed in commit 8670835, contains an information disclosure vulnerability in the LCL/ZLIB video decoder that allows attackers to expose uninitialized heap memory by supplying a valid zlib stream that inflates to fewer bytes than the expected frame size. The zlib_decomp() function in lcldec.c treats short decompression as non-fatal and continues to the RGB24 conversion path, which copies a full frame's worth of rows from the allocation buffer using original frame dimensions, causing uninitialized heap contents including pointer-derived allocator bytes to be copied into the attacker-observable AVFrame output and potentially defeating ASLR in long-lived media processing services.

FFmpeg through 8.1.2, fixed in commit 5d7112c, contains an uncontrolled resource consumption vulnerability in the IAMF demuxer that allows an unauthenticated attacker to cause multi-gigabyte memory allocation from a 17-byte input file by supplying a crafted count_label field. The mix_presentation_obu() function in libavformat/iamf_parse.c calls av_calloc(count_label, sizeof(*language_label)) with an attacker-controlled value before validating available OBU data, enabling an allocation amplification of approximately 126 million bytes per input byte that exhausts process memory or triggers an OOM-kill during format probing.