vsftpd EUVD-2026-113833

Exploitation requires the target to be using FTPS (explicit TLS via AUTH TLS) on vsftpd 3.0.5 or earlier, and requires the attacker to originate from the same source IP as the victim (e.g., shared NAT, VPN/proxy egress, or multi-tenant host), because the flaw lets ssl_data_accept() accept any valid resumed TLS session ticket instead of binding the data connection to the victim's authenticated control session. The attacker must also connect to the victim's PASV data port and win the timing race for that data connection. Limiting factors captured by AC:H/AT:P: no shared-source-IP position means no path to exploit, FTP-only (non-TLS) or non-PASV deployments are not in scope, and success depends on the race against the legitimate data transfer - it is not reliable, remote, mass exploitation against arbitrary internet hosts.

The input rates this CVSS 4.0 9.1 (Critical) with vector AV:N/AC:H/AT:P/PR:N/UI:N and VC:H/VI:H/VA:N, and vuln.today assigns an 'act_now' decision label, so this should be treated as a near-term priority for any environment running FTPS on vsftpd ≤3.0.5. The signals are partly reinforcing and partly tempering: PR:N (unauthenticated) and AV:N (network) raise urgency, but AC:H combined with AT:P reflects real preconditions - the attacker must share the victim's source IP and win a timing/connection race against the victim's PASV data channel - which point to targeted rather than opportunistic, internet-wide exploitation. No EPSS probability is provided in the input, and there is no CISA KEV listing in the data, so there is no confirmed active-exploitation or scored-likelihood signal to weigh against the vendor/researcher reporting; the 'act_now' label here is driven by severity and a detailed public technical analysis, not by observed in-the-wild use. Impact is confined to the FTPS data channel (confidentiality and integrity of transferred files, VC:H/VI:H) with no availability impact and no scope/subsequent-system change (VA:N, SC:N/SI:N/SA:N). Net: a genuine high-priority data-channel hijack for FTPS deployments where attackers can share the victim's source address (shared NAT, proxy, multi-tenant egress), but the shared-source-IP and timing requirements meaningfully narrow the realistic attacker population below what a raw 9.1 implies.

An attacker positioned behind the same NAT or egress IP as a legitimate FTPS user opens their own control connection, issues AUTH TLS, and obtains a valid TLS session ticket. Because ssl_data_accept() accepts any resumed ticket rather than binding the data connection to the victim's control-channel session, the attacker connects to the victim's PASV data port and resumes their own ticket to hijack the transfer - stealing downloaded content or injecting attacker-controlled data into an upload. A detailed technical write-up of the flaw is public (abraxaslabs research and the VulnCheck advisory); the input does not confirm packaged working exploit code, and the AC:H/AT:P metrics reflect the required shared source IP and timing against the data channel.