EternalBlue is the most consequential remote code execution vulnerability of the last decade, and it is worth studying precisely because the fix was available before the damage was done. Tracked as CVE-2017-0144, it is a flaw in the SMBv1 (Server Message Block version 1) file-sharing protocol as implemented in Microsoft Windows. Microsoft rated the corresponding bulletin, MS17-010, as Critical. The NVD assigns the CVE a CVSS 3.x base score of 8.8 (High) and a legacy CVSS 2.0 score of 9.3. Whatever number you anchor to, the practical impact was total: an unauthenticated attacker who could reach TCP port 445 could execute code in kernel context on a vulnerable host.
Timeline and impact
Microsoft shipped the patch on March 14, 2017. One month later, on April 14, 2017, a group calling itself the Shadow Brokers publicly dumped a cache of exploits attributed to a nation-state toolkit, and "EternalBlue" was among them. That gap, patch first, weaponized exploit second, is the reverse of the usual zero-day story, and it meant that every organization hit afterward had already been given a fix.
On May 12, 2017, the WannaCry ransomware worm used EternalBlue to self-propagate across flat networks, encrypting an estimated 200,000+ machines across more than 150 countries, famously disrupting the UK's National Health Service. Six weeks later, on June 27, 2017, the NotPetya wiper, disguised as ransomware, used the same primitive (paired with credential theft) to cause billions of dollars in damage to shipping, logistics, and pharmaceutical firms. EternalBlue has since resurfaced in cryptominers and lateral-movement toolkits and remains on CISA's Known Exploited Vulnerabilities catalog.
Root cause
The bug lives in the SMBv1 server driver's handling of extended file attributes. When a client sends a request containing an OS/2-style FEA (File Extended Attribute) list, the driver converts that structure into the NT internal format. The size calculation used to allocate the destination buffer relied on an arithmetic operation that mixed a larger integer type with a smaller one; a maliciously oversized attribute list caused the computed length to wrap, so the driver allocated a buffer that was too small and then copied the full attacker-supplied payload into it. The result is a controlled write past the end of a non-paged kernel pool allocation.
By combining that primitive with careful "grooming" of the kernel pool, using additional SMB packets to arrange adjacent allocations, an attacker turned a heap corruption into reliable kernel code execution. No credentials and no user interaction were required, which is exactly what made a network worm feasible.
Which systems were affected
CVE-2017-0144 affected the SMBv1 server in a broad sweep of Windows releases: Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 and 2012 R2, Windows RT 8.1, Windows 10 versions 1507/1511/1607, and Windows Server 2016. Embedded and medical-device variants running affected Windows builds were also exposed, which is part of why the outbreak reached hospitals so hard.
Detection
Detecting exposure is straightforward because the vulnerable surface is a single legacy protocol:
- Inventory every host with SMBv1 enabled. On modern Windows you can query the optional feature state and disable it where it is not required.
- Confirm the MS17-010 update (the relevant KB for each OS build) is installed on every asset that speaks SMB.
- Scan internally for reachable TCP 445. Open-source scanners such as the Nmap
smb-vuln-ms17-010script probe the specific FEA-conversion code path safely. - Watch perimeter and east-west firewall logs for unexpected 445 traffic between workstation subnets, a hallmark of worm propagation.
Remediation and patched versions
The definitive fix is the MS17-010 security update for your specific Windows build; apply it everywhere SMB is exposed. Beyond patching, three hardening steps sharply reduce risk and remain good hygiene regardless of patch level:
- Disable SMBv1 entirely. It has been deprecated for years, and Windows 10/11 and Windows Server 2019+ no longer install it by default. Nothing in a modern environment should depend on it.
- Block TCP 445 (and 139) at the network perimeter and segment internal networks so a single compromised workstation cannot reach an entire subnet over SMB.
- Retire or isolate end-of-life systems. Microsoft took the extraordinary step of releasing patches for out-of-support Windows XP and Server 2003 during the WannaCry emergency, but relying on emergency patches for dead operating systems is not a strategy.
How Safeguard helps
EternalBlue is an operating-system flaw rather than an open-source dependency, but the lesson it teaches, known-exploitable components sitting unpatched in production, is exactly what a modern supply chain platform is built to prevent. Safeguard maintains a continuous inventory of the components inside your build artifacts and correlates every one against the CISA KEV catalog and live exploit intelligence, so a component tied to an actively exploited CVE surfaces immediately instead of after an outbreak. Where Windows or mixed-OS container images are part of your pipeline, Safeguard's container scanning flags legacy protocol stacks and end-of-life base layers before they ship. Its software composition analysis applies the same KEV-aware prioritization to the third-party code your applications actually depend on, and policy gates can block a deployment that includes a component matching a known-exploited advisory. If you are weighing platforms, the product comparison walks through how prioritization differs across tools.
Known-exploited, patch-available vulnerabilities like EternalBlue should never be the reason you make the news. Get started free or read the documentation to bring KEV-aware prioritization to your own environment.
Frequently Asked Questions
Is EternalBlue still a threat in 2026?
Yes, on unpatched or unmanaged systems. Nearly a decade after the patch, internet and internal scans still find hosts with SMBv1 enabled and MS17-010 missing, and cryptominers and lateral-movement tools continue to bundle the exploit. The vulnerability remains on CISA's Known Exploited Vulnerabilities list, which is a strong signal to verify your fleet is patched and that SMBv1 is disabled.
What is the difference between EternalBlue and WannaCry?
EternalBlue (CVE-2017-0144) is the vulnerability, the SMBv1 flaw that allows remote code execution. WannaCry is the ransomware worm that used EternalBlue as its propagation mechanism in May 2017. The same exploit was later reused by NotPetya and other malware, so patching the vulnerability neutralizes the entire family of threats that depend on it.
Do I need to worry about EternalBlue if SMBv1 is disabled?
Disabling SMBv1 removes the vulnerable code path, so a host with SMBv1 turned off is not exploitable via CVE-2017-0144. Because SMBv1 is deprecated and unnecessary in modern environments, disabling it is the recommended defense in depth even on patched systems. Confirm the change across every host, since re-enabling can happen through legacy application requirements or imaging mistakes.
How was EternalBlue patched?
Microsoft released the MS17-010 security bulletin on March 14, 2017, with updates for each affected Windows build. Applying that update fixes the flawed size calculation in the SMBv1 server driver. During the WannaCry emergency, Microsoft also issued out-of-band patches for end-of-life Windows XP and Server 2003, an unusual move that underscored how severe the flaw was.