CVE-2026-34329

What it actually does

This is a heap-based buffer overflow in Windows Message Queuing (MSMQ). An unauthenticated attacker on an adjacent network can send specially crafted MSMQ network traffic to a vulnerable Windows system with Message Queuing enabled, corrupt heap memory in the MSMQ service process, and potentially execute arbitrary code. Successful exploitation can provide high-impact compromise of confidentiality, integrity, and availability on the affected host. The attack requires network adjacency but does not require credentials or user interaction.

Why it matters to the business

A vulnerable system running Windows Message Queuing could be remotely compromised by an attacker on the same local or adjacent network segment, enabling service disruption, data access, lateral movement, or deployment of additional malware. This is especially important for Windows servers that support line-of-business applications using MSMQ, because exploitation could interrupt application messaging workflows or provide a foothold into broader infrastructure. The issue is not currently listed in CISA KEV, has low EPSS, and no public exploit maturity is reported, but the high CVSS impact and broad Windows version coverage make timely patching and exposure reduction important.

How an attack unfolds

An attacker first identifies Windows hosts on an adjacent network that expose MSMQ, commonly by looking for systems listening on MSMQ-related ports such as TCP 1801. The attacker then sends malformed MSMQ protocol traffic designed to trigger a heap overflow in the Message Queuing service. If the memory corruption is successfully controlled, the attacker can redirect execution within the MSMQ service process and run attacker-controlled code. After gaining code execution, the attacker may establish persistence, dump local data, disable defenses, move laterally to other reachable systems, or use the compromised host as a bridge deeper into the environment. Failed exploitation attempts may cause mqsvc.exe crashes or repeated Message Queuing service restarts.

How to fix it

Apply the Microsoft security update that addresses this vulnerability for all affected Windows versions, or install the latest cumulative update available for the affected operating system. Because no exact fixed build numbers were provided, organizations should validate directly against Microsoft Security Update Guide and ensure systems are updated to a release level published on or after the vendor fix for this issue. If MSMQ is not required, remove or disable the Message Queuing feature and stop the Message Queuing service. Restrict MSMQ exposure with host firewalls and network controls, allowing TCP 1801 and related MSMQ/RPC traffic only from trusted systems that require it. Segment servers that require MSMQ away from user workstations and untrusted adjacent networks. Where immediate patching is not possible, prioritize disabling MSMQ, blocking inbound MSMQ traffic, and increasing monitoring for service crashes or suspicious connections to MSMQ ports.

How to confirm the fix worked

Confirm whether the Message Queuing feature is installed and enabled on Windows systems. On servers and workstations, check for the MSMQ service and listening ports, for example by validating the Message Queuing service state and whether TCP 1801 is listening. Confirm that affected systems have installed the relevant Microsoft cumulative security update released for this vulnerability or a later superseding update. Validate firewall policy by confirming that untrusted adjacent network segments cannot connect to MSMQ listener ports. After patching or mitigation, rescan representative systems to verify that MSMQ is either no longer exposed or is reachable only from approved sources. Review Windows Update history, installed hotfixes, endpoint management inventory, and vulnerability scanner results to ensure all affected Windows 10, Windows 11, and Windows Server versions have been remediated.

Typical attack path

1. Gain access to the same broadcast domain, local network, VPN segment, compromised workstation, or other adjacent network path as the target system.
2. Scan for Windows systems with Message Queuing enabled and reachable MSMQ services, especially TCP 1801.
3. Send crafted MSMQ traffic that triggers heap corruption in the Message Queuing service.
4. Achieve code execution in the context of the vulnerable service process if exploitation succeeds.
5. Use the compromised host for follow-on actions such as credential access, persistence, lateral movement, or disruption of message-processing workloads.

How to detect it

To determine whether exploitation may have already occurred, review Windows event logs and endpoint telemetry for abnormal Message Queuing behavior. Useful sources include Windows Application logs, System logs, Windows Error Reporting, Microsoft-Windows-MSMQ operational logs if enabled, EDR process telemetry, firewall logs, network flow records, and IDS/IPS events for MSMQ traffic. Look for crashes of mqsvc.exe, repeated restarts of the Message Queuing service, unexplained service termination events, or inbound connections to TCP 1801 from unexpected adjacent-network hosts. Correlate any MSMQ crash or restart with preceding network traffic from the same source IP. Investigate follow-on behavior from the affected host, including unusual child processes spawned after mqsvc.exe activity, new services, scheduled tasks, credential access attempts, remote administration tool execution, or outbound connections to unfamiliar destinations. There are no public exploit-specific indicators provided, so detection should focus on service instability, unexpected MSMQ exposure, and post-exploitation behavior.

• C:\Windows\System32\mqsvc.exe
• mqsvc.exe
• Message Queuing
• MSMQ
• TCP/1801
• Faulting application name: mqsvc.exe
• Faulting module name: mqsvc.exe
• The Message Queuing service terminated unexpectedly
• The Message Queuing service entered the stopped state
• The Message Queuing service entered the running state
• Windows Error Reporting
• Event ID 7031
• Event ID 1000
• Event ID 1001
• Microsoft-Windows-MSMQ

What your security team should do

• Prioritize patching Windows servers and workstations with Message Queuing enabled, especially systems reachable from user networks, VPN networks, or shared infrastructure segments.
• Inventory MSMQ usage across Windows 10, Windows 11, Windows Server 2012, 2016, 2019, 2022, and 2025 systems; remove the feature where it is not required.
• Restrict inbound MSMQ traffic, especially TCP 1801, to known application peers only; block access from general workstation, guest, wireless, and VPN segments unless explicitly required.
• Monitor for mqsvc.exe crashes, Message Queuing service restarts, Windows Error Reporting events, and unusual inbound connections to MSMQ ports.
• Treat unexpected MSMQ exposure on servers or endpoints as a lateral-movement risk and include it in network segmentation reviews.
• Because the vulnerability is more than 90 days old, verify that standard patch compliance reporting has not missed long-lived or intermittently connected Windows assets.