← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:100464 · Disclosed 2017-05-09

Microsoft Windows SMBv1 Multiple Vulnerabilities

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This finding is more like spotting an old lock on the door than proving the door is still unlocked

Tenable plugin 100464 fires when a Windows host still supports SMBv1 and then maps that exposure to the May 2017 SMBv1 bug cluster: info leak (CVE-2017-0267/0268/0270/0271/0274/0275/0276), DoS (CVE-2017-0269/0273/0280), and RCE (CVE-2017-0272/0277/0278/0279). The affected Windows generations called out by Microsoft/NVD are legacy-era builds including Windows 7 SP1, Server 2008 SP2 / 2008 R2 SP1, Windows 8.1, Server 2012 / 2012 R2, early Windows 10 releases through 1703, and Server 2016 when SMBv1 server is enabled.

The vendor HIGH label matches the *theoretical impact* of the worst CVE, but it overstates what this specific plugin actually proves in 2026. Tenable explicitly says the remote check can be inaccurate on newer Windows versions and recommends local patch checks instead; it is really detecting SMBv1 exposure, not reliably proving the host missed a 2017 patch. That friction, plus the lack of cited public exploitation for this exact CVE set, pushes this down to a solid MEDIUM unless you confirm a missing KB locally or find the host exposed on 445/tcp.

"This is mostly a legacy-protocol exposure signal, not proof you still have a live 2017 SMB RCE hole"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find an SMBv1-speaking host

An attacker first needs a reachable Windows system listening on 445/tcp and willing to negotiate SMBv1. Commodity tooling like nmap --script smb-protocols or exposure platforms such as runZero can identify hosts that still speak the deprecated protocol.
Conditions required:
  • Target host must expose SMB on 445/tcp or 139/tcp
  • SMBv1 server support must still be enabled
Where this breaks in practice:
  • Most modern Windows builds do not install SMBv1 by default
  • Perimeter firewalls commonly block inbound SMB from the internet
  • Many enterprises restrict lateral SMB between segments
Detection/coverage: High coverage for protocol discovery. Nmap smb-protocols, Tenable plugin 100464, and exposure tools can all flag SMBv1 support, but that is not the same as confirming missing May 2017 patches.
STEP 02

Reach the vulnerable code path

The attacker must negotiate SMBv1 and deliver specially crafted SMB packets that hit one of the 2017 request-handling flaws. The worst-case path is the RCE set represented by CVE-2017-0272, which is unauthenticated and network-reachable in theory.
Conditions required:
  • Unauthenticated network reachability to the SMB service
  • A truly unpatched vulnerable Windows build, not just SMBv1 enabled
Where this breaks in practice:
  • This plugin does not reliably prove the target is unpatched
  • Tenable notes remote accuracy problems on later Windows unless anonymous pipe/share access is allowed
  • Tenable also states no known exploits are available for this plugin's representative CVE source
Detection/coverage: Remote scanners can overcall here. Credentialed Windows bulletin checks are the right way to confirm missing patches on supported hosts.
STEP 03

Trigger crash, leak, or code execution

If the host is actually missing the 2017 fix set, the crafted packet can cause information disclosure, denial of service, or arbitrary code execution in the SMBv1 server. From there the attacker either knocks over the file server or lands code execution in a service context.
Conditions required:
  • Target must be on the historical affected build train
  • Relevant May/June 2017 security update (or later superseding cumulative update) must be absent
Where this breaks in practice:
  • Most still-supported Windows systems have long since superseded these fixes through cumulative servicing
  • Legacy systems that still keep SMBv1 are often isolated precisely because they are brittle
Detection/coverage: Host telemetry should show SMB service crashes, anomalous srv/SMB errors, or suspicious child-process behavior if exploitation succeeds. Network IDS may see malformed SMB packets, but coverage is uneven for niche 2017 bug classes.
STEP 04

Use SMB foothold for lateral movement

Once code execution or service disruption is achieved, the operator pivots into standard Windows post-exploitation: credential theft, share access, service creation, and ransomware staging. The blast radius depends far more on east-west reachability and privilege hygiene than on the SMB bug alone.
Conditions required:
  • Successful exploit or crash effect
  • Useful adjacent targets or credentials in the environment
Where this breaks in practice:
  • EDR, SMB signing policies, segmentation, and local admin controls limit follow-on value
  • A single legacy SMBv1 box is bad hygiene, but not automatically enterprise-wide compromise
Detection/coverage: EDR and Windows eventing usually catch the post-exploitation phase better than the exploit itself. Focus on service creation, remote admin shares, suspicious SMB sessions, and abnormal process trees off services.exe.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusI found no direct CISA KEV evidence for CVE-2017-0267 through CVE-2017-0280. CISA's broadly exploited SMBv1 history centers on other CVEs such as the MS17-010 family, not this exact May 2017 set.
Proof-of-concept availabilityTenable marks the representative issue as Exploit Ease: No known exploits are available. That is a major downgrade from headline SMBv1 bugs like EternalBlue, which defenders often confuse with this plugin.
EPSSPublic mirrors of FIRST EPSS data show CVE-2017-0272 at roughly 5.5% EPSS (0.05522), which is not trivial but nowhere near today's aggressively exploited edge-service CVEs. Validate the exact live score in your own EPSS feed before using it for SLA overrides.
KEV statusNot KEV-listed for the representative CVE-2017-0272 based on current CISA KEV catalog review; therefore there is no KEV due date tied to this plugin as written.
CVSS vectorTenable/NVD use CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H from CVE-2017-0272, base 8.1 HIGH. Translation: unauthenticated network attack, but with high attack complexity, which matters in the real world.
Affected versionsMicrosoft/NVD scope the RCE CVE to Windows 7 SP1, Server 2008 SP2 / 2008 R2 SP1, Windows 8.1, Server 2012 / 2012 R2, Windows RT 8.1, Windows 10 Gold/1511/1607/1703, and Server 2016. All of that assumes the SMBv1 server path is actually available.
Fixed versionsFor supported platforms, the fix landed on 2017-05-09 and is carried forward by later cumulative updates. Microsoft also shipped extra coverage for unsupported lines in Security Advisory 4025685 on 2017-06-13 after WannaCry.
Scanning and detection realityThe plugin requires SMB/SMBv1_is_supported and Tenable warns it cannot always correctly determine vulnerability on later Windows versions unless anonymous access to named pipes/shares is allowed. In plain English: this is a weak remote heuristic and should be validated with credentialed bulletin checks.
Exposure populationMicrosoft says SMBv1 is not installed by default in Windows 11 or Windows Server 2019+. If you still have this finding, you are usually looking at legacy debt, a manual re-enable, or an old estate that already deserves containment.
Disclosure and attributionMicrosoft was the CNA/source for CVE-2017-0272; Tenable lists vulnerability publication date 2017-05-09, while NVD shows published 2017-05-12. I found no public external researcher attribution on the core Microsoft/NVD records.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.8/10)

The single biggest reason this lands in MEDIUM is that plugin 100464 is not a reliable patch-state signal; it mostly tells you SMBv1 is still enabled. High theoretical impact does not beat the practical friction that the host may already be patched, and Tenable says exactly that for later Windows releases.

HIGH This plugin is better treated as SMBv1 exposure/misconfiguration than as confirmed missing 2017 patch state
MEDIUM Direct exploitation likelihood for the exact CVE cluster behind the plugin

Why this verdict

  • Baseline starts high: the representative CVE (CVE-2017-0272) is unauthenticated network RCE with NVD/Tenable 8.1 HIGH
  • Downshift #1 — attacker reachability is narrower in real estates: exploitation requires direct SMB access on 445, which is usually blocked externally and often segmented internally
  • Downshift #2 — the plugin mostly proves SMBv1 support, not missing patches: Tenable says the remote check can be inaccurate on later Windows and recommends local bulletin checks
  • Downshift #3 — no strong exploitation evidence for this exact CVE set: Tenable lists no known exploits, and I found no KEV listing for the May 2017 SMBv1 CVEs in this plugin
  • Amplifier kept it above LOW: SMBv1 is still dangerous legacy protocol debt, and if the host is truly unpatched the impact is still ugly

Why not higher?

Because this is not the same thing as confirmed MS17-era patch absence. The decisive friction is that the scanner is keying on SMBv1 being enabled, and Tenable itself warns the remote determination can be wrong on newer Windows builds. Without credentialed confirmation or real exposure on 445, calling this HIGH just manufactures urgency.

Why not lower?

I did not drop it to LOW because SMBv1 should not be hanging around in a mature estate, and the worst-case impact behind the finding is still unauthenticated network-side RCE. If one of these hosts is legacy, flat-networked, or externally reachable, the operational risk rises fast even if the plugin is noisy.

05 · Compensating Control

What to do — in priority order.

  1. Validate with credentialed checks — Use Tenable's local Windows bulletin plugins or another credentialed patch source to separate SMBv1 enabled from actually missing May/June 2017 fixes. For a MEDIUM verdict there is no mitigation SLA; do this as the first triage step and then remediate within the 365-day window if it is just protocol debt.
  2. Disable SMBv1 where business allows — Turn off the SMBv1 client/server components on hosts that do not have a hard legacy dependency. This removes the protocol attack surface entirely; for a MEDIUM verdict there is no mitigation SLA — go straight to the remediation plan and complete retirement within 365 days.
  3. Fence legacy SMB islands — If SMBv1 must remain for old devices or applications, isolate those systems with host firewalls, VLAN segmentation, and strict allowlists for 445/tcp. There is no formal mitigation SLA at MEDIUM, but containment should happen during normal hardening rather than waiting for next year's cleanup.
  4. Block internet exposure of SMB — Ensure 445/tcp and 139/tcp are not internet-reachable and are tightly controlled east-west. This matters because the exploit path requires direct network access; treat any external SMB exposure as an exception that should be removed immediately even though the noisgate bucket here is MEDIUM.
  5. Audit for active SMBv1 use — Enable SMB auditing and inventory which clients still require SMBv1 so you can retire the dependency instead of preserving it forever for folklore reasons. Use that data to drive application-owner cleanup inside the 365-day remediation window.
What doesn't work
  • A WAF does nothing here; this is SMB, not HTTP.
  • Relying on 'Windows is fully patched' claims without credentialed evidence does not clear this plugin, because the finding is tied to protocol support and the remote check is imperfect.
  • Assuming SMB signing alone solves it is wrong; signing may harden parts of SMB, but it does not remove the vulnerable SMBv1 code path or the legacy exposure.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows host from an elevated PowerShell session. Example: powershell.exe -ExecutionPolicy Bypass -File .\check-tenable-100464.ps1; local admin is recommended because the script queries SMB server configuration, optional features, and installed hotfixes.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-tenable-100464.ps1

# Purpose: Triage Tenable plugin 100464 locally.

# Output: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=ERROR


$ErrorActionPreference = 'Stop'

function Write-Result {
    param(
        [string]$Status,
        [int]$Code,
        [string]$Reason
    )
    Write-Output "$Status - $Reason"
    exit $Code
}

try {
    $os = Get-CimInstance Win32_OperatingSystem
    $caption = $os.Caption
    $version = [version]$os.Version
    $build = [int]$os.BuildNumber

    # Determine whether SMBv1 server support is enabled.

    $smb1Enabled = $null
    try {
        $smbCfg = Get-SmbServerConfiguration -ErrorAction Stop
        $smb1Enabled = [bool]$smbCfg.EnableSMB1Protocol
    }
    catch {
        # Fallback for older hosts: registry/service heuristics.

        try {
            $reg = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters' -ErrorAction Stop
            if ($null -ne $reg.SMB1) {
                $smb1Enabled = ($reg.SMB1 -eq 1)
            }
        }
        catch {}
    }

    # Feature-state hint; SMB1 may be absent entirely on modern hosts.

    $featureState = $null
    try {
        $feature = Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -ErrorAction Stop
        $featureState = $feature.State
        if ($featureState -eq 'Disabled' -or $featureState -eq 'DisabledWithPayloadRemoved') {
            Write-Result 'PATCHED' 0 'SMBv1 optional feature is disabled or removed.'
        }
    }
    catch {}

    if ($smb1Enabled -eq $false) {
        Write-Result 'PATCHED' 0 'SMBv1 server protocol is disabled.'
    }

    if ($null -eq $smb1Enabled -and $null -eq $featureState) {
        Write-Result 'UNKNOWN' 2 'Unable to determine SMBv1 state on this host.'
    }

    # Historical affected trains for the representative May 2017 SMBv1 CVEs.

    $affected = $false
    if ($caption -match 'Windows 7') { $affected = $true }
    elseif ($caption -match 'Windows 8\.1') { $affected = $true }
    elseif ($caption -match 'Windows Server 2008') { $affected = $true }
    elseif ($caption -match 'Windows Server 2012') { $affected = $true }
    elseif ($caption -match 'Windows Server 2016') { $affected = $true }
    elseif ($caption -match 'Windows 10') {
        # Windows 10 through 1703 only. Build 15063 = 1703.

        if ($build -le 15063) { $affected = $true }
    }

    if (-not $affected) {
        Write-Result 'PATCHED' 0 "Host OS build ($caption $($os.Version) build $build) is outside the historical affected version range for the May 2017 SMBv1 CVEs."
    }

    if ($smb1Enabled -ne $true) {
        Write-Result 'UNKNOWN' 2 'OS is historically affected, but SMBv1 state could not be confirmed as enabled.'
    }

    # Patch-state heuristic:

    # Any later cumulative/hotfix activity strongly suggests the 2017 fix set was superseded.

    $latestHotfix = $null
    try {
        $latestHotfix = Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1
    }
    catch {}

    $cutoff = Get-Date '2017-06-13'
    if ($latestHotfix -and $latestHotfix.InstalledOn -ge $cutoff) {
        Write-Result 'PATCHED' 0 "SMBv1 is enabled, but the host has hotfix activity after $($cutoff.ToString('yyyy-MM-dd')); use this as a local triage result and still retire SMBv1."
    }

    if ($latestHotfix -and $latestHotfix.InstalledOn -lt (Get-Date '2017-05-09')) {
        Write-Result 'VULNERABLE' 1 'SMBv1 is enabled on a historically affected OS and no hotfixes later than 2017-05-09 were found.'
    }

    Write-Result 'UNKNOWN' 2 'SMBv1 is enabled on a historically affected OS, but patch state was not conclusively proven from local hotfix data. Use credentialed bulletin checks for confirmation.'
}
catch {
    Write-Error $_.Exception.Message
    exit 3
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat plugin 100464 as a cleanup-and-validation queue, not as proof of a live wormable SMB RCE. First pivot these assets into credentialed Windows patch checks to confirm whether they are actually missing the May/June 2017 fixes; then retire or isolate any remaining SMBv1 dependencies. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use the noisgate remediation SLA to remove SMBv1 or document the exception within 365 days. If any of these hosts are internet-exposed on 445/tcp, bypass the normal queue and fix the exposure immediately even though the bucket here stays MEDIUM.

Sources

  1. Tenable Nessus Plugin 100464
  2. Microsoft Security Advisory 4025685
  3. NVD CVE-2017-0272
  4. Microsoft: Detect, enable, and disable SMBv1/v2/v3
  5. Microsoft: SMBv1 not installed by default
  6. CISA Known Exploited Vulnerabilities Catalog
  7. CISA Vulnerability Summary for week of May 15, 2017
  8. Nmap smb-protocols NSE documentation
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.