Microsoft has delivered a security update for CVE-2025-53143, a remote code execution vulnerability in the Windows Message Queuing (MSMQ) service. The flaw, rooted in a type confusion error, allows an authorized attacker to send specially crafted network packets to TCP port 1801 and execute arbitrary code in the context of the mqsvc.exe service, which typically runs with SYSTEM privileges. Though the patch is now available, the vulnerability puts a spotlight on a decades-old, often-overlooked Windows component that still lurks on servers worldwide—one that made headlines in 2023 when Check Point Research revealed the unauthenticated QueueJumper exploit.

MSMQ, or Microsoft Message Queuing, is an optional middleware component present in all modern Windows versions, from Windows 11 to Windows Server 2022. Despite Microsoft’s own documentation growing stale after 2016, the service persists on thousands of production machines, quietly enabling legacy enterprise applications, vendor appliances, and even Exchange Server installations. It listens on TCP port 1801 by default, making it a tempting network-facing attack surface. The new CVE-2025-53143 is classified as an access-of-resource-using-incompatible-type vulnerability, commonly called type confusion. In a type confusion bug, the code treats a memory object as if it were a different data type, leading to pointer corruption, control flow hijacking, and ultimately, code execution.

MSMQ: The Legacy Service That Refuses to Die

Microsoft Message Queuing was designed for distributed, loosely-coupled messaging, offering guaranteed delivery, transaction support, and priority-based messaging. It remains available as an optional Windows feature, enabled with a few clicks in the Control Panel or via PowerShell’s Install-WindowsFeature MSMQ-Services. Many organizations unknowingly turn it on when deploying third-party software. For example, Check Point Research found that installing Microsoft Exchange Server with the recommended “Automatically install Windows Server roles and features” option silently enables MSMQ. The result: an Exchange server running mqsvc.exe on the same box, vastly expanding the attack surface.

An Internet scan by Check Point in early 2023 uncovered more than 360,000 IPs with port 1801 exposed to the public internet. The real number is likely far higher when internal networks are counted. Because MSMQ runs as a high-privilege system service, any remote code execution bug in its parsing or dispatch logic can hand an attacker immediate SYSTEM-level access. That’s exactly what happened with CVE-2023-21554 (QueueJumper), and though CVE-2025-53143 requires an authorized attacker, the risk remains severe.

CVE-2025-53143 at a Glance

According to the Microsoft Security Update Guide, CVE-2025-53143 is a type confusion vulnerability in Windows Message Queuing. Microsoft’s advisory describes it as “Access of resource using incompatible type”, which can lead to remote code execution when the service receives a malicious message. Crucially, the advisory states that an “authorized attacker” can trigger the flaw, meaning some level of authentication is presumably required before exploitation. This sets it apart from the unauthenticated QueueJumper disaster, but does not reduce the urgency: an attacker who has obtained even low-privileged credentials on a network could leverage this bug to escalate to SYSTEM remotely.

At the time of writing, Microsoft has not reported active exploitation in the wild, but the track record of MSMQ vulnerabilities argues for immediate patching. Previous MSMQ RCEs were quickly weaponized after disclosure, and Check Point’s research revealed multiple DoS flaws (CVE-2023-21769, CVE-2023-28302) alongside QueueJumper, proving that the codebase is brittle and full of dangerous parsing errors.

Type Confusion: A Primer

Type confusion (CWE-843) occurs in languages like C/C++ when a program accesses a memory location through a pointer that assumes a certain data type, but the underlying data actually conforms to a different type. For a networked service like MSMQ, an attacker crafts specially formed packets that corrupt the internal state of the message parser. The parser subsequently dereferences or calls a function pointer that points to attacker-controlled data, hijacking execution flow. Because mqsvc.exe runs with extensive privileges, a successful exploit yields immediate SYSTEM access, allowing the attacker to install malware, steal credentials, or move laterally.

The Check Point QueueJumper report detailed how a single packet to port 1801 could achieve unauthenticated RCE. CVE-2025-53143, while requiring authentication, follows the same dangerous pattern: network input + type confusion + high privilege = a critical risk.

Who Is at Risk?

Any Windows host with MSMQ installed and reachable over the network should be considered at risk. The highest-priority targets include:

  • Internet-facing servers with port 1801 exposed, even if hidden behind a misconfigured firewall.
  • Internal servers that accept MSMQ traffic from broad subnets or untrusted VLANs.
  • Appliances and software from third-party vendors that bundle MSMQ without the administrator’s awareness.
  • Machines where MSMQ is installed but the service is not actively used—silent risk that nobody audits.

CERT-EU and Check Point have consistently warned that inventorying MSMQ deployments is the first step for any defender. An asset management query for “Message Queuing” in Windows features or a simple check for the mqsvc service can reveal dangerous exposure within minutes.

Mitigation and Protection

Microsoft’s official fix is the security update associated with CVE-2025-53143; applying it to all affected systems is the primary defense. The WindowsForum advisory and past MSMQ response playbooks recommend a layered approach:

  1. Inventory and triage – Identify every server and client with MSMQ enabled. Use PowerShell (Get-WindowsFeature -Name MSMQ, Get-Service mqsvc) or group policy to scan large estates.
  2. Apply patches immediately – Push the Microsoft update to all affected machines, prioritizing exposed or critical assets. Validate patches in a test environment first if change control requires it, but do not delay rollout on high-risk systems.
  3. Temporary network mitigation – If patching cannot happen right away, block inbound TCP port 1801 at edge firewalls and host firewalls for all systems that do not strictly need to receive MSMQ traffic. Restrict legitimate MSMQ traffic to specific management IPs only.
  4. Disable MSMQ where unused – Remove the Windows feature and stop/disable the mqsvc service. This is a permanent hardening step recommended by Check Point and CERT-EU for every MSMQ vulnerability.
  5. Detection and monitoring – Configure EDR/SIEM rules to alert on suspicious mqsvc.exe child processes (e.g., spawned cmd.exe, powershell.exe), new autorun keys, or unexpected network connections to port 1801. Monitor event logs for MSMQ errors and system application crashes.

Historical Context: QueueJumper and the MSMQ Attack Surface

In April 2023, Check Point Research disclosed three vulnerabilities in MSMQ, collectively dubbed QueueJumper. The most critical, CVE-2023-21554, allowed unauthenticated RCE via a single crafted packet to port 1801. The discovery prompted a wave of patching and network hardening, but many organizations merely blocked external access to port 1801 without fully inventorying internal MSMQ instances. CVE-2025-53143 is a grim reminder that MSMQ’s codebase continues to harbor dangerous parsing bugs.

Check Point’s research highlighted how overlooked the service is: “MSMQ is a forgotten or legacy service, yet it is still available on all Windows operating systems.” The same research noted that installing Microsoft Exchange Server 2019 with default options silently enables MSMQ, dragging it onto countless critical mail servers. The report also provided detection signatures for IPS and SIEM systems, many of which remain relevant for identifying exploitation attempts against the new CVE.

CERT-EU’s 2023 advisory reinforced the same mitigations: patch, block port 1801, disable if not needed, and monitor for anomalous mqsvc activity. Those recommendations are now standard for every MSMQ-related CVE, including CVE-2025-53143.

Detection and Incident Response

Based on both the WindowsForum discussion and past MSMQ incident guidance, defenders should look for:

  • Network indicators: Inbound connections to TCP/1801 from untrusted IPs, especially after business hours, and sudden spikes in MSMQ traffic.
  • Host indicators: Unusual child processes spawned by mqsvc.exe (cmd.exe, powershell.exe, wscript.exe, or unknown binaries), creation of new services or scheduled tasks, and modifications to registry autorun keys.
  • Log analysis: Windows Event Logs for MSMQ (source “MSMQ”), System event ID 7031/7034 (service crashes), and Application event errors around the time of suspected intrusion.

If an exploit is suspected, isolate the machine from the network immediately while preserving volatile data (memory dump, running processes, network connections). Capture a forensic disk image and engage incident response per your organization’s playbook. Because mqsvc.exe runs as SYSTEM, assume the attacker gained full control of the machine and pivot capabilities.

FAQ

Q: Can CVE-2025-53143 be exploited without credentials?
A: Microsoft’s advisory explicitly states that an “authorized attacker” can achieve remote code execution. This strongly suggests that some level of authentication is required. The exact requirements (e.g., a valid domain account, a specific MSMQ permission) are not disclosed publicly, but the consensus is that this is not an unauthenticated wormable bug like QueueJumper. Still, an attacker with even limited network access could exploit it post-compromise to escalate privileges dramatically.

Q: If I block port 1801 at the firewall, am I safe?
A: Blocking port 1801 from untrusted networks is a powerful short-term mitigation against external attacks. However, an attacker who has already gained internal network access or can send messages via a compromised application host might still reach the service. Patching remains the definitive fix. Also, blocking port 1801 does not protect against local exploitation if the attacker is already on the machine.

Q: My vendor appliance uses MSMQ—what should I do?
A: Contact the vendor for compatibility guidance. Ask whether their product requires a specific MSMQ configuration and whether they will provide a validated patch. If immediate updating is impossible, isolate the appliance on a dedicated VLAN and restrict MSMQ traffic to only the necessary management IPs.

Closing Analysis

CVE-2025-53143 is not the first, and likely not the last, critical MSMQ vulnerability to rattle Windows administrators. The service’s privileged position, network exposure, and creaky legacy codebase make it a perennial target. While this particular bug requires an authorized attacker, the blast radius of a successful exploit is no less devastating: full SYSTEM compromise. Microsoft’s patch is the definitive remedy, but the history of QueueJumper proves that blocking port 1801, disabling MSMQ wherever unnecessary, and maintaining rigorous detection rules are indispensable layers of defense. For any organization still running MSMQ in 2025, the message is clear: inventory, patch, harden, and monitor—because the next packet to port 1801 could be the one that devastates your network.