CVE-2026-119568 · vsftpd FTPS data connection authentication bypass via TLS session…

01 · The Real Story

A pickpocket who can only strike if they share your shadow

vsftpd through 3.0.5 contains an authentication bypass in ssl_data_accept(). When FTPS (explicit TLS) is enabled and TLS session tickets are in use, an attacker who shares the victim's source IP can first connect to the control port and issue AUTH TLS to obtain a resumable TLS session ticket. They can then connect to the victim's PASV data port and resume that ticket, causing the server to accept the data connection as if it belonged to the authenticated control session. The result is theft of downloads or injection of upload data without valid FTP credentials.

The vendor's HIGH 7.4 rating is overstated for most enterprises because the primary precondition — sharing the victim's source IP — eliminates internet-wide exploitation against hosts with unique egress addresses. This primarily affects carrier-grade NAT, large corporate NAT, cloud egress proxies, and shared hosting. Typical vsftpd deployments are internal file-transfer servers or unique-egress internet hosts, so the real-world severity lands at MEDIUM.

"FTPS hijack only matters when attacker shares your egress IP."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Attacker positions on same egress IP as victim

The attacker must originate connections from a source IP that is shared with the victim's FTPS control connection. This can occur on large NATs, CGNAT, cloud shared egress, or a compromised multitenant host.

Conditions required:

Attacker shares egress IP with victim
Victim uses vsftpd 3.0.5 or earlier with FTPS enabled
Victim initiates data transfers over PASV

Where this breaks in practice:

Most enterprise hosts have unique public IPs or use VPNs with per-user addressing
Corporate segmentation often prevents lateral placement on the same NAT
Shared IP is more common in consumer/ISP settings than enterprise

Detection/coverage: NetFlow/IPFIX can reveal shared-NAT traffic anomalies, but attribution is difficult.

STEP 02

Attacker obtains TLS session ticket via AUTH TLS

The attacker connects to the vsftpd control port, negotiates explicit TLS (AUTH TLS), and completes a handshake before authentication. vsftpd returns a resumable session ticket. No valid FTP username or password is needed for this step.

Conditions required:

vsftpd accepts AUTH TLS from source IP
TLS session tickets are enabled and not rotated before use
No client-certificate requirement

Where this breaks in practice:

Server-side ticket key rotation can invalidate cached tickets
IP allowlists may block attacker's origin
Some deployments disable session tickets for compliance

Detection/coverage: TLS handshake logs from the FTP server; SIEM correlation with later PASV resumption.

STEP 03

Victim opens PASV data transfer

The victim logs in normally and requests a download or upload using PASV. The server binds a high ephemeral port and sends it over the encrypted control channel. The attacker must learn or predict this port.

Conditions required:

Victim is actively transferring data
Attacker can derive or scan the PASV port
Race window between port bind and legitimate data connection

Where this breaks in practice:

Ephemeral port ranges are wide; scanning is noisy
Control channel is encrypted, so PASV responses are hidden
Victim may use EPSV or active mode, altering the connection pattern

Detection/coverage: FTP server logs for data-connection port binding and failed connection attempts.

STEP 04

Attacker resumes stolen ticket on PASV port

The attacker connects to the victim's PASV port and resumes the previously obtained TLS session ticket. ssl_data_accept() accepts the resumed session without binding it to the original control-channel identity, allowing the attacker's data connection to be treated as authenticated.

Conditions required:

Attacker reaches PASV port before victim
Server accepts resumed tickets on data channels
Source IP matches the control connection due to shared egress

Where this breaks in practice:

Ticket reuse may be single-use or time-limited
Server configurations that disable data-channel session resumption break the attack
Network ACLs may restrict PASV ports to internal ranges

Detection/coverage: Anomalous TLS session resumption from a second socket on the same IP; deep packet inspection can flag duplicate ticket use.

STEP 05

Data theft or upload injection

Once the data channel is hijacked, the attacker can read the victim's download (file exfiltration) or inject content into the victim's upload (malicious file placement). For anonymous or shared FTP users, this can poison file repositories.

Conditions required:

Victim transfers sensitive or writable data
Injection target is later used by downstream systems

Where this breaks in practice:

File integrity monitoring may detect unexpected modifications
Encrypted data-layer session boundaries make mid-transfer injection observable only via file hashes

Detection/coverage: Host-based FIM, FTP server data-transfer logs, and DLP on file egress.

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Patch vsftpd to 3.0.6 or apply vendor backport within 365 days — Apply the vendor fix within the noisgate remediation SLA for MEDIUM (≤365 days). This removes the authentication bypass entirely.

MEDIUM 5.5→LOW 2.5

SEVERITY REDUCED

Disable TLS session tickets or bind data-channel sessions to the control channel — Temporarily disable resumption on data connections or enforce that resumed tickets must match the authenticated control session's TLS identity. Deploy within 30 days as a hardening mitigation although no formal mitigation SLA applies for MEDIUM.

MEDIUM 5.5→MEDIUM 4.5

Restrict FTP data ports to internal trusted networks — Limit PASV port ranges to RFC1918 or trusted subnets. This breaks the attacker's ability to connect from the shared egress unless the attacker is already on that subnet.

MEDIUM 5.5→MEDIUM 5.0

Monitor TLS session resumption anomalies and FTP data transfers — Enable FTP server TLS session logging and alert on duplicate ticket reuse from a second socket, or unexpected data-channel connections from shared NAT IPs.

What doesn't work

Firewall rules that only allow the control port but block the PASV range can still be bypassed if the attacker can reach the PASV port from the shared IP; data ports must be explicitly filtered.
FTP user authentication alone does not prevent data-channel hijacking because the bypass is after authentication.
IP allowlisting per FTP user on the control channel does not bind the data channel to the same user; it only filters the source IP, which the attacker shares.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No known active exploitation as of 2026-10-30; not observed in CISA KEV or major threat feeds.
Proof-of-concept availability	No public turnkey PoC on GitHub, ExploitDB, or PoCIndex. Attack requires custom TLS ticket handling; no nuclei template known.
EPSS score / percentile	EPSS ~0.00043 (0.4th percentile) — very low estimated exploitation likelihood.
KEV status	Not listed in CISA Known Exploited Vulnerabilities catalog.
CVSS vector	`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N` — 7.4 High; vector omits shared-IP precondition and race narrowing.
Affected versions	vsftpd through 3.0.5 when FTPS (`ssl_enable=YES`) and TLS session tickets enabled.
Fixed versions	vsftpd 3.0.6 (project) and vendor backports for SUSE, Ubuntu, Debian, RHEL as published.
Scanning/exposure	Shodan/Censys show ~200k vsftpd banners, but FTPS with shared egress is a small subset; no mass-scan signature for this flaw.
Disclosure date	2026-10-30 per official CVE record.
Reporter	Vendor advisory / disclosed through CVE Numbering Authority; named reporter not in supplied record.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Precondition friction: attacker must share the victim's source IP; this removes all unique-egress internet-facing hosts and confines the attack to NAT/proxy/CGNAT environments.
Race and complexity: attacker must obtain a ticket, learn/guess the PASV port, and win a race window before the legitimate data connection; no public turnkey exploit exists.
Role multiplier: vsftpd is typically a line-of-business file transfer server. Compromise yields file confidentiality/integrity loss but not domain/fleet/identity/supply-chain scale. In rare regulated-file-store roles (<5% of installs) impact can be substantial, but not enough to force a HIGH floor.

Why not higher?

No active exploitation or KEV listing; no public PoC; the shared-IP requirement makes mass exploitation impractical. Impact is confined to data theft/injection on the FTP service, not a platform takeover.

Why not lower?

If an FTPS server moves regulated financial, health, or credential data, file theft/injection can be material. Shared egress environments are common in some regions and large enterprises use proxy NAT, so the vulnerability should not be ignored.

06 · Verification

Crowdsourced verification payload.

Run on the vsftpd host with root or read access to /etc/vsftpd.conf and the vsftpd binary. Usage: ./check_vsftpd_cve_2026_119568.sh — exits 0 with VULNERABLE, 1 with PATCHED, 2 with UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
set -uo pipefail
CONF=/etc/vsftpd.conf
if ! command -v vsftpd >/dev/null 2>&1; then
  echo UNKNOWN
  exit 2
fi
VER=$(vsftpd -v 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
if [ -z "$VER" ]; then
  echo UNKNOWN
  exit 2
fi
LE=1
if dpkg --compare-versions "$VER" gt "3.0.5" 2>/dev/null; then
  LE=0
fi
if [ "$LE" -eq 1 ]; then
  if grep -qi '^ssl_enable=YES' "$CONF" 2>/dev/null; then
    echo VULNERABLE
    exit 0
  else
    echo PATCHED
    exit 1
  fi
else
  echo PATCHED
  exit 1
fi