Still running SMBv1? The catalog has a 2017 reminder for you.

Among the older Windows entries in the Known Exploited Vulnerabilities catalog is CVE-2017-0147, an SMBv1 server information-disclosure flaw. That CVE number is part of the MS17-010 family, the set of SMBv1 vulnerabilities patched in March 2017 after the Shadow Brokers leaked the NSA’s exploits, the family whose RCE member, EternalBlue, powered WannaCry and NotPetya weeks later. Alongside it sit a handful of legacy Windows privilege-escalation and browser bugs from 2016 through 2020 (CVE-2016-3351, CVE-2020-0638, CVE-2019-1385, CVE-2019-1130). They’re not a single campaign, but they share a profile and, more usefully, a remediation: these are old, long-patched Windows bugs, and you’re only exposed if you’re running unpatched or end-of-life Windows, with SMBv1 the standout liability.

The SMBv1 problem specifically

SMBv1 is the protocol that should already be gone from your environment, and the MS17-010 family is why. The EternalBlue-driven worms of 2017 caused billions in damage by spreading over SMBv1, and the protocol has no business running on a modern network. Microsoft has shipped Windows with SMBv1 disabled or uninstalled by default since Windows 10 1709 and Windows Server 2019, so if SMBv1 is active anywhere in your estate, something or someone re-enabled it or the host predates that change. Either way it’s a finding.

The broader cluster, the privilege-escalation and browser bugs, follows the familiar legacy pattern: each was fixed years ago, so the only systems still exposed are the ones that never took the updates, typically unmanaged, forgotten, or end-of-life machines. As with the legacy runtimes and end-of-life edge devices elsewhere in the catalog, the issue isn’t the patch (it exists); it’s the unpatched and unsupported hosts that the patch never reached.

What to do

• Disable and uninstall SMBv1 everywhere. This is the headline action. Audit for SMBv1 across the fleet and remove it; on supported Windows it’s already off by default, so the work is finding and fixing the exceptions. Nothing modern needs it, and its presence enables a class of worming attacks that the catalog still tracks.
• Patch supported Windows fully, including workstations. The legacy EoP bugs in this cluster were all fixed years ago. A current, fully-patched Windows machine is not exposed; the risk lives entirely on machines behind on updates. Make sure your patch coverage actually reaches every host, not just the ones in your inventory.
• Find and retire end-of-life Windows. Hosts past support, old Windows 7, Server 2008/2012, and the like, will never get fixes for new bugs and are the natural home for this whole stratum of exploited CVEs. Inventory them, isolate what you can’t immediately replace, and put migration on a real schedule.
• Don’t dismiss the local EoP bugs as low priority. As with every privilege-escalation flaw, these are the second stage an intruder uses after a foothold. On an unpatched or legacy host they’re a clean path to SYSTEM, so patching workstations matters as much as servers.
• Segment legacy and OT Windows. Where old Windows must persist (industrial control, medical, a vendor-locked appliance), block SMBv1 and unnecessary services at the network boundary and isolate the host, so a worm or an escalation can’t spread from it.

The reframe is consistent with the rest of the catalog’s legacy layer: these aren’t patching puzzles, they’re inventory-and-retirement work. A 2017 SMBv1 bug and a set of 2016-2020 Windows escalation flaws appear on a current exploited-vulnerabilities list because the affected systems are still out there, unpatched or unsupported, on networks where SMBv1 is somehow still answering. Kill SMBv1, keep supported Windows current, and retire what’s past its end of life, and this entire cluster stops being your problem. We track the legacy Windows entries as a class, because the action, find it and bring it current or take it out, is the same across all of them.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2017-0147 (Windows SMBv1 information disclosure) — 2017-03
• Microsoft: Detect, enable, and disable SMBv1, SMBv2, and SMBv3
• Microsoft MS17-010 security bulletin — 2017-03-14