FFmpeg EUVD-2026-95080

Exploitation requires FFmpeg to be built with libssh support AND the victim application/user to actually use the sftp:// protocol handler with a password-bearing URL - this is not a default media workflow. The attacker must additionally hold an active man-in-the-middle position on the network (ARP, DNS, or routing spoofing) at the moment of connection. Limiting factors: required user interaction (supplying or triggering the sftp URL, reflected as UI:P), the attacker's need for a privileged on-path network position (AT:P), high attack complexity (AC:H), and the compile-time/runtime dependence on the libssh SFTP feature - none of which apply to the vast majority of FFmpeg invocations that process local files or HTTP(S)/RTMP streams.

This is a genuine but conditional medium-severity issue, not a drop-everything priority. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:P, score 6.0) is internally consistent with the description: no authentication is needed (PR:N), but exploitation demands a privileged network position (AT:P), succeeds only against a user action (UI:P supplying/triggering an sftp URL), and is non-trivial (AC:H), which collectively depress real-world risk despite the network attack vector. Impact is primarily confidentiality (VC:H - capture of passwords embedded in sftp:// URLs) with limited integrity (VI:L - forged media served to the victim) and no availability impact. There is no EPSS score, KEV listing, or POC in the provided data: exploitation status is 'no public exploit identified at time of analysis,' which aligns with a flaw that requires an active man-in-the-middle rather than remote mass exploitation. Note a signal to weigh: FFmpeg is ubiquitously deployed, but this flaw only reaches code paths that use the libssh-based SFTP handler, so the ubiquitous product footprint overstates the actual attack surface - most FFmpeg deployments never invoke sftp:// at all. No conflicting signals were observed between the CVSS vector and the description; both point to an adjacent/network MITM scenario against SFTP clients.

A victim runs FFmpeg against an sftp:// URL (e.g., to pull or push media) while an attacker occupies the network path via ARP or DNS spoofing. Because FFmpeg's libssh handler does not verify the server host key, the attacker impersonates the real SFTP server, harvests the password embedded in the sftp URL, and can return forged media or capture uploaded output. No public exploit code is identified at time of analysis, but the technique (SSH MITM without host-key pinning) is well understood and requires no memory-corruption primitive.