What Is a TCP ACK-PSH Flood Attack?

A TCP ACK-PSH flood is a protocol-based DDoS attack that sends TCP segments with both the ACK and PSH flags set toward a target, forcing the receiving stack to treat each packet as if it carries data ready for immediate delivery to the application. Because the PSH flag instructs the receiver to bypass normal buffering and push data straight to the application layer, each packet costs more CPU and memory to process than a plain ACK flood, even when the payload is empty or the connection does not exist.

TL;DR: TCP ACK-PSH flood is a variant of ACK flood that adds the PSH (push) flag to each packet. On a real connection, PSH tells the receiving stack to deliver buffered data to the application immediately instead of waiting to fill a buffer. When attackers set PSH on floods of ACK packets — often for connections that never existed — the target’s TCP stack still performs a connection-state lookup and, on packets that appear to match state, additional buffer-handling work. This raises per-packet processing cost compared to a plain ACK flood, pressuring CPU, firewall state tables, and application-facing buffers. Mitigation relies on stateful inspection, rate limiting, and moving TCP termination to a distributed edge network.

Last updated: 2026-08-27

How a TCP ACK-PSH Flood Works

The ACK and PSH flags in the TCP header

TCP segments carry a set of control bits in the header, defined originally in RFC 793 and consolidated in RFC 9293. Two of them matter here:

• ACK (Acknowledgment): set on nearly every segment after the handshake completes; it confirms receipt of data up to a given sequence number.
• PSH (Push): signals to the receiving TCP stack that any buffered data — including the data in the current segment — should be delivered to the application immediately, rather than held until the receive buffer fills or a timer expires.

In legitimate traffic, PSH is set at the end of a logical message (for example, the final segment of an HTTP request) so the receiving application does not wait for more data before acting. Combined with ACK, an ACK-PSH segment says: “I acknowledge your data, and here is a payload that you must hand to the application now.”

TCP header flags (relevant bits):
CWR ECE URG ACK PSH RST SYN FIN

Normal data segment during a session:
[ACK]           → acknowledges prior data, no new payload flush required
[ACK, PSH]      → acknowledges prior data AND flushes payload to the application now

Why the flag combination increases cost

A plain ACK flood forces the receiver to look up connection state for each packet and, in most cases, discard it as invalid when no matching connection exists. An ACK-PSH flood adds a second layer of work:

1. The kernel performs the same connection-state lookup as an ACK flood (conntrack, netfilter, or the TCP stack’s own tables).
2. If the segment appears to match an established connection — spoofed or hijacked sequence numbers, or attacks that ride real sessions — the PSH flag forces the stack to attempt an immediate copy of any payload into the application’s receive buffer and to wake the application process, rather than allowing the kernel to coalesce or delay delivery.
3. Even when the connection does not exist and the packet is dropped, some middleboxes and stateful firewalls perform deeper inspection on ACK+PSH combinations because they are more likely to be classified as “data-carrying” and therefore subject to additional logging or DPI rules.

Normal traffic:
Client ──ACK,PSH(data)──▶ Server   [Server delivers data to app immediately]

ACK-PSH flood:
Bot 1 (spoofed IP) ──ACK,PSH──▶ Server  [state lookup + buffer-handling attempt]
Bot 2 (spoofed IP) ──ACK,PSH──▶ Server  [state lookup + buffer-handling attempt]
Bot 3 (spoofed IP) ──ACK,PSH──▶ Server  [state lookup + buffer-handling attempt]
... [millions more per second]

Result: CPU spent on lookups and buffer-handling paths rises faster than
        packet count alone would predict; firewall/IDS inspection load increases

The net effect is the same category of damage as an ACK flood — CPU exhaustion on stateful devices, connection-table churn, and processing overhead on the origin — but achieved with fewer packets per unit of damage, because each packet forces more work.

Why attackers use small or empty payloads

Most ACK-PSH flood traffic carries little or no real payload. The PSH flag itself, not the payload size, is what forces immediate processing; attackers do not need large packets to trigger this behavior, which keeps the attack bandwidth-efficient relative to its processing impact.

TCP ACK-PSH Flood vs. Related Flag-Based Floods

Detection Signals and Telemetry

Distinguishing ACK-PSH flood traffic from legitimate high-throughput sessions requires correlating flag distribution with connection state, not just packet volume.

# Socket summary — watch for growth in sockets with no matching application read
ss -ti

# TCP counters — invalid segments, resets generated for unmatched ACKs
nstat -az | grep -i tcp

# Netfilter conntrack table state and size
conntrack -L | wc -l
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# iptables counters on rules matching ACK+PSH without SYN (mid-session-only pattern)
iptables -L -v -n --line-numbers

# Packet capture flag distribution (short window only — high PPS attacks can overload capture)
tcpdump -i eth0 -c 20000 'tcp' -nn | awk '{print $0}' | grep -c "P."

Mitigation Techniques

Edge termination is the most durable defense: when a distributed network completes the TCP handshake and manages the session state on behalf of the origin, ACK-PSH packets that do not correspond to a real, edge-validated session never reach the origin’s stack at all.

Common Mistakes

How to Implement on Azion

Azion terminates TCP connections at the network edge, which changes where ACK-PSH flood traffic is absorbed:

• DDoS Protection provides always-on detection and mitigation for protocol-based floods, including anomalous ACK/PSH patterns, before traffic reaches the origin.
• Network Shield applies programmable network-layer rules, including IP, CIDR, and ASN-based lists, to block sources associated with flood traffic.
• Firewall enables custom rules for connection-state and rate-based filtering at the edge.
• WAAP combines network and application-layer protections for environments facing blended attacks.

Because Azion completes and manages TCP sessions at distributed points of presence, origin infrastructure is only exposed to already-validated connections, reducing the surface for flag-manipulation floods like ACK-PSH.

Related Resources

• What Is a DDoS Attack?
• DDoS Attack Types
• What Is a SYN Flood Attack?
• What Is DDoS Protection and Mitigation?
• Azion DDoS Protection

Frequently Asked Questions

What is a TCP ACK-PSH flood attack? A TCP ACK-PSH flood sends large volumes of TCP segments with both the ACK and PSH flags set toward a target, often for connections that do not exist. The PSH flag forces the receiving stack to attempt immediate buffer delivery, increasing per-packet processing cost compared to a plain ACK flood.

How is ACK-PSH flood different from a plain ACK flood? A plain ACK flood only forces a connection-state lookup, which is typically inexpensive per packet. Adding the PSH flag forces the receiving stack to also attempt an immediate push of any payload to the application layer, which increases CPU and buffer-handling cost per packet even at the same packet rate.

Does an ACK-PSH flood require a completed TCP handshake? No. Most ACK-PSH flood traffic targets connections that were never established, relying on the receiver performing a state lookup and rejecting the packet. The attack is more damaging when it can piggyback on real, active sessions, but that is not a requirement.

How does ACK-PSH flood differ from SYN flood? SYN flood exhausts kernel memory by creating half-open connection entries during the handshake. ACK-PSH flood targets packets sent after a handshake would have occurred, exhausting CPU on connection-lookup and buffer-handling logic rather than memory on half-open state. SYN cookies, the primary SYN flood defense, do not mitigate ACK-PSH flood.

How does ACK-PSH flood differ from TCP FIN or RESET flood? FIN and RESET floods target connection teardown logic and conntrack/session-table churn by simulating connection closure. ACK-PSH flood simulates mid-session data delivery. Both categories force state lookups, but FIN and RESET floods specifically stress teardown state machines, while ACK-PSH stresses data-path processing.

Can SYN cookies stop an ACK-PSH flood? No. SYN cookies only affect handshake-stage processing (SYN and SYN-ACK). ACK-PSH floods target segments that occur logically after the handshake, so they bypass SYN cookie protection entirely.

Why do attackers set the PSH flag if the payload is empty? The PSH flag itself — not the payload size — triggers the receiving stack’s immediate-delivery code path. Attackers get the increased processing cost without needing to send large packets, keeping the attack bandwidth-efficient.

Can a stateful firewall block an ACK-PSH flood? Yes, for non-spoofed and moderately distributed attacks. A stateful firewall can drop ACK/PSH segments that do not match a tracked connection before they reach the deeper processing path. For highly distributed, spoofed floods, the firewall’s own state table can become the bottleneck, requiring upstream or edge-based mitigation.

Is ACK-PSH flood a volumetric or a protocol attack? It is a protocol (state-exhaustion) attack rather than a purely volumetric one. It typically requires far less bandwidth than a volumetric flood to cause measurable CPU and processing impact, because the damage comes from per-packet processing cost rather than raw throughput.

What telemetry best identifies an ACK-PSH flood in progress? The most reliable signals are a rising ratio of ACK+PSH packets with no matching connection state, sustained growth in conntrack table size, and elevated CPU time in the netfilter or TCP stack processing path relative to overall packet volume — rather than total bandwidth alone.

Does edge termination fully eliminate ACK-PSH flood risk? Edge termination substantially reduces exposure because only validated, edge-managed sessions reach the origin. It does not eliminate the need for rate limiting and anomaly detection at the edge itself, since the edge network’s own stateful infrastructure must still process the flood traffic.

Sources:

• IETF. “Transmission Control Protocol.” RFC 793. 1981.
• IETF. “Transmission Control Protocol (TCP).” RFC 9293. 2022.
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP 38). 2000.