CVE-2023-21769

What it actually does

CVE-2023-21769 is a network-reachable denial-of-service vulnerability in Microsoft Message Queuing (MSMQ). An unauthenticated attacker can send specially crafted traffic to a Windows system running the Message Queuing service and cause availability impact, such as service disruption, process failure, resource exhaustion, or system instability. The vulnerability does not provide code execution, privilege escalation, or data theft by itself, but it can interrupt applications that depend on MSMQ for reliable message delivery. The CVSS vector indicates remote exploitation over the network with low attack complexity, no privileges required, and no user interaction required, with high availability impact.

Why it matters to the business

Organizations using MSMQ may experience interruption of business workflows that rely on queued message delivery, including application-to-application messaging, transaction processing, background job handling, integration middleware, and legacy Windows-based services. Because exploitation can be performed remotely without authentication, internet-exposed or broadly reachable MSMQ services are higher risk. Although it is not listed in CISA KEV and no ransomware use is indicated, the EPSS score is high, so security teams should treat exposed MSMQ instances as a priority availability risk, especially for critical Windows servers and applications that depend on message queues.

How an attack unfolds

An attacker first identifies Windows hosts exposing Microsoft Message Queuing, most commonly by scanning for MSMQ network services such as TCP port 1801. If the Message Queuing service is enabled and reachable, the attacker sends malformed or specially crafted MSMQ protocol traffic to the target. The vulnerable service mishandles the input, causing denial-of-service conditions such as MSMQ service failure, degraded responsiveness, or disruption to queue processing. The attacker can repeat the traffic to maintain the outage until the system is patched, MSMQ is disabled, service access is blocked, or compensating network controls prevent further reachability.

How to fix it

Apply the Microsoft security updates that address CVE-2023-21769 for all affected Windows versions, including supported Windows 10, Windows 11, Windows Server 2008, 2012, 2016, 2019, and 2022 releases. If MSMQ is not required, disable or remove the Microsoft Message Queuing feature. If MSMQ is required, restrict access to trusted systems only using host firewalls, network firewalls, and segmentation; do not expose MSMQ services to the internet. Block unnecessary inbound access to MSMQ-related services, especially TCP port 1801, and review whether any additional MSMQ RPC or queue access paths are reachable. For unsupported or end-of-life systems, migrate to supported versions or isolate them aggressively because they may not receive effective security updates.

How to confirm the fix worked

Confirm that applicable Microsoft security updates from April 2023 or later are installed on affected Windows systems. Validate that the Message Queuing service is disabled where it is not needed. Where MSMQ is required, confirm that inbound access to TCP port 1801 is limited to authorized application peers and is not internet-exposed. Use vulnerability scanners, authenticated patch inventory, Windows update compliance tools, and network scans to verify remediation. Operationally, confirm that queue-dependent applications continue to function after patching or service hardening and that MSMQ does not accept traffic from untrusted networks.

Typical attack path

1. Scan networks for Windows hosts with Microsoft Message Queuing exposed, especially TCP port 1801.
2. Confirm the target is running the Message Queuing service and accepts MSMQ traffic.
3. Send specially crafted MSMQ packets to the vulnerable service without authentication.
4. Trigger service disruption, crash, resource exhaustion, or interruption of queue processing.
5. Repeat the traffic as needed to prolong application or service outage.
6. Move to other reachable MSMQ-enabled systems if network segmentation allows broad access.

How to detect it

To determine whether exploitation may have already occurred, review Windows System and Application event logs for Message Queuing service crashes, unexpected service stops, repeated restarts, or application errors around queue processing. Examine Microsoft-Windows-MSMQ event logs where enabled, service control manager events, Windows Error Reporting entries, crash dumps, and monitoring alerts for mqsvc.exe. Correlate these artifacts with network telemetry showing unexpected or high-volume inbound connections to MSMQ, especially TCP port 1801, from untrusted or unusual source addresses. Look for repeated patterns of MSMQ failure followed by recovery, bursts of malformed or anomalous traffic, and simultaneous queue-processing disruption across multiple hosts. Because this is a denial-of-service issue, evidence may be limited to availability symptoms and network activity rather than durable malware artifacts.

• TCP/1801 inbound to Windows hosts running Microsoft Message Queuing
• mqsvc.exe
• Message Queuing service terminated unexpectedly
• The Message Queuing service terminated unexpectedly
• The Message Queuing service entered the stopped state
• The Message Queuing service entered the running state
• Service Control Manager Event ID 7031
• Service Control Manager Event ID 7034
• Windows Error Reporting faulting application name: mqsvc.exe
• Microsoft-Windows-MSMQ
• MSMQ

What your security team should do

• Prioritize patching internet-exposed, DMZ, externally reachable, and business-critical Windows systems running Microsoft Message Queuing.
• Inventory all systems with the Message Queuing feature installed or the Message Queuing service running.
• Disable MSMQ wherever it is not explicitly required by an application or business process.
• Restrict inbound MSMQ access, especially TCP port 1801, to trusted application hosts only.
• Review firewall and segmentation rules to ensure MSMQ is not reachable from untrusted networks or broad user segments.
• Monitor for unusual spikes in MSMQ traffic, repeated service crashes, and application outages involving message queues.
• Create SIEM detections for MSMQ service failures, restarts, and network connections to MSMQ from unexpected sources.
• For legacy Windows Server versions, verify extended security update coverage or isolate and migrate them.
• Because EPSS is high, treat exposed instances as urgent even though the CVE is not currently listed in CISA KEV.