Yes. CISA added CVE-2019-0703 to its Known Exploited Vulnerabilities catalogue on 23 May 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. An information disclosure vulnerability exists in the way that the Windows SMB Server handles certain requests, which could lead to information disclosure from the server.
What it means to be actively exploited in the wild
CISA’s KEV listing is the key operational signal here, because it means the vulnerability is not just theoretical or publicly documented, it is being observed in real attacks. For defenders, that changes the question from “Is there a bug?” to “Is any exposed Windows SMB Server still reachable, and can we prove it is not already being abused?”
When a Windows SMB issue reaches the KEV catalogue, the practical assumption should be that opportunistic scanning, follow-on exploitation, and rapid weaponisation may already be under way. That makes exposure management, not just patch awareness, the immediate concern.
For a vulnerability of this type, the first check is whether the affected Windows SMB Server instance is internet-facing, reachable from untrusted internal segments, or used in ways that broaden attack paths. If it is reachable anywhere that untrusted code, users, or devices can touch, treat it as a live exposure until proven otherwise.
Why SMB information disclosure matters operationally
An information disclosure weakness in SMB is not the same as a remote code execution flaw, but it can still be operationally serious. Exposed server information can assist reconnaissance, help an attacker map the environment, and improve the reliability of later intrusion steps, especially when paired with other Windows or network exposure. The point is not the single disclosure alone, but the way it supports a broader attack chain.
That is why SMB issues often deserve cross-team attention. Infrastructure, endpoint, and detection teams may each see only part of the problem, while the attacker sees one more way to learn about hosts, shares, naming, or service behavior. Lateral Movement Guide is useful context because SMB weaknesses frequently become part of the path attackers use after initial access.
The right response also depends on whether the affected host is a server, a file-sharing dependency, or a platform component with broad internal reach. A disclosure flaw on a quiet lab machine is one thing; the same flaw on a production SMB service with sensitive connectivity and many downstream users is a different operational risk entirely.
How to respond when patching is delayed
If you cannot patch immediately, the goal is to reduce exposure and narrow the blast radius while you verify whether the host has already been touched. Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide both map well to this kind of KEV-driven triage: confirm scope, prioritise by exposure, and treat delay as an exception that requires compensating controls.
Practical compensating measures usually include restricting SMB reachability to the smallest necessary set of hosts, tightening segmentation around file services, and increasing monitoring for anomalous SMB activity. If the system is externally reachable, the threshold for exception approval should be much higher than for an internal-only host.
Because KEV status implies active exploitation evidence, deferral should never be treated as a passive backlog item. It should be a time-bound risk decision with ownership, expiry, and a documented plan to validate whether the host remained uncompromised during the delay.
Risk and Threat Considerations
The main risk is not only disclosure itself, but what the disclosure enables when an attacker is already probing the environment. Active exploitation means the flaw may be used in mass scanning, opportunistic compromise attempts, or as a supporting step in a broader intrusion chain against Windows infrastructure.
Failure mechanism: Exposed SMB services can leak information that helps an attacker enumerate targets, refine follow-on exploits, or confirm that a host is worth deeper focus, especially where network exposure is broad and monitoring is weak.
Impact: The likely consequence is faster attacker reconnaissance and a greater chance that the vulnerable server becomes part of a larger compromise path, even if the disclosure itself does not directly execute code.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed SMB issues need prioritised discovery and remediation. |
| Recommendation — Prioritise, track, and remediate exposed SMB vulnerabilities on a strict SLA. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This is a live vulnerability remediation decision on Windows servers. |
| Recommendation — Apply and verify remediation for the SMB flaw as soon as exposure is confirmed. | ||
| NIST CSF 2.0 | ID.RA-01 — Threat and Vulnerability Identification | KEV status requires identifying vulnerable SMB assets and their exposure. |
| PR.IP-12 — Vulnerability Management | The page is about exploitability and remediation prioritisation. | |
| Recommendation — Identify affected SMB assets and classify their exposure for urgent treatment. Use a vulnerability management process that fast-tracks KEV-listed assets. | ||
| MITRE ATT&CK | T1040 — Network Sniffing | SMB information disclosure can support attacker recon over the network. |
| Recommendation — Monitor for network reconnaissance and correlate SMB exposure with suspicious probing. | ||
Practitioner Guidance
What to prioritise: Verify whether any Windows SMB Server instance is reachable from untrusted networks, then prioritise the most exposed production hosts first. A KEV-listed issue should be handled as a live exposure problem, not a routine patch queue item.
What to verify: Confirm patch or mitigation status, then check logs and network telemetry for SMB access patterns that would be unusual for the host’s normal role. If the environment lacks good SMB visibility, treat that as part of the risk, not as evidence of safety.
Escalation / exception: If patching must wait, require a documented exception with expiry, compensating controls, and explicit post-change validation. If the host is externally reachable or supports sensitive internal file access, escalate the issue rather than accepting an open-ended delay.
Practitioner takeaway: For KEV-listed SMB flaws, the defensible decision is to assume hostile interest already exists, reduce reachability immediately, and then validate whether the host was exposed before you decide whether the issue is just unpatched or already compromised.
Related resources from NHI Mgmt Group
- CVE-2019-0703 (Microsoft Windows SMB Information Disclosure)
- Is CVE-2025-24984 (Microsoft Windows NTFS Information Disclosure) being exploited in the wild?
- Is CVE-2019-1388 (Microsoft Windows Certificate Dialog Privilege Escalation) being exploited in the wild?
- Is CVE-2025-33073 (Microsoft Windows SMB Client Improper Access Control) being exploited in the wild?