A Nuke attack is a legacy term for a category of denial-of-service techniques that send malformed, fragmented, or out-of-band packets designed to crash the target’s networking stack rather than exhaust its bandwidth. The best-known example, WinNuke, exploited a flaw in how 1990s Windows systems handled out-of-band TCP data on NetBIOS port 139, freezing or crashing the machine with a single crafted packet.
TL;DR: “Nuke” describes a class of 1990s-era attacks that sent one or a few malformed packets to crash a target outright, rather than flooding it with volume. WinNuke, the most famous variant, sent TCP segments with the URGENT flag set and out-of-band data to port 139 on Windows 95 and Windows NT machines, triggering a blue screen or lockup because the OS mishandled OOB data when no application was reading it. Microsoft patched the flaw in 1997-1998. The term now functions mostly as a historical label; modern usage sometimes extends it informally to any attack that crashes a networking stack with a single malformed packet, but current operating systems handle malformed TCP options and OOB data safely.
Last updated: 2026-08-27
How the Attack Works
TCP includes an urgent data mechanism, signaled by the URGENT flag and an urgent pointer field in the TCP header, originally intended to let applications send high-priority data (such as a Telnet interrupt signal) ahead of the normal data stream. WinNuke abused this mechanism against Windows NetBIOS services listening on port 139.
Normal TCP urgent data handling:Client ──TCP segment (URG flag set, urgent pointer set, OOB data)──▶ ServerServer: passes OOB data to the application via its OOB handling routine
WinNuke:Attacker ──TCP segment (URG=1, OOB data)──▶ target:139 (NetBIOS)Target's NetBIOS driver receives OOB data with no applicationexpecting it; the vulnerable OOB handling code in the TCP/IPstack dereferences an invalid pointer or mishandles the data │ ▼Windows 95/NT: system freezes, displays a blue screen, or crashesThe underlying flaw was not in the TCP specification itself but in how the affected Windows TCP/IP stack processed OOB data delivered to an established NetBIOS session: the handling routine did not correctly account for the case where OOB data arrived without an application actively reading from that socket in the expected way, leading to a kernel-level fault. Because NetBIOS over TCP/IP (port 139) was enabled by default and widely exposed on early Windows networking configurations, the exploit was reachable on a large number of machines with a single crafted packet.
Historical Context
WinNuke surfaced in 1997 as one of the more widely publicized “single packet crash” exploits of the era, following closely on the heels of Ping of Death and Teardrop, which had demonstrated similar single-packet denial-of-service techniques against other parts of the TCP/IP stack. It specifically affected Windows 95 and Windows NT 3.51/4.0 systems with NetBIOS enabled on port 139. Microsoft released patches addressing the OOB data handling flaw in 1997 and 1998, and the fix was incorporated into subsequent Windows service packs and later Windows versions by default.
The “Nuke” name predates WinNuke and was used informally in 1990s hacker and IRC culture for any tool that could remotely crash or disconnect another user’s machine — WinNuke became the most prominent branded example and effectively became synonymous with the category.
Nuke Attacks vs. Modern Connection-Disruption Attacks
| Aspect | Nuke / WinNuke (legacy) | TCP RESET Flood (modern) |
|---|---|---|
| Mechanism | Malformed OOB TCP data exploiting a stack bug | High volume of spoofed RST packets to force connection teardown |
| Packets required | One or a few | Many, sustained over the attack duration |
| Root cause | Software defect in OOB data handling | Protocol behavior (TCP accepts RST without full validation) |
| Effect | Full crash, freeze, or reboot of the target | Disruption of active connections, not a system crash |
| Modern OS exposure | Patched since the late 1990s | Still relevant; mitigated with sequence validation |
| Typical targets today | Essentially none on patched systems | Any TCP-based service with long-lived connections |
Why Modern Systems Are Largely Immune
Current operating systems no longer enable legacy NetBIOS-over-TCP/IP services like port 139 by default, and where NetBIOS or SMB services remain enabled, their OOB and TCP option handling has been re-implemented and hardened over more than two decades of subsequent security review. Standard TCP/IP stacks in Windows, Linux, and BSD-derived systems now validate urgent pointer and OOB data handling without the pointer or state-handling defects that made WinNuke possible.
Residual risk is largely conceptual rather than literal: the term “Nuke” is sometimes applied informally to newer single-packet or few-packet crash exploits discovered in specific software (embedded device firmware, industrial protocol stacks, or niche network appliances) that mishandle malformed input in a similar way. Legacy Windows systems still running in unsupported, air-gapped, or industrial environments without patches remain the closest literal descendants of the original exposure.
Detection and Mitigation
- Disable unused legacy services — NetBIOS over TCP/IP (port 139) should be disabled unless explicitly required, removing the historical attack surface entirely
- Kernel-level input validation — modern TCP/IP stacks validate OOB data and urgent pointer handling; ensure legacy or embedded systems run patched stacks
- Firewall rules blocking anomalous flags — filter TCP segments with unusual or unnecessary URG flag usage directed at internal services from untrusted networks
- Network segmentation — isolate legacy systems that cannot be patched behind firewalls that restrict access to only required, trusted sources
- Patch and asset management — maintain an inventory of legacy or embedded devices still running vulnerable network stacks and prioritize patching or replacement
How to Implement on Azion
Azion’s DDoS Protection and Network Shield can help filter malformed and anomalous TCP traffic, including unusual flag combinations, before it reaches origin infrastructure. Firewall rules can restrict which ports and protocols are reachable at the edge, reducing exposure of legacy or internal services that may still be vulnerable to single-packet crash techniques.
Related Resources
- What Is a DDoS Attack?
- DDoS Attack Types
- What Is DDoS Protection and Mitigation?
- What Is a Teardrop Attack?
- What Is a TCP RESET Flood Attack?
- Azion DDoS Protection
Frequently Asked Questions
What is a Nuke attack? A Nuke attack is a legacy term for denial-of-service techniques that send malformed or out-of-band packets to crash a target’s networking stack directly, rather than flooding it with high traffic volume. WinNuke, targeting Windows via NetBIOS port 139, is the best-known example.
Is Nuke attack still a threat today? The literal WinNuke exploit is not a threat to any patched modern system; Microsoft fixed the underlying flaw in 1997-1998. The term persists informally to describe any small-packet-count exploit that crashes a networking stack, a category that can still appear in unpatched embedded or legacy software.
How did WinNuke work? WinNuke sent a TCP segment with the URGENT flag set and out-of-band data to port 139 (NetBIOS) on Windows 95 or Windows NT machines. The vulnerable OOB data handling routine in the affected TCP/IP stack mishandled the data, causing a system freeze or crash.
What is out-of-band (OOB) data in TCP? OOB data is a TCP mechanism, signaled with the URGENT flag and an urgent pointer, that lets an application send high-priority data ahead of the normal stream. It was originally used for signals like Telnet interrupt characters; WinNuke abused how Windows processed it when no application was actively expecting it.
How is a Nuke attack different from a Teardrop attack? Teardrop exploits overlapping IP fragment offsets to crash a target during packet reassembly, while WinNuke-style Nuke attacks exploit a TCP-level OOB data handling flaw, unrelated to fragmentation. Both are single- or few-packet crash exploits from the same mid-1990s era of TCP/IP stack vulnerabilities.
How is a Nuke attack different from a TCP RESET flood? A TCP RESET flood uses volume — many spoofed RST packets — to tear down active connections and relies on normal TCP behavior, not a software bug. A Nuke attack like WinNuke exploits a specific implementation defect and can crash a target with a single crafted packet.
Why was port 139 significant in WinNuke? Port 139 is used by NetBIOS over TCP/IP, a service enabled by default on early Windows networking configurations for file and printer sharing. Its broad, default-on exposure made it a convenient and widely reachable target for the OOB data exploit.
Can Nuke-style attacks affect Linux or macOS? The original WinNuke exploit was specific to the Windows NetBIOS implementation of that era and did not affect Linux or macOS TCP/IP stacks in the same way. Other operating systems have had their own historical single-packet crash bugs, but they are generally not referred to as “WinNuke.”
Do modern firewalls block Nuke-style attacks? Yes. Modern firewalls and intrusion prevention systems can detect and drop TCP segments with anomalous flag combinations or unnecessary OOB data directed at services that do not expect it, and most environments no longer expose NetBIOS ports externally at all.
Is “Nuke” a formal technical term? No. Unlike SYN flood or Teardrop, “Nuke” originated as informal hacker and IRC-culture slang in the 1990s for any tool that could remotely crash or disconnect a target’s machine. WinNuke became the most recognized branded implementation of the concept.
What should organizations still running legacy Windows systems do? Disable NetBIOS over TCP/IP unless required, apply all available security patches, and isolate any unpatched legacy system behind network segmentation that restricts inbound access to trusted sources only.
Sources
- CERT|CC. Advisories and vendor bulletins documenting the WinNuke (OOB data) vulnerability, 1997.
- Microsoft. Security bulletins addressing out-of-band data handling in Windows 95 and Windows NT, 1997-1998.
- IETF. “Transmission Control Protocol.” RFC 793 (obsoleted by RFC 9293). 1981.
- NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.