A ping of death is a denial-of-service attack that crashes, freezes, or reboots a target by sending a malformed ICMP packet larger than the 65,535-byte limit that the Internet Protocol allows. The attacker splits that oversized packet into fragments, and the victim’s system fails the moment it tries to reassemble them and overruns its memory buffer. The classic version was patched out of most operating systems by 1998, yet the technique keeps resurfacing, with IPv6 variants appearing in 2013 and again in 2020. This guide covers how the attack works, how it differs from a ping flood and a DDoS, why it still counts as a DoS, and how to keep it off your network.
Key Takeaways
- A ping of death sends an ICMP packet that exceeds the maximum IPv4 size of 65,535 bytes, then abuses fragment reassembly to overflow the target’s buffer.
- It is a denial-of-service (DoS) attack, not automatically a DDoS, because a single source can knock out a vulnerable host.
- A normal ping carries about 56 bytes of data (roughly 84 bytes on the wire); a ping of death pushes past 65,535 bytes, which is where the protocol gets violated.
- Systems built after 1998 validate fragment size during reassembly, so the original attack rarely lands today.
- IPv6 revivals CVE-2013-3183 (2013) and CVE-2020-16898, nicknamed Bad Neighbor (2020), proved the idea returns whenever new code mishandles malformed packets.
- Prevention rests on patching, fragment-size validation, ICMP filtering at the firewall, and packet inspection at the network edge.
What Is a Ping of Death (PoD) Attack?
A ping of death (PoD) is a denial-of-service attack that sends a deliberately oversized or malformed ICMP echo request to crash, hang, or reboot the target machine. It weaponizes the ordinary ping command, the same tool administrators use to check if a host is reachable.
The trick sits in the numbers. A correctly formed ICMP echo request is about 56 bytes of data, or 84 bytes once you count the ICMP and IPv4 headers. The Internet Protocol caps a single IPv4 packet at 65,535 bytes. Send something larger, and you break the rules the receiving stack was written to trust.
Older TCP/IP implementations never expected an echo request bigger than that ceiling, so they allocated memory as if the limit could not be crossed. When it was, the results ranged from a frozen screen to a full kernel panic. This is why layered edge platforms now pair network-layer filtering with an advanced web application firewall so malformed traffic gets dropped long before it reaches an application.
- Uses ICMP, the protocol behind the everyday ping utility
- Relies on a packet that violates the 65,535-byte IPv4 size limit
- Needs no botnet: one host can take down one vulnerable target
- Targets a software flaw in packet reassembly, not raw bandwidth
Here is what most people miss: a ping of death is not about traffic volume at all. A ping flood tries to drown you in requests, but a ping of death can drop a server with one packet if the target parses fragments carelessly. That difference is exactly what the next section pulls apart.
How Ping of Death Works: The IP Fragmentation Exploit
A ping of death works by hiding an illegal packet size inside legal-looking fragments. The attacker never sends one giant 70,000-byte packet in the open, because routers would reject it. Instead, the oversized payload is chopped into small fragments that each look fine on their own.
Every fragment carries an offset that tells the receiver where its piece belongs in the reassembled whole. By setting the offset and length of the final fragment so their sum climbs past 65,535, the attacker guarantees the reassembled packet overruns the buffer the target set aside for it. On stacks that used a 16-bit variable to track size, that overflow corrupts memory and takes the system down.
- The attacker crafts an ICMP echo request whose total size exceeds 65,535 bytes.
- The oversized packet is fragmented into pieces small enough to pass network checks.
- Each fragment travels to the target and waits in a reassembly buffer.
- During reassembly, the fragment offset plus length pushes past the 65,535-byte limit.
- The buffer overflows and the target crashes, freezes, or reboots.
The math is worth pinning down. Subtract the 20-byte IP header and the 8-byte ICMP header from 65,535, and you get 65,507 bytes of legal data. Anything that forces reassembly beyond 65,535 total is where the danger lives. A safe stack enforces one rule during reassembly: fragment offset plus total length must stay at or below 65,535, or the packet is discarded.
Think of it like a jigsaw puzzle where every piece fits the box, but the last piece is cut so the finished picture spills over the frame. The puzzle looks fine until the final moment of assembly.
Providers offering advanced DDoS mitigation drop these malformed and oversized packets at the edge, so the reassembly step never happens on your origin server. The filtering happens before the fragments reach any hardware that might mishandle them.
Knowing the mechanism matters, but so does knowing what a ping of death is not. It gets mixed up with two very different attacks.
Ping of Death vs Ping Flood vs DDoS: Clearing Up the Confusion
A ping of death, a ping flood, and a DDoS attack all involve ICMP or traffic overload, but they break a target in different ways. A ping of death exploits a software flaw with one malformed packet. A ping flood overwhelms a host with a high rate of legitimate pings. A DDoS spreads that flood across many machines at once.
| Attack | How it breaks the target | Sources needed | Primary weapon | Still effective today? |
|---|---|---|---|---|
| Ping of Death | Triggers buffer overflow during fragment reassembly | One | A single malformed, oversized packet | Rarely, only on unpatched or legacy systems |
| Ping Flood | Exhausts bandwidth and CPU through request volume | One or a few | High-rate ICMP echo requests | Yes, without rate limiting in place |
| DDoS | Saturates capacity using traffic from many sources | Hundreds to millions | Distributed traffic from a botnet | Yes, remains a major availability threat |
You might be thinking a ping of death is just a tiny DDoS. It is not. A DDoS wins through scale, throwing more traffic than your pipe can carry. A ping of death wins through precision, exploiting a parsing bug so one packet does the work of a million.
A useful way to picture it: a ping flood is a crowd pushing through a doorway until it jams, while a ping of death is one person handing the doorman an instruction he was never trained to handle, so he simply collapses. Volume versus logic.
That distinction leads straight to a question every team eventually asks: if the classic attack was patched decades ago, is it still worth worrying about?
Is Ping of Death Still a Threat?
For fully patched modern systems, the classic ping of death is neutralized. Devices produced after 1998 check fragment size during reassembly and discard anything that would exceed 65,535 bytes. The threat has not vanished, though, because the same idea keeps reappearing in fresh code.
In 2013, an IPv6 version surfaced in Microsoft Windows. The TCP/IP stack mishandled memory when processing malformed ICMPv6 packets, opening a path to remote denial of service. Microsoft fixed it in MS13-065 that August, and it carries the identifier CVE-2013-3183.
The louder revival came in October 2020. CVE-2020-16898, nicknamed Bad Neighbor and Ping of Death Redux, lived in how the Windows tcpip.sys driver parsed ICMPv6 Router Advertisement packets using the recursive DNS option. A crafted packet could trigger a buffer overflow, crash the machine with a blue screen, and in theory allow remote code execution. It scored 9.8 on CVSS, near the maximum.
- CVE-2013-3183 (2013): malformed ICMPv6 caused remote denial of service, fixed in MS13-065
- CVE-2020-16898 (2020): crafted ICMPv6 Router Advertisement, CVSS 9.8, potential remote code execution
- CVE-2020-16899 (2020): a companion flaw that could hang the target without code execution
What most teams overlook is the long tail of unpatched gear. Legacy industrial controllers, older IoT sensors, and consumer routers that never receive firmware updates can still fall to malformed-packet attacks. The attack is old, but the vulnerable devices are still plugged in.
The devices most exposed to that long tail are routers, so they are worth a closer look.
What Is a Ping of Death Attack on a Router?
A ping of death attack on a router sends malformed, oversized packets to the router’s own IP address to crash or reboot it, cutting off every device behind it. Because a router is a shared gateway, one successful packet can take an entire home or office network offline, not just a single host.
Routers, modems, and IoT gateways are prime targets for two reasons. Many run stripped-down TCP/IP stacks with limited validation, and many rarely, if ever, receive firmware patches. When a router dies this way it fails quietly, so people tend to blame their internet provider rather than suspect an attack.
- Consumer routers running years-old firmware with no auto-update
- IoT gateways and smart-home hubs with minimal packet validation
- Industrial and SCADA equipment on long, cautious patch cycles
- Cheap network appliances that never shipped a security update
A small logistics firm we looked at kept losing connectivity every afternoon until a capture showed fragmented ICMP hitting the gateway from a single external address. The fix was a firmware update plus dropping oversized ICMP at the perimeter. It also fits a wider pattern of protocol-based attacks, which is where this goes next.
Protocol-Based DDoS Attacks: Where Ping of Death Fits
A ping of death belongs to the family of protocol-based attacks, which abuse how network protocols at Layers 3 and 4 handle malformed or unexpected input rather than relying on raw bandwidth. These attacks target the logic of the stack, not the size of the pipe.
Volumetric attacks aim to fill your bandwidth. Protocol attacks aim to exhaust a resource or crash a process by breaking the rules the protocol assumes everyone follows. The ping of death is the textbook example, but it has close relatives.
- Teardrop: sends overlapping fragment offsets that confuse reassembly
- SYN flood: leaves half-open TCP connections to exhaust the connection table
- Smurf: spoofs ICMP echoes to bounce amplified traffic off a broadcast network
- Land attack: forges a packet whose source and destination are the target itself
Volumetric attacks fight you with mass. Protocol attacks fight you with malformed logic. Defending against one does little to stop the other.
The category is useful shorthand, but you still need a checklist. Here is how to keep a ping of death out of your environment.
How to Prevent a Ping of Death Attack
You prevent a ping of death by combining patched software, strict fragment validation, and packet filtering that drops oversized or malformed ICMP before it reaches a vulnerable stack. No single control is enough on its own, so the goal is defense in depth.
- Patch operating systems, routers, and IoT firmware so reassembly code enforces the 65,535-byte limit.
- Validate fragments so any reassembled packet exceeding the size ceiling is discarded.
- Filter or rate-limit ICMP at the perimeter, and block oversized echo requests outright.
- Inspect traffic at the network edge so malformed packets are dropped before they hit your origin.
- Disable WAN-side ping responses and remote management on gateway devices.
Firewall policy does much of the heavy lifting here. Tight network firewall rules can reject fragments whose offset and length would break the size limit, and they can drop ICMP echoes from untrusted sources entirely. Pairing that with Layer 4 protection at the transport layer catches malformed packets that slip past basic rules.
One media company we reviewed thought it was protected because its firewall blocked standard pings, yet fragmented ICMP still reached the origin. Moving inspection to the edge, where fragments are reassembled and validated before forwarding, closed the gap. Prevention works best when the malformed packet dies before it touches hardware you cannot fully patch.
Final Thought on Ping of Death Attack
A ping of death is a reminder that availability is not only about surviving floods of traffic. Sometimes a single packet, crafted to break an assumption in your protocol stack, is all it takes. The classic attack has been patched for decades, but the pattern behind it, mishandling malformed input, resurfaces in new code every few years.
The durable defense is protocol hygiene backed by layered filtering. Keep systems patched, validate fragment sizes, control ICMP at the firewall, and push inspection to the edge so oversized packets die before they reach anything fragile. Treat legacy routers and unpatched IoT devices as the real exposure, because that is where this old attack still finds a home.
Frequently Asked Questions About Ping of Death Attack
Is a ping of death a DDoS attack?
Not by default. A ping of death is a denial-of-service (DoS) attack that a single source can carry out with one malformed packet. It becomes distributed only if many sources send crafted packets at once, which is uncommon because the technique relies on a software flaw rather than sheer volume.
What is the difference between a ping of death and a ping flood?
A ping of death crashes a target with one oversized, malformed ICMP packet that overflows a reassembly buffer. A ping flood does not malform anything; it sends a high volume of valid pings to exhaust bandwidth and CPU. One exploits a bug; the other exploits capacity.
Why is a ping of death considered a DoS attack?
Because its purpose is to make a system unavailable, not to steal data. By crashing, freezing, or rebooting the target, it denies service to legitimate users. The disruption is the objective, which is the defining trait of a denial-of-service attack.
