CVE-2026-100202 is a remote-code-execution bug in Microsoft Message Queuing (MSMQ), the Windows component that lets distributed applications place work in durable queues for another application to collect later. An attacker does not need an account, privileges, or user interaction: Microsoft says a specially crafted network message sent to a host running the MSMQ service can lead to code execution.
That makes this worth separating from the much larger Windows estate. MSMQ is an optional service, not something every Windows endpoint uses. The exposure sits with servers and application hosts where Queue Manager is enabled and reachable from an attacker’s network position — especially where message traffic can cross network segments or, worse, where the service is internet-reachable.
A malformed message can outlive its memory
The defect is a use-after-free (CWE-416) in Queue Manager. In plain terms, the service can continue using a piece of memory after it has released it. A carefully formed message can exploit that broken lifetime handling, potentially steering the service into running attacker-controlled code. The advisory assigns a 9.8 CVSS score and describes the outcome as unauthorized code execution over a network; its affected-build boundaries and the server variants in scope are documented in the CNA record.
Queue Manager is the part of MSMQ that owns local queues, accepts messages from applications or other queue managers, stores or forwards them, and delivers them to recipients. That architecture is useful when systems are intermittently connected or processing must be asynchronous, but it also means a messaging listener may exist on a server that operators do not think of as externally facing.
The likely population is Windows-based line-of-business and distributed application environments: financial and e-commerce processing, workflow systems, field applications, and operational deployments such as embedded or transport-supporting systems. Legacy .NET, WCF, and BizTalk stacks are also plausible places to find MSMQ. The advisory does not establish how many exposed instances exist, so teams should inventory rather than assume their environment is unaffected.
Patch enabled Queue Manager hosts first
Microsoft released fixes in the October 13, 2026 Windows security updates. The practical priority is to identify every machine with MSMQ installed and the service enabled, then patch those systems through the normal Windows Update, Windows Update for Business, Microsoft Update Catalog, or WSUS path. For validation, compare OS builds with Microsoft’s published fixed boundaries; for example, Server 2016 needs 10.0.14393.9612 or later, Server 2019 needs 10.0.17763.9376 or later, Server 2022 needs 10.0.20348.5761 or later, and Server 2025 needs 10.0.26100.33650 or later.
Until updates are deployed, reduce which hosts can reach MSMQ with network segmentation and restrictive firewall rules, and remove or disable MSMQ where no application depends on it. Do not treat that as a substitute for the patch: a trusted internal sender, compromised peer, or overlooked route may still satisfy the network requirement.
No public exploitation evidence so far
As of October 19, 2026, Microsoft recorded exploitation as no and assessed exploitation as “Less Likely”; reporting likewise found no detected exploitation. CVE-2026-100202 was not in CISA’s Known Exploited Vulnerabilities catalogue, and no public proof of concept or exploit code had surfaced in searches of common repositories and exploit indexes. That is not evidence that private exploit development does not exist.
This was not the exploited Windows Shell issue from the same release, CVE-2026-96951. Still, unauthenticated network code execution in a service that may be quietly supporting business workflows deserves a fast, measured response: inventory MSMQ, constrain reachability, patch, and verify the resulting builds. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs.
