Is CVE-2017-0145 (Microsoft SMBv1 Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2017-0145 to its Known Exploited Vulnerabilities catalogue on 10 February 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. The SMBv1 server in multiple Microsoft Windows versions allows remote attackers to execute arbitrary code via crafted packets.

What “being exploited in the wild” means for CVE-2017-0145

For this CVE, the practical question is not whether the flaw exists, but whether there is evidence that attackers are already using it outside a lab. CISA’s KEV listing is the key signal here, because it reflects confirmed active exploitation, not just theoretical exposure. For defenders, that changes the problem from vulnerability tracking to incident-ready response.

The SMBv1 service path matters because exploitation can occur remotely through crafted traffic, so exposure is often broader than teams expect. If SMBv1 is still enabled on any Windows system, the issue is not only code execution risk but also how quickly an attacker could turn a single reachable host into a foothold for lateral movement.

When a vulnerability is known to be exploited in the wild, the operational question becomes whether the asset is internet-facing, internally reachable, or already exposed through a trusted segment. That distinction drives urgency, because an internal-only asset can still be a serious enterprise risk if it is reachable from compromised endpoints or legacy management networks.

How to confirm exposure and reduce blast radius

Start by identifying every system that still supports SMBv1, then determine whether that support is business-critical or merely legacy compatibility. If SMBv1 is enabled and not essential, the safest course is to remove it rather than treat the issue as a normal patching exercise. If the protocol must remain for a short period, its reachable scope should be reduced as much as possible.

Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog as the authoritative sources for required action and prioritisation. For vulnerability context and record-level confirmation, the CVE Program and NIST National Vulnerability Database are the right reference points, but they should complement, not replace, your remediation workflow.

Because the exploitation condition is confirmed rather than speculative, mitigation should be paired with verification. That means checking whether SMBv1 is actually disabled, whether the affected hosts still answer on the relevant ports, and whether any compensating controls are only documented rather than enforced.

What to do if patching or removal is delayed

If immediate removal of SMBv1 is not possible, treat the environment as temporarily exposed and narrow the attack surface aggressively. The useful response is to isolate the affected hosts, restrict who can reach them, and watch for unusual SMB activity or follow-on authentication attempts. Delay without containment is usually how a known exploited flaw becomes an incident.

Teams should also assume that an exploited remote code execution path may have been used before remediation completed. That means validating whether the host shows signs of pre-remediation compromise, not just whether the configuration has now been corrected. A clean patch state does not prove the system was never touched.

Where the server may have held privileged sessions, shared administrative access, or sensitive internal connectivity, rotate the relevant credentials and review access paths. The point is not to rotate everything automatically, but to focus on the accounts and sessions most likely to have been reachable from the vulnerable service.

Risk and Threat Considerations

Confirmed in-the-wild exploitation changes the risk posture from “known vulnerability” to “probable attacker interest.” With SMBv1 exposed, the main concern is not only initial code execution, but also rapid pivoting into adjacent systems if the compromised host has trust relationships, cached credentials, or broad network reach.

Failure mechanism: An attacker sends crafted SMB traffic to a reachable SMBv1 service, obtains execution on the target, and then uses that access to enumerate credentials, move laterally, or stage additional payloads before defenders complete containment.

Impact: The consequence can extend well beyond a single host, because one exploited Windows system may become a foothold for domain access, ransomware deployment, or broader internal compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	SMBv1 exposure is a configuration weakness that should be disabled or hardened.
Recommendation — Disable SMBv1 and enforce secure baseline configurations on all Windows assets.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A KEV-listed exploited vulnerability requires timely remediation and verification.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation depends on finding systems that still support the vulnerable service path.
	SC-7 — Boundary Protection	Network restriction and segmentation reduce reachability of the exploited SMB service.
Recommendation — Prioritise remediation for actively exploited flaws and verify the fix was applied. Scan for vulnerable SMBv1 systems and confirm the actual exposed population. Restrict network paths to vulnerable hosts until SMBv1 is removed.

Practitioner Guidance

What to prioritise: Put exposed SMBv1 systems ahead of ordinary backlog work, especially where they are reachable from user subnets, management networks, or external-facing segments. The priority is exposure reduction first, then root-cause cleanup and compromise checking.

What to verify: Confirm not just that a fix was scheduled, but that SMBv1 is actually disabled or removed, the host is no longer reachable in the vulnerable way, and the system has been checked for suspicious activity that predates remediation.

Decision rule: If the system can be reached by untrusted or broadly trusted internal networks, treat it as urgent containment work. If the host is business-critical and cannot be changed immediately, contain it with segmentation and tight access controls until removal is complete.

Practitioner takeaway: For a KEV-listed flaw, the key decision is not whether it is exploitable, but whether you can still justify keeping the exposed service path alive while proving the host has not already been compromised.