This is a landmine in an optional basement room, not a grenade in every Windows box
CVE-2023-21554, aka *QueueJumper*, is an unauthenticated remote code execution bug in Microsoft Message Queuing (MSMQ). The flaw is improper input validation in MSMQ packet parsing, and public technical write-ups show it can be triggered with a crafted message over TCP/1801, leading to out-of-bounds writes in mqsvc.exe. The affected population is broad *if* MSMQ is installed: Windows Server 2008 SP2 through Server 2022 and multiple Windows 10/11 releases before the April 11, 2023 fixes; representative fixed builds include Windows 10 1607 14393.5850+, Server 2019 / Windows 10 1809 17763.4252+, Windows 10 20H2/21H2/22H2 1904x.2846+, Windows 11 21H2 22000.1817+, and Windows 11 22H2 / Server 2022 22621.1555+ / 20348.1668+.
Microsoft's CRITICAL 9.8 score is technically fair in a lab: no auth, no user interaction, remote code execution, wormable conditions. In enterprise reality, though, the biggest friction is brutal and simple: MSMQ is an *optional* Windows feature, not a universal default, and exploitation only matters where attackers can route to TCP/1801. That pushes this down from blanket-CRITICAL to HIGH for most fleets, while still making it an urgent fix for any server farms, middleware stacks, Exchange-era installs, or flat internal networks where MSMQ was quietly enabled.
4 steps from start to impact.
Find reachable MSMQ listeners
masscan/nmap, or passive internet intel from services like GreyNoise/Censys/Shodan, looking for TCP/1801. Check Point reported roughly 360,000 internet-exposed MSMQ hosts at disclosure, and WithSecure cited more than 400,000 exposed hosts. The attack surface is not 'all Windows'—it is 'Windows with MSMQ installed and network-reachable.'- Target has the
MSMQfeature installed - TCP/1801 is reachable from the attacker's network position
- Host is not shielded behind strict ACLs or segmentation
- MSMQ is an optional feature and absent on many endpoints
- Many enterprises do not expose TCP/1801 externally
- Internal segmentation or host firewalls often break direct reachability
175373 and simple port inventories catch the obvious cases.Confirm vulnerable parsing behavior
auxiliary/scanner/msmq/cve_2023_21554_queuejumper, and GitHub PoCs from zoemurmure/CVE-2023-21554-PoC and 3tternp/CVE-2023-21554 demonstrate the packet structure. This turns exposure into a concrete target list fast.- MSMQ responds enough for protocol fingerprinting
- Target is missing the April 2023 security fix or later cumulative update
- Patched systems may simply drop or ignore malformed probes
- Some probes are noisy and can trip IDS/IPS or EDR network telemetry
Send malicious QueueJumper packet
mqsvc.exe service processes it before authentication or user interaction. In the right build state, that gives code execution in the service context.- Attacker can deliver raw MSMQ traffic to the listener
- Target is still vulnerable at the OS build level
- Reliable code execution is harder than a crash on some versions
- IPS signatures, inline firewalls, or protocol-aware inspection may break exploit delivery
mqsvc.exe; scanner coverage is decent, exploit telemetry coverage is moderate.Use the foothold for lateral movement
- Successful RCE on a server with useful trust relationships
- Post-exploitation controls do not immediately contain the host
- Modern EDR should catch suspicious follow-on execution from a service host
- Tiering, PAM, and east-west segmentation limit lateral movement value
mqsvc.exe activity; vulnerability scanners do not cover this stage.The supporting signals.
| In-the-wild status | No confirmed KEV listing and no authoritative public evidence of sustained real-world exploitation found in the sources reviewed; WithSecure said no in-the-wild exploits were recorded *at time of writing*, and Wiz currently shows Has CISA KEV Exploit: No. |
|---|---|
| Proof-of-concept availability | Public PoCs exist: GitHub repos zoemurmure/CVE-2023-21554-PoC and 3tternp/CVE-2023-21554; Rapid7 also publishes auxiliary/scanner/msmq/cve_2023_21554_queuejumper for validation. |
| EPSS | High exploit probability: Tenable shows EPSS 0.92162; Wiz shows EPSS 91.9% at the 99.7th percentile. |
| KEV status | Not KEV-listed in the reviewed sources; Wiz shows Has CISA KEV Exploit: No, with no KEV release or due date. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — this is the classic pre-auth network RCE profile, but it assumes the service is present and reachable. |
| Affected versions | Broad Windows coverage when MSMQ is installed: NVD lists Windows 10 1607/1809/20H2/21H2/22H2, Windows 11 21H2/22H2, and Windows Server 2008 SP2 through 2022. |
| Fixed versions | Patched by Microsoft's April 11, 2023 security updates and later LCUs. Representative fixed builds: 14393.5850+, 17763.4252+, 19042/19044/19045.2846+, 22000.1817+, 22621.1555+, and 20348.1668+. |
| Exposure data | Check Point reported ~360,000 internet-exposed MSMQ hosts on TCP/1801; WithSecure later cited more than 400,000 exposed hosts. GreyNoise saw scanning activity and later added a malicious QueueJumper RCE-attempt tag. |
| Disclosure date | 2023-04-11 via Microsoft's Patch Tuesday release. |
| Reporting researcher / org | Discovered by Wayne Low of Fortinet FortiGuard Labs and Haifei Li of Check Point Research; technical analysis and exploitability research were later expanded by IBM X-Force. |
noisgate verdict.
The decisive downward pressure is that exploitation only exists where the optional MSMQ role is installed *and* reachable on TCP/1801. When those conditions are met the impact is ugly, but those prerequisites materially narrow the exposed population compared with a true edge-everywhere Windows RCE.
Why this verdict
- Downgrade for optional feature: Vendor
9.8assumes a universal service. In reality,MSMQis an optional Windows component, so a large fraction of endpoints simply do not have the vulnerable listener at all. - Downgrade for attacker position: The attacker must reach TCP/1801. That implies either internet exposure or prior internal access, and each network boundary sharply reduces the practical target set.
- Hold it high for blast radius: If MSMQ is present and reachable, this is still unauthenticated remote code execution against Windows server infrastructure, with public PoCs and wormable-style internal spread potential.
- No confirmed KEV / active exploitation: The reviewed sources do not show CISA KEV inclusion or authoritative ongoing exploitation, which removes the strongest reason to keep this at fleet-wide CRITICAL.
- Exposure is uneven, not theoretical: Check Point and WithSecure both reported hundreds of thousands of exposed TCP/1801 listeners, so this is not a lab-only issue; it is just not evenly distributed across all Windows assets.
Why not higher?
Because this is not a universal Windows network stack bug. The exploit path depends on an optional service plus reachable TCP/1801, and in many enterprises that means a niche subset of middleware and server roles rather than the entire estate. The lack of confirmed KEV-listed exploitation is another reason not to keep the vendor's blanket CRITICAL label.
Why not lower?
Because once the prerequisites are met, there is very little attacker friction left: no credentials, no user interaction, and full remote code execution potential. Public PoCs, scanner support, and broad internal reachability in flat networks make this much more dangerous than a routine post-auth or local-only issue.
What to do — in priority order.
- Block TCP/1801 from untrusted networks — Apply host and network ACLs so only explicitly approved peers can reach MSMQ, and do it within 30 days for a HIGH verdict. This is the cleanest compensating control because QueueJumper dies if the attacker cannot route traffic to the listener.
- Remove or disable MSMQ where unused — Audit for the
MSMQfeature and uninstall or disable it on systems that do not have a documented dependency, within 30 days. This reduces both vulnerability exposure and the long-tail risk of forgotten middleware components. - Isolate known MSMQ servers — Put confirmed MSMQ-dependent systems into tightly controlled application segments, allowlisting only required source hosts, within 30 days. This matters because the most realistic abuse case is east-west movement after an attacker already has some foothold.
- Hunt for
mqsvc.exeexposure and abnormal behavior — Add detections for inbound TCP/1801,mqsvc.execrashes, and suspicious child processes or script engines spawned from service-host contexts, within 30 days. Detection will not prevent exploitation, but it improves your odds of catching validation attempts and post-exploitation pivots.
- A WAF does not help; this is not HTTP and does not traverse the web stack.
- MFA does nothing; the attack is pre-auth over a service port.
- Patching Exchange alone is not a fix; Exchange may be one path that enabled MSMQ, but the vulnerable code is in Windows MSMQ itself.
- General email security controls are irrelevant; the exploit path is direct network access to TCP/1801, not user-delivered content.
Crowdsourced verification payload.
Run this on the target Windows host you want to validate, not from an auditor workstation. Invoke it as powershell -ExecutionPolicy Bypass -File .\check-queuejumper.ps1; local admin is recommended for reliable service and OS inspection. The script treats hosts without the MSMQ service as not exposed to this CVE and prints exactly VULNERABLE, PATCHED, or UNKNOWN.
# check-queuejumper.ps1
# Detect likely exposure to CVE-2023-21554 (QueueJumper) on the local Windows host.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
function Get-OsBuildInfo {
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
$build = [int]$cv.CurrentBuildNumber
$ubr = 0
if ($null -ne $cv.UBR) { $ubr = [int]$cv.UBR }
$display = $cv.DisplayVersion
if (-not $display) { $display = $cv.ReleaseId }
[pscustomobject]@{
ProductName = [string]$cv.ProductName
Build = $build
UBR = $ubr
Display = [string]$display
}
}
function Get-MsmqInstalled {
$svc = Get-Service -Name 'MSMQ'
if ($svc) { return $true }
return $false
}
function Compare-Build {
param(
[int]$Build,
[int]$UBR,
[int]$MinBuild,
[int]$MinUBR
)
if ($Build -gt $MinBuild) { return 1 }
if ($Build -lt $MinBuild) { return -1 }
if ($UBR -ge $MinUBR) { return 1 }
return -1
}
$os = Get-OsBuildInfo
$msmqInstalled = Get-MsmqInstalled
# If MSMQ service is absent, the QueueJumper attack path is not present on this host.
if (-not $msmqInstalled) {
Write-Output 'PATCHED'
exit 0
}
# Representative fixed build thresholds from April 2023 advisories / NVD-enriched data.
# Some legacy SKUs are hard to map cleanly from build number alone; those return UNKNOWN.
$result = 'UNKNOWN'
$exitCode = 2
switch ($os.Build) {
14393 {
# Windows 10 1607 / Server 2016 fixed at 14393.5850+
if ((Compare-Build -Build $os.Build -UBR $os.UBR -MinBuild 14393 -MinUBR 5850) -gt 0) { $result='PATCHED'; $exitCode=0 } else { $result='VULNERABLE'; $exitCode=1 }
}
17763 {
# Windows 10 1809 / Server 2019 fixed at 17763.4252+
if ((Compare-Build -Build $os.Build -UBR $os.UBR -MinBuild 17763 -MinUBR 4252) -gt 0) { $result='PATCHED'; $exitCode=0 } else { $result='VULNERABLE'; $exitCode=1 }
}
19042 {
# Windows 10 20H2 fixed at 19042.2846+
if ((Compare-Build -Build $os.Build -UBR $os.UBR -MinBuild 19042 -MinUBR 2846) -gt 0) { $result='PATCHED'; $exitCode=0 } else { $result='VULNERABLE'; $exitCode=1 }
}
19043 {
# Windows 10 21H1/21H2 family; use 19044.2846 threshold conservatively by UBR
if ($os.UBR -ge 2846) { $result='PATCHED'; $exitCode=0 } else { $result='VULNERABLE'; $exitCode=1 }
}
19044 {
# Windows 10 21H2 fixed at 19044.2846+
if ($os.UBR -ge 2846) { $result='PATCHED'; $exitCode=0 } else { $result='VULNERABLE'; $exitCode=1 }
}
19045 {
# Windows 10 22H2 fixed at 19045.2846+
if ($os.UBR -ge 2846) { $result='PATCHED'; $exitCode=0 } else { $result='VULNERABLE'; $exitCode=1 }
}
22000 {
# Windows 11 21H2 fixed at 22000.1817+
if ($os.UBR -ge 1817) { $result='PATCHED'; $exitCode=0 } else { $result='VULNERABLE'; $exitCode=1 }
}
22621 {
# Windows 11 22H2 fixed at 22621.1555+
if ($os.UBR -ge 1555) { $result='PATCHED'; $exitCode=0 } else { $result='VULNERABLE'; $exitCode=1 }
}
22631 {
# Newer enablement-package branch; later than fixed 22621 baseline
$result='PATCHED'; $exitCode=0
}
20348 {
# Windows Server 2022 fixed at 20348.1668+
if ($os.UBR -ge 1668) { $result='PATCHED'; $exitCode=0 } else { $result='VULNERABLE'; $exitCode=1 }
}
default {
# Legacy systems like 2008/2012/2012 R2 or uncommon builds need authoritative KB validation.
$result='UNKNOWN'
$exitCode=2
}
}
Write-Output $result
exit $exitCode
If you remember one thing.
MSMQ plus reachable TCP/1801. For a HIGH verdict, the noisgate mitigation SLA is within 30 days: identify every host with the MSMQ service, block untrusted access to TCP/1801, and remove the feature anywhere it is not explicitly required. Then finish the actual Windows patching under the noisgate remediation SLA of within 180 days, with internet-exposed and high-trust middleware servers going first.Sources
- Microsoft Security Update Guide - CVE-2023-21554
- NVD - CVE-2023-21554
- Check Point Research - QueueJumper
- GreyNoise - QueueJumper scanning and RCE attempt tags
- Rapid7 module - CVE-2023-21554 QueueJumper MSMQ RCE Check
- Tenable plugin 175373
- Wiz vulnerability entry - CVE-2023-21554
- WithSecure Threat Highlight Report April 2023
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.