CVE-2026-50447 exposes Windows Message Queuing Service to unauthenticated remote code execution through a heap-based buffer overflow, making the July 14 Windows security updates a priority for systems running MSMQ. Microsoft assigned the flaw a CVSS 3.1 score of 9.8 out of 10, reflecting an attack that can cross the network without credentials or user interaction and potentially compromise confidentiality, integrity, and availability.
Detailed in Microsoft’s Security Update Guide and recorded by the National Vulnerability Database, the vulnerability affects supported and extended-support releases ranging from Windows Server 2012 to Windows Server 2025, plus several Windows 10 and Windows 11 versions. Microsoft labels the issue Important rather than Critical, but its technical characteristics warrant exposure-based triage rather than reliance on the severity label alone.
Microsoft had not reported public disclosure or active exploitation when the vulnerability was published on July 14, 2026. The Zero Day Initiative’s July security-update review and the SANS Internet Storm Center likewise listed it as neither publicly known nor exploited.
CVE-2026-50447 is classified as CWE-122, a heap-based buffer overflow. Microsoft’s description says an unauthorized attacker can exploit the weakness over a network to execute code on an affected Windows system.
The CVSS vector is
A successful exploit could therefore do considerably more than crash the Message Queuing service. Microsoft’s scoring anticipates high impact across data confidentiality, data integrity, and system availability, although the company has not publicly documented the resulting execution context or released proof-of-concept details.
The report-confidence value is confirmed. That metric indicates that Microsoft, as the assigning authority and affected vendor, has confirmed the vulnerability and that the available technical account is considered credible. It should not be confused with evidence of exploitation: confidence that a bug exists does not mean attackers are already using it.
MSMQ provides asynchronous message delivery for distributed Windows applications, allowing systems to exchange queued messages even when a destination is temporarily unavailable. It remains relevant in enterprise middleware, older line-of-business software, transactional applications, and bespoke services that have survived multiple Windows Server upgrade cycles.
Microsoft’s network-port documentation identifies TCP 1801 as the principal MSMQ service port, with additional ports used for directory integration, management, RPC, and diagnostics. An exposed listener does not prove that a machine is exploitable, but it gives administrators a concrete place to begin checking reachability.
Affected client releases include Windows 10 versions 1607, 1809, 21H2, and 22H2, as well as Windows 11 versions 24H2, 25H2, and 26H1. Some entries remain relevant only through specialized servicing channels or extended security arrangements, but administrators should not assume an older deployment is outside the advisory simply because it is absent from a normal consumer fleet.
The fixed build thresholds published with the CVE include:
Windows Server 2025 is addressed by KB5099536, taking it to build 26100.33158. Administrators responsible for Windows Server 2012 or 2012 R2 should verify the applicable July Monthly Rollup or security-only package against their servicing entitlement rather than attempting to apply a package intended for a newer branch.
The first operational step is to identify machines where the Message Queuing service exists and determine whether it is running. That inventory should be correlated with listening ports, firewall policy, application dependencies, network zones, and whether untrusted clients can initiate connections to the queue manager.
Internet exposure on TCP 1801 deserves immediate investigation. Internal-only servers are not automatically safe: a network-reachable, unauthenticated RCE can become a valuable lateral-movement path after an attacker compromises a workstation, VPN account, web server, or other foothold inside the perimeter.
Blocking unnecessary inbound MSMQ traffic can reduce exposure while updates move through testing, but filtering is a compensating control rather than a replacement for the patch. Environments that require MSMQ should restrict access to known application hosts and management networks instead of allowing broad workstation-to-server connectivity.
Removing or disabling MSMQ may be appropriate where the feature is unused, but administrators should test that decision carefully. Legacy applications can depend on private queues, transactional delivery, or local service behavior without documenting MSMQ as an obvious prerequisite.
That caution has recent operational context. Microsoft’s December 2025 security changes caused MSMQ-related failures in some enterprise applications and IIS workloads, leaving administrators understandably wary of applying another update to queue-dependent systems without validation. The existence of that earlier regression does not justify delaying a network-reachable RCE fix, but it does strengthen the case for a focused canary group and application-level monitoring.
Security teams should also watch for failed or malformed MSMQ connections, unusual traffic to TCP 1801, unexpected service crashes, and new processes spawned around queue-processing workloads. Microsoft has not provided enough public exploit detail to define a high-confidence signature, so behavior and reachability remain more useful than searching for one specific packet pattern.
As of July 15, CVE-2026-50447 was not listed as actively exploited, and NVD was still awaiting its own enrichment beyond Microsoft’s CNA data. The window for orderly deployment is therefore open, but unauthenticated network access, low attack complexity, and full-impact scoring make it a poor candidate for a routine end-of-month patch cycle.
Detailed in Microsoft’s Security Update Guide and recorded by the National Vulnerability Database, the vulnerability affects supported and extended-support releases ranging from Windows Server 2012 to Windows Server 2025, plus several Windows 10 and Windows 11 versions. Microsoft labels the issue Important rather than Critical, but its technical characteristics warrant exposure-based triage rather than reliance on the severity label alone.
Microsoft had not reported public disclosure or active exploitation when the vulnerability was published on July 14, 2026. The Zero Day Initiative’s July security-update review and the SANS Internet Storm Center likewise listed it as neither publicly known nor exploited.
A Malformed Message Can Cross the Trust Boundary
CVE-2026-50447 is classified as CWE-122, a heap-based buffer overflow. Microsoft’s description says an unauthorized attacker can exploit the weakness over a network to execute code on an affected Windows system.The CVSS vector is
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In practical terms, the vulnerable component is network-accessible, exploitation requires low attack complexity, no privileges are required, and no user needs to open a file, click a link, or approve a prompt.A successful exploit could therefore do considerably more than crash the Message Queuing service. Microsoft’s scoring anticipates high impact across data confidentiality, data integrity, and system availability, although the company has not publicly documented the resulting execution context or released proof-of-concept details.
The report-confidence value is confirmed. That metric indicates that Microsoft, as the assigning authority and affected vendor, has confirmed the vulnerability and that the available technical account is considered credible. It should not be confused with evidence of exploitation: confidence that a bug exists does not mean attackers are already using it.
MSMQ provides asynchronous message delivery for distributed Windows applications, allowing systems to exchange queued messages even when a destination is temporarily unavailable. It remains relevant in enterprise middleware, older line-of-business software, transactional applications, and bespoke services that have survived multiple Windows Server upgrade cycles.
Microsoft’s network-port documentation identifies TCP 1801 as the principal MSMQ service port, with additional ports used for directory integration, management, RPC, and diagnostics. An exposed listener does not prove that a machine is exploitable, but it gives administrators a concrete place to begin checking reachability.
The Affected List Spans Multiple Server Generations
Microsoft’s affected-product record covers Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server 2022, and Windows Server 2025. Server Core installations are explicitly included where Microsoft lists them separately.Affected client releases include Windows 10 versions 1607, 1809, 21H2, and 22H2, as well as Windows 11 versions 24H2, 25H2, and 26H1. Some entries remain relevant only through specialized servicing channels or extended security arrangements, but administrators should not assume an older deployment is outside the advisory simply because it is absent from a normal consumer fleet.
The fixed build thresholds published with the CVE include:
- Windows Server 2016 and Windows 10 version 1607 are fixed at build 14393.9339.
- Windows Server 2019 and Windows 10 version 1809 are fixed at build 17763.9020.
- Windows Server 2022 is fixed at build 20348.5386.
- Windows Server 2025 is fixed at build 26100.33158.
- Windows 11 version 24H2 is fixed at build 26100.8875.
- Windows 11 version 25H2 is fixed at build 26200.8875.
- Windows 11 version 26H1 is fixed at build 28000.2269 or later in Microsoft’s affected-version record.
Windows Server 2025 is addressed by KB5099536, taking it to build 26100.33158. Administrators responsible for Windows Server 2012 or 2012 R2 should verify the applicable July Monthly Rollup or security-only package against their servicing entitlement rather than attempting to apply a package intended for a newer branch.
Exposure Matters More Than Feature Presence
MSMQ is installed as a Windows feature rather than being required by every Windows deployment. That limits the practical attack surface, but enterprise inventories often undercount optional components installed years earlier as application prerequisites.The first operational step is to identify machines where the Message Queuing service exists and determine whether it is running. That inventory should be correlated with listening ports, firewall policy, application dependencies, network zones, and whether untrusted clients can initiate connections to the queue manager.
Internet exposure on TCP 1801 deserves immediate investigation. Internal-only servers are not automatically safe: a network-reachable, unauthenticated RCE can become a valuable lateral-movement path after an attacker compromises a workstation, VPN account, web server, or other foothold inside the perimeter.
Blocking unnecessary inbound MSMQ traffic can reduce exposure while updates move through testing, but filtering is a compensating control rather than a replacement for the patch. Environments that require MSMQ should restrict access to known application hosts and management networks instead of allowing broad workstation-to-server connectivity.
Removing or disabling MSMQ may be appropriate where the feature is unused, but administrators should test that decision carefully. Legacy applications can depend on private queues, transactional delivery, or local service behavior without documenting MSMQ as an obvious prerequisite.
Patch Quickly, Then Validate the Queue
The July cumulative updates contain other security and compatibility changes, so normal deployment testing still applies. MSMQ environments in particular should verify queue creation, message delivery, transactional processing, service startup, application-pool behavior, clustering where used, and recovery after reboot.That caution has recent operational context. Microsoft’s December 2025 security changes caused MSMQ-related failures in some enterprise applications and IIS workloads, leaving administrators understandably wary of applying another update to queue-dependent systems without validation. The existence of that earlier regression does not justify delaying a network-reachable RCE fix, but it does strengthen the case for a focused canary group and application-level monitoring.
Security teams should also watch for failed or malformed MSMQ connections, unusual traffic to TCP 1801, unexpected service crashes, and new processes spawned around queue-processing workloads. Microsoft has not provided enough public exploit detail to define a high-confidence signature, so behavior and reachability remain more useful than searching for one specific packet pattern.
As of July 15, CVE-2026-50447 was not listed as actively exploited, and NVD was still awaiting its own enrichment beyond Microsoft’s CNA data. The window for orderly deployment is therefore open, but unauthenticated network access, low attack complexity, and full-impact scoring make it a poor candidate for a routine end-of-month patch cycle.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Official source: learn.microsoft.com
Service overview and network port requirements - Windows Server | Microsoft Learn
A roadmap of ports, protocols, and services that are required by Microsoft client and server operating systems, server-based applications, and their subcomponents to function in a segmented network.learn.microsoft.com
