CVE-2026-8328

What it actually does

This flaw is an FTP protocol injection/SSRF-style issue in Python's ftplib.ftpcp() helper. When copying data between FTP servers, ftpcp() parses the source server's PASV response directly with parse227() and trusts the IP address and port supplied by the FTP server. A malicious or compromised FTP server can return an arbitrary address in the 227 Passive Mode response, causing ftpcp() to send that attacker-controlled address and port to the target FTP server via PORT. The practical result is that the target FTP server can be induced to initiate a connection to an unintended host and port, potentially reaching internal services, performing FTP-bounce-style scanning, or causing unintended data transfer behavior. Exploitation requires an application or user to use ftpcp() against an attacker-controlled FTP endpoint.

Why it matters to the business

Organizations using Python-based automation that copies files between FTP servers could unintentionally allow an untrusted FTP server to make another FTP server connect to internal or sensitive network locations. This can expose internal network topology, enable unauthorized interactions with services reachable from the FTP server, disrupt file-transfer workflows, or create a pathway for data integrity issues. The EPSS score is currently low and there is no known KEV listing or ransomware association, but the issue is relevant where legacy FTP workflows are still used in automated business processes.

How an attack unfolds

An attacker first needs to influence a Python application, script, or operator to use ftplib.ftpcp() with an FTP server under the attacker's control as one side of the copy operation. When the client requests passive mode, the malicious FTP server returns a crafted 227 response containing an IP address and port chosen by the attacker rather than its own data endpoint. Because ftpcp() trusts this response, it passes the supplied address to the second FTP server using a PORT command. The second FTP server then attempts to connect to the attacker-selected destination. Depending on network placement and service behavior, the attacker may use this to probe reachable hosts and ports, trigger interactions with internal services, or manipulate the FTP copy operation. This is closely related to the earlier class of FTP PASV response trust issues addressed in CVE-2021-4189, but the vulnerable path remains in ftpcp().

How to fix it

Upgrade Python to a version that includes the fix once available from the Python maintainers or from the operating system/distribution vendor. No exact fixed versions were provided in the input, so track vendor advisories for Python/CPython packages and apply the relevant security update when released. As immediate mitigation, avoid using ftplib.ftpcp() with untrusted FTP servers, disable or remove workflows that copy directly between FTP servers using this helper, and replace FTP-based transfers with safer authenticated protocols such as SFTP or HTTPS where possible. If ftpcp() must be used before patching, validate that PASV responses resolve to the actual FTP control-channel peer address and reject private, loopback, link-local, multicast, or otherwise unexpected destination addresses. Network controls should restrict FTP servers from initiating connections to internal networks or sensitive service ports unless explicitly required.

How to confirm the fix worked

Confirm the installed Python runtime or vendor package contains the upstream fix for ftplib.ftpcp(). Where source validation is possible, inspect Lib/ftplib.py and verify that ftpcp() no longer trusts the raw host returned by parse227() and instead uses the actual peer address or otherwise validates the PASV endpoint consistently with the makepasv() fix. In test environments, attempt to use ftpcp() against a controlled FTP server that returns a PASV response with a different IP address than the control connection peer; the patched behavior should not cause the target FTP server to receive or act on that spoofed address. Also review application code and dependencies for use of ftplib.ftpcp() and confirm untrusted FTP endpoints are not accepted.

Typical attack path

1. Identify an application, script, or operator workflow that uses Python ftplib.ftpcp() to copy data involving an FTP server.
2. Cause the workflow to connect to an attacker-controlled or compromised FTP server.
3. Return a crafted FTP 227 Passive Mode response containing an arbitrary IP address and port.
4. Allow the vulnerable ftpcp() code path to parse the attacker-supplied PASV address using parse227().
5. Have ftpcp() send the attacker-controlled address and port to the target FTP server via PORT.
6. Observe or leverage the target FTP server's attempted connection to the specified host and port for SSRF-like access, scanning, or unintended data transfer behavior.

How to detect it

To determine whether this was already exploited, review FTP client, FTP server, network firewall, proxy, IDS, and packet-capture logs around Python-based FTP copy workflows. Focus on sessions where a PASV response from one FTP server advertised an IP address that did not match the server's control-channel peer IP, followed shortly by a PORT command sent to another FTP server containing that same unexpected IP and port. On FTP target servers, look for PORT commands pointing to loopback, link-local, private/internal, cloud metadata, management, or otherwise policy-disallowed ranges. On network telemetry, look for FTP servers initiating unusual outbound connections immediately after receiving PORT commands. On application hosts, search source code, job definitions, and command logs for use of ftplib.ftpcp(), and correlate execution times with anomalous FTP control-channel activity. Because there are no public exploit-specific payloads or known threat actors reported for this CVE, detection should be behavior-based rather than hash- or tool-based.

• ftpcp(
• ftplib.ftpcp
• parse227(
• sendport(
• 227 Entering Passive Mode (127,
• 227 Entering Passive Mode (10,
• 227 Entering Passive Mode (192,168,
• 227 Entering Passive Mode (169,254,
• 227 Entering Passive Mode (172,16,
• 227 Entering Passive Mode (172,17,
• 227 Entering Passive Mode (172,18,
• 227 Entering Passive Mode (172,19,
• 227 Entering Passive Mode (172,20,
• 227 Entering Passive Mode (172,21,
• 227 Entering Passive Mode (172,22,
• 227 Entering Passive Mode (172,23,
• 227 Entering Passive Mode (172,24,
• 227 Entering Passive Mode (172,25,
• 227 Entering Passive Mode (172,26,
• 227 Entering Passive Mode (172,27,
• 227 Entering Passive Mode (172,28,
• 227 Entering Passive Mode (172,29,
• 227 Entering Passive Mode (172,30,
• 227 Entering Passive Mode (172,31,
• PORT 127,
• PORT 10,
• PORT 192,168,
• PORT 169,254,
• PORT 172,16,
• PORT 172,17,
• PORT 172,18,
• PORT 172,19,
• PORT 172,20,
• PORT 172,21,
• PORT 172,22,
• PORT 172,23,
• PORT 172,24,
• PORT 172,25,
• PORT 172,26,
• PORT 172,27,
• PORT 172,28,
• PORT 172,29,
• PORT 172,30,
• PORT 172,31,

What your security team should do

• Inventory Python applications, scripts, batch jobs, and vendor tools that use ftplib.ftpcp() or direct FTP server-to-server copy behavior.
• Prioritize remediation for systems where FTP automation connects to third-party, internet-facing, partner-operated, or otherwise untrusted FTP servers.
• Apply vendor Python security updates as soon as fixed packages are available; monitor CPython and OS distribution advisories for exact fixed versions.
• Temporarily disable ftpcp()-based workflows or restrict them to trusted FTP servers with known network paths.
• Add egress controls preventing FTP servers from connecting to loopback, link-local, RFC1918/internal, cloud metadata, and sensitive management subnets unless explicitly needed.
• Review FTP server logs for suspicious PORT commands containing internal, loopback, or otherwise unexpected destination addresses.
• Prefer migration away from FTP to SFTP, HTTPS, or managed file-transfer platforms with stronger endpoint validation and logging.