What Is a Ping of Death Attack? | ICMP Fragmentation and Legacy Buffer Overflow

A Ping of Death attack is a legacy denial-of-service technique that sends an oversized, fragmented ICMP Echo Request packet exceeding the IP protocol’s 65,535-byte maximum packet size, causing a buffer overflow when the target reassembles the fragments. First documented in 1996, it crashed or rebooted vulnerable TCP/IP stacks of that era; modern operating systems patch this flaw, though embedded and legacy devices remain at residual risk.

TL;DR: Ping of Death abuses IP fragmentation to deliver an ICMP Echo Request whose reassembled size exceeds the 65,535-byte limit defined by the IP protocol (RFC 791). Older TCP/IP stack implementations allocated fixed-size reassembly buffers and did not validate the total reconstructed length before writing to memory, causing a buffer overflow that crashed, froze, or rebooted the target. Windows, macOS, Linux, and most networking gear patched this flaw by the late 1990s. The attack persists as a risk category only for unpatched embedded systems, industrial control systems, and IoT devices running outdated network stacks.

Last updated: 2026-08-27

How the Attack Works

Every IP packet has a maximum total size of 65,535 bytes, including headers — a limit fixed by the 16-bit Total Length field in the IP header (RFC 791). A single ICMP Echo Request (“ping”) is far smaller than this, so an attacker cannot send one oversized packet directly. Instead, the attack relies on IP fragmentation: the sending stack (or a hand-crafted packet tool) splits the ICMP packet into fragments, each with a valid individual size, but with fragment offsets constructed so that the reassembled total exceeds 65,535 bytes.

Normal ICMP Echo Request:
IP Header (20 bytes) + ICMP Header (8 bytes) + Data (≤ 65,507 bytes)
Total ≤ 65,535 bytes (IP maximum packet size)

Ping of Death fragment sequence:
Fragment 1: offset = 0,      length = 65,000  [more fragments flag set]
Fragment 2: offset = 65,000, length = 1,000   [last fragment flag set]
                                    │
                                    ▼
Target reassembly buffer receives:
  65,000 + 1,000 + headers = 65,536+ bytes  →  exceeds 65,535-byte limit
                                    │
                                    ▼
Fixed-size reassembly buffer overflow → crash, freeze, or reboot

On vulnerable stacks, the reassembly routine allocated a buffer sized to the declared maximum packet length and copied incoming fragment data into it without validating that the final offset plus length stayed within bounds. The result was a classic buffer overflow: memory adjacent to the buffer was overwritten, corrupting kernel data structures and typically crashing the operating system (the “blue screen of death” on affected Windows versions was a common symptom).

Historical Context

Ping of Death was identified and publicized in late 1996, quickly affecting a wide range of operating systems and networking equipment, including early versions of Windows 95, Windows NT, classic Mac OS, several UNIX variants, and routers and printers from multiple vendors. Because the exploit required only a single crafted packet — sendable from any machine with a raw socket tool — it spread quickly as a proof-of-concept attack.

Vendors issued patches through 1997, correcting reassembly routines to validate total packet length before allocating or writing to buffers. CERT/CC and other coordination centers documented the vulnerability and distributed mitigation guidance in advisories from that period. By the early 2000s, Ping of Death was considered fully resolved in mainstream operating systems.

Ping of Death vs. Modern ICMP Flood

Why Modern Systems Are Largely Immune

Modern operating system kernels validate the total reconstructed packet length during IP fragment reassembly and reject or drop fragment sets that would exceed the 65,535-byte limit, per hardening work that followed RFC 791 and later reassembly guidance (RFC 815). Standard OS network stacks (Windows, Linux, BSD-derived systems, macOS) have carried these checks for over two decades, and most firewalls and intrusion prevention systems also drop malformed fragment sequences before they reach the host stack.

Residual risk remains in three categories:

• Embedded and IoT devices running minimal or outdated TCP/IP stacks that were never patched
• Legacy industrial control systems (ICS/SCADA) that run unsupported operating systems for extended lifecycles
• Custom or third-party network stack implementations (found in some routers, printers, and appliances) that reimplement fragmentation handling without the same validation rigor

Detection and Mitigation

• Kernel-level packet validation — modern stacks reject fragment sets whose reassembled length exceeds the IP maximum; verify this behavior is present and unmodified on legacy or embedded systems
• IP fragment reassembly limits — configure maximum reassembly buffer size and timeout at the firewall or host to drop incomplete or oversized fragment chains
• Firewall rules dropping malformed fragments — filter fragments with inconsistent offsets or that would produce a total packet size beyond 65,535 bytes
• ICMP rate limiting — throttle ICMP Echo Request volume per source, which also mitigates conventional ICMP floods
• Patch management for embedded and ICS devices — treat unpatched legacy network stacks as a known exposure and isolate them behind network segmentation where patching is not feasible

How to Implement on Azion

Azion’s DDoS Protection inspects traffic at the network edge, filtering malformed, oversized, and fragmented ICMP packets before they reach origin infrastructure. Network Shield can help enforce fragment reassembly limits and drop packets that violate protocol size constraints at Layers 3 and 4. Firewall rules can be configured to block ICMP traffic patterns consistent with legacy exploit attempts, adding a policy-based layer of defense for origins that still run legacy or embedded network equipment behind Azion.

Related Resources

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

Frequently Asked Questions

What is a Ping of Death attack? A Ping of Death attack sends a fragmented ICMP Echo Request that reassembles into a packet larger than the IP protocol’s 65,535-byte limit. Vulnerable systems fail to validate the reconstructed size, causing a buffer overflow that crashes, freezes, or reboots the target.

Is Ping of Death still a threat today? Largely no, for mainstream operating systems and networking gear, which have been patched since the late 1990s. It remains a real risk for unpatched embedded systems, IoT devices, and legacy industrial control systems running outdated TCP/IP stacks.

How is Ping of Death different from a modern ICMP flood? Ping of Death exploits a memory-handling bug with a single malformed packet to crash the target outright. A modern ICMP flood sends high volumes of normal ICMP packets to exhaust bandwidth or CPU, requiring no software defect on the target.

Why is 65,535 bytes significant? The IP header’s Total Length field is 16 bits, capping any single IP packet — including all its data — at 65,535 bytes. Ping of Death constructs fragments that reassemble beyond this cap, a state the target’s stack was never designed to handle safely.

Can Ping of Death be launched from a single machine? Yes. Because it exploits a software flaw rather than relying on volume, one crafted packet from a single source could crash a vulnerable target, which is part of why it spread quickly as a proof-of-concept in 1996-1997.

Which operating systems were affected by Ping of Death? Early Windows 95 and Windows NT, classic Mac OS, several UNIX variants, and networking equipment such as routers and printers from multiple vendors were affected before patches were released in 1997.

How do modern systems prevent Ping of Death? Modern kernels validate the total reassembled packet length during IP fragment reassembly and drop fragment sets that would exceed the 65,535-byte maximum, preventing the buffer overflow that made the original exploit possible.

Does Ping of Death only use ICMP? The classic exploit used ICMP Echo Request because “ping” was a simple, universally available way to trigger fragment reassembly. The underlying buffer overflow could theoretically apply to any oversized, fragmented IP payload, but ICMP is what defines the named attack.

What devices are still at risk from Ping of Death-style attacks? Embedded devices, IoT products, and legacy industrial control systems that run minimal or unpatched TCP/IP stacks are the primary residual risk, since they may never have received the reassembly validation fixes applied to mainstream operating systems.

How is Ping of Death detected on a network? Detection relies on identifying fragmented ICMP traffic with offset and length combinations that would reassemble beyond 65,535 bytes, or simply dropping any fragment chain exceeding the maximum IP packet size at the firewall before reassembly is attempted.

What is the relationship between Ping of Death and IP fragmentation? Ping of Death is a specific exploit that abuses IP fragmentation — the mechanism that splits large packets into smaller pieces for transmission — as its delivery method. It targets a reassembly bug rather than exploiting fragmentation itself as a category.

Should I still worry about Ping of Death in a cloud-native environment? Direct risk is minimal, since cloud provider network stacks and load balancers are current and patched. The residual concern applies mainly to on-premises legacy hardware, ICS/OT environments, or IoT fleets that connect to cloud-hosted services.

Sources

• CERT|CC. Advisories documenting the Ping of Death vulnerability and vendor patches, mid-1990s.
• IETF. “Internet Protocol.” RFC 791. 1981.
• IETF. “IP Datagram Reassembly Algorithms.” RFC 815. 1982.
• IETF. “Internet Control Message Protocol.” RFC 792. 1981.
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.