An FTP Bounce Attack abuses the FTP PORT command to make an FTP server connect to a third-party host or port on the attacker’s behalf. It can be used to scan or reach internal services through a trusted server, so defenders should disable unsafe FTP relay behaviour and restrict outbound connections from FTP infrastructure.
How FTP bounce attacks work
An FTP bounce attack is possible because the classic FTP control channel can accept a client-supplied destination for data transfer. Instead of sending data to the requesting client, the server is induced to make outbound connections to other systems, which turns a normal file-transfer feature into an unwanted network pivot.
The technique depends on legacy FTP behaviour, especially the PORT command, and it is most dangerous when an FTP service can reach internal or otherwise restricted hosts. In that situation, the server is no longer just a file-transfer endpoint, it becomes a proxy for reconnaissance or connection attempts.
For background on the network exposure this class of attack exploits, Network Ports and Protocols Security Guide is a useful reference for understanding why risky services and open ports matter.
Why the bounce technique is dangerous
The core danger is trust inversion. Defenders often allow an FTP server to talk outward more freely than end-user systems, so an attacker can abuse that allowance to test whether internal services are reachable through a trusted intermediary. That can expose topology, service presence, or firewall weaknesses without the attacker connecting directly.
Even when no data is stolen, the server may be used as a network scanner or as a stepping stone toward further access. The practical security issue is not FTP as a file-transfer protocol alone, but the combination of legacy relay behaviour and broad egress reach from infrastructure that should not be able to initiate arbitrary internal connections.
Attack chains that begin with exposed infrastructure and abused trust relationships are a recurring pattern in real-world incidents, which is why The State of NHI & AI Agent Breach Report 2026 is a useful companion read for understanding how attackers exploit reachable systems and trusted execution paths.
How organisations check exposure
Exposure review starts with inventory: identify where FTP is still deployed, whether it accepts active-mode transfers, and whether the server can initiate outbound connections to internal or partner networks. Teams should then compare that inventory with firewall and routing rules to see whether the service can be abused as a relay.
Vendor documentation and hardening guidance matter because FTP implementations differ in how they handle relay behaviour, passive mode, and outbound restrictions. If the environment still requires FTP, the safe design question is whether the server can be constrained so it only reaches approved destinations and cannot be used to probe anything else.
For authoritative updates and vendor-specific exposure guidance, readers should also consult the CISA cyber threat advisories feed alongside product documentation.
Controls, remediation, and monitoring
The preferred remediation is to remove legacy FTP where possible and use a secure alternative such as SFTP or FTPS with modern access controls. If FTP must remain, disable unsafe relay behaviour, restrict outbound connections from the FTP host, and segment the server so it cannot reach sensitive internal ranges.
Detection should look for unusual PORT command patterns, outbound connection attempts to unexpected ports, and FTP sessions that trigger connection activity unrelated to normal file transfer. After hardening, review logs for signs that the server was already used to reach internal services, because a bounce attack can be a reconnaissance step rather than a loud failure.
Where FTP is one of several network-facing services, the hardening principles in Network Ports and Protocols Security Guide reinforce the need to reduce risky service exposure at the port and protocol layer.
Risk and Threat Considerations
FTP bounce attacks are especially concerning in environments that still permit legacy active-mode behaviour and allow the FTP server broad outbound reach. The attacker is not trying to break FTP authentication, but to abuse the server’s network position to map or reach systems that should not be directly reachable from outside.
Failure mechanism: The server accepts attacker-influenced connection targets and uses its own network trust zone to initiate connections on the attacker’s behalf, which bypasses the normal path that would block direct scanning or access.
Impact: This can expose internal services to reconnaissance, generate misleading connection logs, and create a pivot point for follow-on abuse if the FTP host is trusted by internal networks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | FTP bounce abuse is prevented by hardening legacy services and limiting unsafe relay behaviour. |
| CIS-12 — Network Infrastructure Management | The attack depends on network reachability and egress paths from the FTP server to other hosts. | |
| Recommendation — Harden FTP hosts and disable active relay behavior to prevent the server from being used as a pivot. Restrict FTP server egress and segment it away from internal services. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Bounce attacks exploit a trusted boundary path to reach other hosts through the FTP server. |
| CM-7 — Least Functionality | Disabling legacy FTP relay behavior reduces the functionality that makes the attack possible. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Unusual PORT-driven connection attempts should be detectable in logs and network telemetry. | |
| Recommendation — Constrain and monitor outbound paths from FTP infrastructure to approved destinations only. Remove or disable FTP features that allow arbitrary outbound connection initiation. Review FTP logs for anomalous PORT commands and unexpected outbound connection attempts. | ||
Practitioner Guidance
Why practitioners should care: FTP bounce attack risk is mostly a design and containment problem, not just a protocol problem. If FTP remains in production, the server’s outbound permissions become part of your security boundary, so the service should be treated as a potential pivot point, not a neutral utility.
What to watch for: Legacy FTP services, unrestricted egress from file-transfer hosts, and internal services that respond to unexpected connection attempts from that infrastructure are the conditions that deserve immediate review. When those patterns appear together, the safest response is to reduce the attack surface rather than rely on detection alone.