CVE-2025-21285

What it actually does

This vulnerability affects Microsoft Message Queuing (MSMQ) and can allow a remote attacker to cause a denial of service against a Windows system running the MSMQ service. At a technical level, the vulnerable service can be driven into an abnormal failure or resource-exhaustion condition by crafted network traffic sent to MSMQ-exposed interfaces. Successful exploitation does not imply code execution or data theft by itself, but it can interrupt message processing, crash or destabilize the MSMQ service, and potentially disrupt applications that depend on queued messaging. The issue is rated CVSS 7.5 and has a relatively elevated EPSS score, indicating that broad exploitation is plausible even though it is not currently listed in CISA KEV and no mature public exploit is indicated in the provided data.

Why it matters to the business

Organizations using MSMQ for application messaging may experience service outages, delayed transactions, failed integrations, or degraded business workflows if exposed systems are attacked. Because MSMQ is often used as middleware between applications, the visible impact may appear as application failures, stalled jobs, or message backlog rather than as an obvious security incident. Internet-exposed or broadly reachable MSMQ services carry the highest operational risk. Although this vulnerability is not currently known to be used in ransomware campaigns or listed in CISA KEV, its age and EPSS score justify prioritizing remediation on systems where MSMQ is enabled.

How an attack unfolds

An attacker first identifies Windows hosts with Microsoft Message Queuing enabled, commonly by scanning for MSMQ-related network exposure such as TCP port 1801 or RPC-accessible MSMQ services. If the service is reachable, the attacker sends crafted traffic designed to trigger the denial-of-service condition in MSMQ. When exploitation succeeds, the MSMQ service may crash, hang, consume excessive resources, or stop processing messages. Applications depending on MSMQ can then experience failed message delivery, backlogs, timeouts, or transaction failures. An attacker may repeat the traffic to sustain the outage after service recovery or system restart.

How to fix it

Apply the Microsoft security update that addresses CVE-2025-21285, released as part of the January 2025 Microsoft security updates, to all Windows systems where MSMQ is installed. Because no per-product fixed build numbers were provided, use Microsoft Security Update Guide and endpoint patch inventory to confirm the applicable KBs for each supported Windows version. If MSMQ is not required, remove or disable the Microsoft Message Queuing feature. Restrict MSMQ exposure to only trusted application hosts using host firewalls, network ACLs, and segmentation; do not expose MSMQ directly to the internet. Limit access to TCP port 1801 and any related RPC paths required by MSMQ. Ensure service recovery settings and monitoring are in place so that message queue disruption is detected quickly, but do not treat service restart as a substitute for patching.

How to confirm the fix worked

Confirm that January 2025 or later Microsoft security updates applicable to each Windows build are installed on systems with MSMQ enabled. Validate whether MSMQ is installed by checking Windows Features, service inventory, or PowerShell queries for the MSMQ feature and the Message Queuing service. Confirm whether the service is running and whether TCP port 1801 is reachable from untrusted network segments. After remediation, verify that the vulnerable hosts are patched, unnecessary MSMQ services are disabled or removed, and firewall rules prevent unauthorized access. Application owners should confirm that dependent message-processing workflows continue to function after patching or feature removal.

Typical attack path

1. Identify Windows systems with Microsoft Message Queuing installed or exposed on the network.
2. Probe for MSMQ access, commonly including TCP port 1801 and related RPC service exposure.
3. Send crafted MSMQ network traffic to the vulnerable service.
4. Trigger MSMQ service failure, hang, or resource exhaustion.
5. Repeat the request pattern to keep the service unavailable or to disrupt dependent applications.
6. Monitor externally visible application behavior to confirm outage or degradation.

How to detect it

To determine whether exploitation may already have occurred, review Windows System event logs for unexpected Message Queuing service failures, service restarts, or crashes around periods of application disruption. Focus on Service Control Manager events showing that the MSMQ service terminated unexpectedly, Windows Error Reporting events for mqsvc.exe, and application logs showing message delivery failures, queue buildup, or timeouts. Review firewall, IDS, NetFlow, and Windows Filtering Platform logs for unusual inbound traffic to TCP port 1801 or repeated connection attempts to MSMQ services, especially from untrusted or unexpected sources. Correlate service failures with spikes in inbound MSMQ traffic. If packet capture is available, inspect for repeated malformed or anomalous MSMQ traffic preceding mqsvc.exe crashes or service hangs. Since this is a denial-of-service issue, evidence may be limited to availability symptoms rather than persistence artifacts, new files, or credential access indicators.

• mqsvc.exe
• MSMQ
• Message Queuing
• TCP/1801
• port 1801
• The Message Queuing service terminated unexpectedly
• Service Control Manager
• Event ID 7031
• Event ID 7034
• Windows Error Reporting
• Application Error
• Faulting application name: mqsvc.exe
• MSMQ service
• Message Queuing service

What your security team should do

• Prioritize patching Windows servers and workstations where Microsoft Message Queuing is installed and reachable over the network.
• Identify all systems with MSMQ enabled, including application servers where the feature may have been installed as a dependency.
• Block external and unnecessary lateral access to MSMQ, especially TCP port 1801 and related RPC exposure.
• Disable or remove MSMQ wherever it is not explicitly required by a supported application.
• Monitor for repeated MSMQ service crashes, unexpected restarts, message backlog growth, and unusual inbound traffic to MSMQ services.
• Review exposure from untrusted networks despite the absence of CISA KEV status, because the EPSS score indicates meaningful exploitation likelihood.
• Coordinate with application owners before disabling MSMQ to avoid disrupting legitimate message-queue workflows.