The ping of death was a 1990s attack that sent a fragmented ICMP echo request which reassembled to more than the maximum IP packet size, overflowing buffers in vulnerable network stacks and crashing the target. Current operating systems check lengths during reassembly, so the classic version no longer works against patched systems.
Why was a ping able to crash a machine?
Start with the IPv4 header in RFC 791. The total length field is 16 bits, so one datagram can be at most 65,535 bytes. Large datagrams travel as fragments, and each fragment carries an offset (counted in 8 byte units) and a flag saying whether more follow. The receiver collects fragments and rebuilds the original.
A ping is an ICMP echo request, defined in RFC 792. It is normally tiny. The attack abused the gap between what the header allows and what the reassembly code assumed. An attacker could send a last fragment whose offset plus length pushed the rebuilt datagram past 65,535 bytes. A stack that trusted those numbers wrote beyond the buffer it had allocated, and the machine froze, rebooted or crashed.
Notice that the packet was not malformed at the fragment level. Each piece looked plausible. The error only appeared in the sum, which is why simple filters missed it.
Does it still work today?
Against current, patched systems, no. Vendors added a length check on reassembly in the years after the attack became known, and maintained stacks validate it now. Seeing a successful ping of death in 2026 would mean a very old or unusual embedded device with an unmaintained network stack.
Still, the name sticks because the idea recurs. Researchers keep finding length and offset mistakes in packet parsing code, including in embedded and industrial devices that rarely get updates.
What is the difference between this and a ping flood?
A ping of death needs one or a few crafted packets and depends on a software bug. A ping flood is volumetric: it sends vast numbers of valid echo requests to saturate bandwidth or processing. The first is a vulnerability exploit, the second a denial of service by volume. Defenses differ accordingly: patching for the first, rate limiting and upstream filtering for the second.
Constructed example: the forgotten camera
An office replaces its servers, keeps current patches on laptops, and ignores a network video recorder in a cupboard. The recorder runs an old embedded stack and has not been updated in years. A scan shows it answers ICMP from the guest network. Nobody has a working ping of death to hand, but the device is exactly the kind of system where a parsing bug survives. The sensible response is to put it on an isolated segment, block inbound ICMP from untrusted zones, and plan its replacement.
What should defenders do?
Blocking all ICMP is not advisable, because ICMP carries error messages that keep path discovery and diagnostics working. Allow the types you need, rate limit echo requests from outside, and block them from untrusted segments to sensitive ones. Firewalls that reassemble fragments before applying rules add protection, though they also become a place where parsing bugs matter.
Most important is patch hygiene for anything that speaks IP, including appliances, printers and cameras. An asset list that includes these devices is the foundation. For software teams, the same lesson applies to code that parses untrusted lengths: validate every size field against the buffer before copying.
How to check or apply this
- Inventory network connected devices, including embedded gear, with firmware versions.
- Retire or isolate anything that no longer receives security updates.
- Allow only necessary ICMP types, and rate limit echo requests from outside.
- Keep untrusted segments, such as guest Wi-Fi, away from management and device networks.
- Alert on bursts of fragmented or oversized ICMP traffic.
- In your own code, check length and offset arithmetic for overflow before allocating or copying.
Quick check
Can the ping of death hit a modern laptop?
Not in its classic form. Current operating systems validate fragment lengths during reassembly. Old unpatched embedded devices are the remaining concern.
Should I block ICMP entirely to be safe?
No. Blocking everything breaks diagnostics and path discovery. Allow needed types and restrict echo from untrusted sources.
Sources
- RFC 791, Internet Protocol
- RFC 792, Internet Control Message Protocol
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
Last reviewed: 18 October 2026.
