CVE-2026-54992, a Critical Microsoft Message Queuing Queue Manager code-execution vulnerability, is fixed in Microsoft’s July 14, 2026 security updates and should move quickly through patch queues on systems running MSMQ. The flaw affects supported Windows client and server releases, including Windows 11 24H2 through 26H1 and Windows Server 2012 through Windows Server 2025.
Microsoft’s Security Update Guide describes the issue as a heap-based buffer overflow in the Message Queuing Queue Manager. Cisco Talos independently highlighted the vulnerability in its July Patch Tuesday analysis and placed it among the Critical remote-code-execution bugs Microsoft considers more likely to be exploited.
The important qualification is buried in the scoring rather than the title. CVE-2026-54992 carries a CVSS 3.1 base score of 8.4 and an attack vector of local, meaning Microsoft is not describing a simple unauthenticated attack sent directly across the Internet. An attacker requires a way to interact with the vulnerable component from the affected system, but no existing privileges or user interaction are required once that condition is met.
Microsoft’s title calls CVE-2026-54992 a remote code execution vulnerability, while the CVSS vector is AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In practical terms, the bug has low attack complexity, requires no privileges, needs no victim interaction, and can produce a complete loss of confidentiality, integrity, and availability—but the vulnerable path is classified as locally reachable.
That distinction matters for incident triage. Administrators should not treat CVE-2026-54992 as equivalent to an unauthenticated network worm that can compromise any exposed MSMQ endpoint with a packet sent to TCP port 1801. It is still a serious memory-corruption flaw, however, and software that can feed data into Queue Manager may provide an attacker with a route to the vulnerable code.
The weakness is classified as CWE-122, a heap-based buffer overflow. Such errors occur when software writes more data into a heap allocation than it can safely hold, potentially corrupting adjacent memory and redirecting program execution. Cisco Talos’ description corroborates the underlying bug class but does not provide exploit mechanics, message formats, or proof-of-concept code.
Microsoft marks the vulnerability as confirmed. That report confidence rating means the vendor has validated the vulnerability and its technical basis; it does not mean exploitation has been observed. At publication, Microsoft and the Zero Day Initiative listed CVE-2026-54992 as neither publicly disclosed nor exploited in the wild.
This is also where the exploitability assessment deserves more weight than the absence of current attacks. Microsoft rates exploitation as more likely, suggesting that the company believes practical exploitation is plausible enough to warrant elevated attention. Administrators should not wait for public exploit code before acting, particularly on shared servers where untrusted applications, middleware, or users can reach MSMQ functionality.
MSMQ is not required on every Windows installation. The affected operating-system list is consequently broader than the list of systems that are practically exposed: a Windows build can contain vulnerable code without having Message Queuing installed or active.
That makes service discovery the first useful administrative step. Security teams should identify machines with the Message Queuing Windows feature installed, check whether the Message Queuing service is running, and map which applications submit or consume messages on those hosts. Windows Server estates deserve particular attention because MSMQ deployments frequently sit behind application tiers and may not appear in conventional lists of Internet-facing services.
Network segmentation remains useful, but it is not a substitute for the update. The local CVSS attack vector means merely blocking inbound MSMQ traffic at the perimeter does not remove every plausible path. A compromised application account, malicious local process, exposed middleware interface, or second-stage payload could potentially use the flaw to deepen control over a host.
Organizations that cannot patch immediately should reduce the reachable surface by disabling MSMQ where it is installed but unused. Where the service is operationally required, administrators should restrict access to trusted systems and accounts, monitor unusual queue activity, and avoid making untested configuration changes that could interrupt dependent applications.
Administrators should verify the installed OS build after deployment rather than relying solely on a successful update job. Cumulative-update installation failures, pending reboots, and machines missing from WSUS or Microsoft Configuration Manager collections can leave nominally patched groups below the corrected build level.
Because MSMQ often supports business-critical applications, testing should include more than confirming that Windows boots. Teams should validate private and public queue operations, transactional messaging, authentication, service startup, application acknowledgements, and any clustering or failover behavior tied to Message Queuing.
The wider July release is unusually large, with BleepingComputer counting 570 Microsoft vulnerabilities and 59 rated Critical. That volume creates a prioritization problem, but CVE-2026-54992 has several characteristics that keep it near the top: memory corruption, no privileges required in the scored attack path, high impact across all three CVSS security properties, and Microsoft’s “exploitation more likely” assessment.
For most environments, the practical order is straightforward: inventory MSMQ, deploy the July cumulative updates to those systems early, confirm the corrected builds, and then test the applications whose queues make the service difficult to patch casually. The absence of known exploitation is a deployment window, not a reason to defer the fix.
Microsoft’s Security Update Guide describes the issue as a heap-based buffer overflow in the Message Queuing Queue Manager. Cisco Talos independently highlighted the vulnerability in its July Patch Tuesday analysis and placed it among the Critical remote-code-execution bugs Microsoft considers more likely to be exploited.
The important qualification is buried in the scoring rather than the title. CVE-2026-54992 carries a CVSS 3.1 base score of 8.4 and an attack vector of local, meaning Microsoft is not describing a simple unauthenticated attack sent directly across the Internet. An attacker requires a way to interact with the vulnerable component from the affected system, but no existing privileges or user interaction are required once that condition is met.
The RCE Label Needs Careful Reading
Microsoft’s title calls CVE-2026-54992 a remote code execution vulnerability, while the CVSS vector is AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In practical terms, the bug has low attack complexity, requires no privileges, needs no victim interaction, and can produce a complete loss of confidentiality, integrity, and availability—but the vulnerable path is classified as locally reachable.That distinction matters for incident triage. Administrators should not treat CVE-2026-54992 as equivalent to an unauthenticated network worm that can compromise any exposed MSMQ endpoint with a packet sent to TCP port 1801. It is still a serious memory-corruption flaw, however, and software that can feed data into Queue Manager may provide an attacker with a route to the vulnerable code.
The weakness is classified as CWE-122, a heap-based buffer overflow. Such errors occur when software writes more data into a heap allocation than it can safely hold, potentially corrupting adjacent memory and redirecting program execution. Cisco Talos’ description corroborates the underlying bug class but does not provide exploit mechanics, message formats, or proof-of-concept code.
Microsoft marks the vulnerability as confirmed. That report confidence rating means the vendor has validated the vulnerability and its technical basis; it does not mean exploitation has been observed. At publication, Microsoft and the Zero Day Initiative listed CVE-2026-54992 as neither publicly disclosed nor exploited in the wild.
This is also where the exploitability assessment deserves more weight than the absence of current attacks. Microsoft rates exploitation as more likely, suggesting that the company believes practical exploitation is plausible enough to warrant elevated attention. Administrators should not wait for public exploit code before acting, particularly on shared servers where untrusted applications, middleware, or users can reach MSMQ functionality.
MSMQ’s Optional Status Narrows the Real Attack Surface
Microsoft Message Queuing, commonly known as MSMQ, is a Windows messaging technology that lets applications exchange queued messages even when the sender and receiver are not simultaneously available. It remains common in older enterprise applications, manufacturing systems, financial workflows, integration middleware, and line-of-business software built around asynchronous processing.MSMQ is not required on every Windows installation. The affected operating-system list is consequently broader than the list of systems that are practically exposed: a Windows build can contain vulnerable code without having Message Queuing installed or active.
That makes service discovery the first useful administrative step. Security teams should identify machines with the Message Queuing Windows feature installed, check whether the Message Queuing service is running, and map which applications submit or consume messages on those hosts. Windows Server estates deserve particular attention because MSMQ deployments frequently sit behind application tiers and may not appear in conventional lists of Internet-facing services.
Network segmentation remains useful, but it is not a substitute for the update. The local CVSS attack vector means merely blocking inbound MSMQ traffic at the perimeter does not remove every plausible path. A compromised application account, malicious local process, exposed middleware interface, or second-stage payload could potentially use the flaw to deepen control over a host.
Organizations that cannot patch immediately should reduce the reachable surface by disabling MSMQ where it is installed but unused. Where the service is operationally required, administrators should restrict access to trusted systems and accounts, monitor unusual queue activity, and avoid making untested configuration changes that could interrupt dependent applications.
July’s Cumulative Updates Carry the Fix
The correction ships through the July 14 Windows cumulative security updates. Microsoft’s affected-version data places the fixed build boundaries at the following releases:- Windows 11 24H2 is updated to build 26100.8875, while Windows 11 25H2 reaches build 26200.8875.
- Windows 11 26H1 is updated to build 28000.2525.
- Windows 10 21H2 and 22H2 are updated to builds 19044.7548 and 19045.7548 respectively.
- Windows Server 2016 is updated to build 14393.9339, and Windows Server 2019 reaches build 17763.9020.
- Windows Server 2022 is updated to build 20348.5386.
- Windows Server 2025 reaches build 26100.33158.
Administrators should verify the installed OS build after deployment rather than relying solely on a successful update job. Cumulative-update installation failures, pending reboots, and machines missing from WSUS or Microsoft Configuration Manager collections can leave nominally patched groups below the corrected build level.
Because MSMQ often supports business-critical applications, testing should include more than confirming that Windows boots. Teams should validate private and public queue operations, transactional messaging, authentication, service startup, application acknowledgements, and any clustering or failover behavior tied to Message Queuing.
One MSMQ Fix Among Several July Queue Bugs
CVE-2026-54992 is not the only Message Queuing vulnerability in the July 2026 release. Microsoft also addressed CVE-2026-50439 in the Queue Manager and CVE-2026-50447 and CVE-2026-50505 in the broader Windows Message Queuing service, all classified as remote-code-execution issues. The accompanying vulnerabilities have different severity and attack characteristics, but together they make MSMQ a distinct patching focus this month.The wider July release is unusually large, with BleepingComputer counting 570 Microsoft vulnerabilities and 59 rated Critical. That volume creates a prioritization problem, but CVE-2026-54992 has several characteristics that keep it near the top: memory corruption, no privileges required in the scored attack path, high impact across all three CVSS security properties, and Microsoft’s “exploitation more likely” assessment.
For most environments, the practical order is straightforward: inventory MSMQ, deploy the July cumulative updates to those systems early, confirm the corrected builds, and then test the applications whose queues make the service difficult to patch casually. The absence of known exploitation is a deployment window, not a reason to defer the fix.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: securityweek.com
Patch Tuesday: Remote Code Execution Flaw in Microsoft Message Queuing
The Windows vulnerability carries a CVSS severity score of 9.8/10 and can be exploited by via specially crafted malicious MSMQ packets.www.securityweek.com - Related coverage: techradar.com
Microsoft quietly patches LNK vulnerability that's been weaponized for years | TechRadar
The November Patch Tuesday fixed an age-old bugwww.techradar.com
