CVE-2026-32212

What it actually does

This is a local information disclosure vulnerability in Microsoft Windows Universal Plug and Play handling, specifically involving improper link resolution before file access in upnp.dll. A low-privileged, authenticated local user may be able to influence a file path using symbolic links, junctions, hard links, mount points, or other NTFS reparse-point behavior so that a privileged Windows component reads or exposes data from a file the user should not normally be able to access. The vulnerability does not provide remote code execution or direct privilege escalation by itself, but it can disclose highly sensitive local data and may be useful as part of a broader attack chain.

Why it matters to the business

An attacker who already has local access to an affected Windows workstation or server could obtain sensitive information from the system, potentially including configuration data, credentials, tokens, service metadata, or other protected files depending on what can be reached through the vulnerable file access path. This can increase the impact of an initial compromise, support lateral movement, or help an attacker escalate through other weaknesses. The CVSS score is moderate, EPSS is currently low and stable, there is no known CISA KEV listing, and no public exploit maturity is reported, so urgency is lower than for actively exploited remote vulnerabilities; however, the broad Windows client and server exposure makes routine patching important.

How an attack unfolds

An attacker first needs valid local code execution or an interactive/logon session on an affected Windows system. They identify a UPnP-related file operation performed by Windows through upnp.dll where path validation or authorization occurs before final link resolution. The attacker prepares a controlled filesystem location and places a symbolic link, junction, hard link, or reparse-point chain that initially appears to reference an allowed path but ultimately resolves to a protected file. They then trigger the affected UPnP workflow locally, causing the Windows component to follow the attacker-controlled link and access the target file. If successful, the vulnerable behavior discloses contents or metadata from a file that the attacker’s account would otherwise be unable to read. Because this is a local information disclosure issue, exploitation generally leaves filesystem and process-execution traces rather than network-facing exploit signatures.

How to fix it

Apply the Microsoft security update that fixes CVE-2026-32212 for the affected Windows version. Since no exact fixed build numbers were provided, use the latest cumulative update or security-only update applicable to Windows 10, Windows 11, Windows Server 2012, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2022 23H2, and Windows Server 2025 systems. Prioritize internet-facing servers, multi-user systems, VDI/session hosts, developer workstations, jump hosts, and systems where untrusted or lower-privileged users can execute code. If immediate patching is not possible, reduce local attack opportunity by restricting interactive logon, limiting who can create symbolic links, enforcing least privilege, monitoring reparse-point creation in writable directories, and disabling unnecessary UPnP-related services only where operationally safe and validated.

How to confirm the fix worked

Confirm that the applicable Microsoft cumulative or security update has been installed for each affected Windows version. Validate through Windows Update, WSUS, Microsoft Configuration Manager, Intune, or endpoint vulnerability management tooling. Check OS build and installed hotfix history using standard Windows inventory methods such as Settings > Windows Update > Update history, Control Panel installed updates, Get-HotFix, wmic qfe, or enterprise patch reporting. Where feasible, verify that vulnerability scanners no longer report exposure for CVE-2026-32212. For compensating controls, confirm that non-administrative users cannot create arbitrary symbolic links unless explicitly required, that developer mode or symlink privileges are not broadly enabled, and that UPnP-related services are disabled only on systems where they are not needed.

Typical attack path

1. Obtain low-privileged local access to an affected Windows client or server.
2. Determine whether the system is unpatched and includes the vulnerable UPnP component.
3. Create an attacker-controlled directory or file path in a writable location such as a user profile or temporary directory.
4. Create a symbolic link, junction, hard link, mount point, or other NTFS reparse point that redirects the expected UPnP file access to a protected target file.
5. Trigger the vulnerable UPnP-related file access path locally.
6. Collect the disclosed file contents or metadata.
7. Use the disclosed information to support credential theft, privilege escalation, lateral movement, or follow-on exploitation.

How to detect it

There is no known public exploit maturity, KEV listing, or reported ransomware use for this issue, so detection should focus on local filesystem abuse patterns rather than fixed malware indicators. Review Windows Security logs, Sysmon telemetry, EDR file-event telemetry, PowerShell logs, and command-line auditing for suspicious creation of symbolic links, junctions, hard links, mount points, or reparse points in user-writable locations shortly before UPnP-related service activity. Relevant log sources include Windows Security Event ID 4688 for process creation, Event ID 4663 for object access if auditing is enabled, Sysmon Event ID 1 for process creation, Sysmon Event ID 11 for file creation, Sysmon Event ID 12/13/14 for registry activity, PowerShell Event ID 4104 for script block logging, and EDR telemetry that records NTFS reparse-point creation. Hunt for mklink.exe/cmd.exe usage, fsutil reparsepoint or hardlink commands, PowerShell New-Item link creation, and suspicious svchost.exe instances loading upnp.dll or hosting UPnP Device Host/SSDP Discovery that access unexpected user-profile or temporary paths. Investigate any sequence where a low-privileged user creates a link in a writable directory and a Windows service soon afterward reads a protected file, especially files under Windows, ProgramData, service configuration directories, or credential-related locations.

• upnp.dll
• upnphost
• SSDPSRV
• UPnP Device Host
• SSDP Discovery
• mklink
• mklink /D
• mklink /J
• mklink /H
• fsutil reparsepoint
• fsutil hardlink
• New-Item -ItemType SymbolicLink
• New-Item -ItemType Junction
• New-Item -ItemType HardLink
• CreateSymbolicLink
• IO_REPARSE_TAG_SYMLINK
• IO_REPARSE_TAG_MOUNT_POINT
• \Windows\System32\upnp.dll
• svchost.exe -k LocalService
• svchost.exe -k LocalServiceAndNoImpersonation

What your security team should do

• Patch affected Windows clients and servers during the next regular security update cycle; accelerate patching for shared servers, jump hosts, VDI, and systems allowing many local users.
• Inventory all affected Windows versions, including older Windows Server 2012 and Windows 10 builds, and ensure they are still receiving security updates or are isolated until upgraded.
• Review local privilege boundaries: restrict interactive logon, remove unnecessary local administrator rights, and limit the ability for standard users to create symbolic links or abuse reparse points.
• Enable or tune endpoint detections for suspicious link creation using mklink, fsutil, PowerShell New-Item -ItemType SymbolicLink/Junction/HardLink, and unusual reparse-point activity in user-writable directories.
• Hunt for unusual access to sensitive files by UPnP-related service contexts or svchost instances hosting UPnP/SSDP services.
• If UPnP functionality is not required on servers or hardened workstations, evaluate disabling UPnP Device Host and SSDP Discovery services after compatibility testing.
• Treat any confirmed exploitation as a potential precursor to privilege escalation or lateral movement and perform credential, token, and sensitive file exposure review.