How to Fix CVE-2019-1405: Improper Privilege Management in Microsoft Windows

Actively exploited. Listed in the CISA Known Exploited Vulnerabilities catalog since 2022-03-15; federal civilian agencies had to remediate by 2022-04-05. This is a local elevation of privilege, so it is most dangerous as the second stage of an attack chain on multi-user, terminal-server, or already-breached hosts. Install the November 2019 (or later) Windows security update.

What is CVE-2019-1405?

CVE-2019-1405 is an elevation-of-privilege flaw in the Windows Universal Plug and Play (UPnP) Device Host service (the upnphost / SSDPSRV family that ships with the OS). The service improperly allows COM object creation in a way that lets a low-privileged caller instantiate and drive COM objects in a higher-privileged context. Microsoft titles it the “Windows UPnP Service Elevation of Privilege Vulnerability.”

The CWE assigned by CISA's vulnrichment is CWE-269: Improper Privilege Management. In plain terms, the service does not correctly enforce the privilege boundary between the caller and the COM objects it brokers, so code that should run as a normal user ends up executing with the service's elevated rights, in practice, NT AUTHORITY\SYSTEM.

Two things matter for how you prioritise this. First, the attack vector is Local (AV:L), with Low privileges required and no user interaction: the attacker must already be able to execute code on the box as some user, but from there the path to SYSTEM is reliable. Second, it carries a CVSS 3.1 base score of 7.8 (High) with HIGH impact to confidentiality, integrity, and availability, because SYSTEM is total control. This is the classic post-exploitation primitive: it does not get an attacker onto the machine, it makes them root once they are there. That is why it belongs in any compromise-recovery and terminal-server hardening checklist, even though it cannot be triggered straight off the internet.

A public exploit exists. Packet Storm published a working local privilege escalation for this issue (referenced below), and CISA's KEV listing confirms it has been used in real intrusions. Assume weaponised code is available.

Identify whether you are affected

This is an operating-system flaw, so “your version” is the Windows build and its patch level, not an application version. The affected list covers essentially every supported branch at the time: Windows 7 SP1, 8.1 and RT 8.1, Windows 10 (RTM through 1903), and Windows Server 2008 / 2008 R2 / 2012 / 2012 R2 / 2016 / 2019 plus the 1803 and 1903 Server Core installations. If a host predates the November 2019 cumulative update, treat it as vulnerable.

Check the installed update level from an elevated PowerShell prompt:

# Show OS build and the most recent installed hotfixes
[System.Environment]::OSVersion.Version
Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15

# Is the UPnP Device Host service even running? (reduces exposure if stopped)
Get-Service SSDPSRV, upnphost | Select-Object Name, Status, StartType

Cross-reference the newest InstalledOn date against the November 2019 Patch Tuesday (12 November 2019). The authoritative per-build KB list lives in the MSRC advisory, pick the row matching your exact build and architecture.

How to fix CVE-2019-1405

The fix is the Microsoft security update released on 12 November 2019 for your specific Windows build. There is no standalone “patched version number” to upgrade to. you apply the monthly cumulative (Windows 10 / Server 2016+) or the security-only / monthly rollup (Windows 7 / 8.1 / Server 2008–2012 R2) that contains the fix. These install through Windows Update, WSUS/SCCM, or a manually downloaded MSU. They do not install through winget, apt, dnf, or any package manager.

Windows Update (PowerShell, run as administrator)

# Option A: PSWindowsUpdate module (installs all pending security updates)
Install-Module PSWindowsUpdate -Force -Scope CurrentUser -ErrorAction SilentlyContinue
Import-Module PSWindowsUpdate
Get-WindowsUpdate -Install -AcceptAll -IgnoreReboot -Category 'Security Updates'

# Confirm the update installed, then reboot to finalise
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10
Restart-Computer -Force

Windows Update (native, no extra module)

# Trigger a scan + download + install using the built-in update client
UsoClient.exe StartScan
UsoClient.exe StartDownload
UsoClient.exe StartInstall
# Then reboot when the install completes
shutdown.exe /r /t 60 /c "Reboot to finalise CVE-2019-1405 security update"

Manual install from the Microsoft Update Catalog (offline / WSUS-free hosts)

# 1. On a connected machine, find the KB for your exact build:
#    https://www.catalog.update.microsoft.com/Search.aspx?q=CVE-2019-1405
# 2. Download the matching .msu (correct OS + architecture), copy to the target, then:
$msu = "$env:USERPROFILE\Downloads\windows-kb-x64.msu"   # rename to the file you downloaded
wusa.exe $msu /quiet /norestart
shutdown.exe /r /t 60 /c "Reboot to finalise security update"

Fleet rollout (WSUS / SCCM / Intune)

For managed estates, approve the November 2019 (or any later cumulative, fixes are cumulative for Win10/Server 2016+) security update for the affected collections and let the management agent stage and reboot it. Because this is a local-only EoP, prioritise hosts where untrusted or many users can run code: RDS/terminal servers, jump boxes, shared workstations, build agents, and any host already flagged in an incident.

If you can't patch immediately

There is no official workaround in the MSRC advisory, and because the trigger is local COM activation rather than a network listener, blocking firewall ports does not mitigate it. The realistic interim controls reduce who can run code on the host and shrink the attack surface of the UPnP service:

• Stop / disable the UPnP Device Host service where it is not needed (it is rarely required on servers or hardened workstations). This removes the vulnerable service entirely:

# Disable the UPnP Device Host (and SSDP discovery it depends on) if unused
Stop-Service upnphost -Force -ErrorAction SilentlyContinue
Set-Service  upnphost -StartupType Disabled
Stop-Service SSDPSRV  -Force -ErrorAction SilentlyContinue
Set-Service  SSDPSRV  -StartupType Disabled
Get-Service upnphost, SSDPSRV | Select-Object Name, Status, StartType

• Restrict who can log on or execute code on multi-user hosts. Tighten “Allow log on locally” / “Allow log on through Remote Desktop Services”, enforce AppLocker or WDAC so unprivileged users cannot drop and run arbitrary binaries, and remove standing local-admin where possible. Since the exploit needs an authenticated local foothold, fewer foothold-capable accounts means fewer realistic attackers.
• Watch for the exploit primitive. Treat unexpected child processes spawned by svchost.exe hosting upnphost, or new SYSTEM-level processes parented off an interactive user session, as suspicious until the patch lands.

These are stopgaps. The only real fix is the November 2019 security update.

Resolve and verify

1. Re-run Get-HotFix and confirm the November 2019 (or a later cumulative) security update KB is present, with an InstalledOn date on or after the patch was applied. The OS build number should match a patched build in the MSRC advisory for your branch.
2. Run an authenticated vulnerability scan (Nessus, Qualys, OpenVAS, Microsoft Defender Vulnerability Management) against the host. CVE-2019-1405 must no longer be reported.
3. If you suspect the host was already compromised before patching: this is a KEV-listed, post-exploitation EoP, assume an attacker may have reached SYSTEM. Hunt for SYSTEM-level persistence (new services, scheduled tasks, run keys), rotate credentials and cached secrets the machine held, and run full IR triage. A patched binary does not undo a prior compromise.
4. If you disabled the UPnP Device Host / SSDP services as a stopgap, decide whether to leave them disabled (preferred where unused) or re-enable them now that the patch is in place, and record the decision in your CMDB.

Is CVE-2019-1405 a remote vulnerability?

No. It is a local elevation-of-privilege flaw (CVSS vector AV:L). An attacker must already be able to run code on the machine as some user; the bug then lets them escalate to SYSTEM. It cannot be exploited directly over the network, so it is typically used as the second stage of an intrusion. That is also why blocking firewall ports does not mitigate it. patching does.

Which Windows update fixes CVE-2019-1405?

Microsoft fixed it in the 12 November 2019 Patch Tuesday release. There is no single “fixed version”; you install the security update for your exact build, the monthly cumulative on Windows 10 / Server 2016 and later, or the security-only / monthly rollup on Windows 7, 8.1, and Server 2008 through 2012 R2. The per-build KB numbers are listed in the MSRC advisory and the Microsoft Update Catalog.

What is the CVSS score and what does it mean here?

CVSS 3.1 base score 7.8 (High), vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Low attack complexity, only low privileges required, no user interaction, and total (HIGH) impact to confidentiality, integrity, and availability because the result is SYSTEM-level control of the host.

Can I just disable UPnP instead of patching?

Disabling the UPnP Device Host (upnphost) and SSDP Discovery (SSDPSRV) services removes the vulnerable service and is a reasonable stopgap on hosts that do not need UPnP. It is not a substitute for the update if the service is required, and it does nothing about any compromise that already happened. Apply the November 2019 security update as the real fix.

References

• Official vendor advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1405
• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2019-1405
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• http://packetstormsecurity.com/files/155723/Microsoft-UPnP-Local-Privilege-Elevation.html
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2019-1405

This guide was assembled from the official vendor advisory, NVD record, and CISA KEV listing on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Related fixes

Additional nearby issues sensible to fix in the same maintenance window:

• How to Fix CVE-2019-0703: Information Disclosure in Microsoft Windows
• How to Fix CVE-2019-1129: Improper Link Resolution Before File Access in Microsoft Windows
• How to Fix CVE-2019-1132: Elevation of Privilege in Microsoft Win32k
• How to Fix CVE-2019-0880: Elevation of Privilege in Microsoft Windows
• How to Fix CVE-2019-0859: Elevation of Privilege in Windows