This is the attacker finding the freight elevator after they already got into the lobby
CVE-2026-40369 is a Windows Kernel elevation-of-privilege bug caused by an untrusted pointer dereference (CWE-822). Microsoft and the CVE record describe it as a local flaw: an attacker with code execution as a low-privilege user can abuse kernel handling to reach SYSTEM-level control. The affected ranges published in the CVE record are Windows 11 24H2 before 10.0.26100.8457, Windows 11 25H2 before 10.0.26200.8457, Windows 11 26H1 before 10.0.28000.2113, and Windows Server 2025 before 10.0.26100.32860.
paragraphs
4 steps from start to impact.
Land low-privilege code execution
AV:L/PR:L, and that prerequisite is the biggest downward pressure on severity.- Code execution on the target host as a standard user, service account, or sandboxed process
- Affected Windows 11 24H2/25H2/26H1 or Windows Server 2025 build
- Requires a prior foothold; this is not an initial-access bug
- MFA, email filtering, browser hardening, and EDR may stop the first-stage payload before this CVE is ever reached
Trigger the kernel primitive with public tooling
NtQuerySystemInformation with class 253 to reach the vulnerable path in ntoskrnl.exe/ExpGetProcessInformation. The value here is not theoretical memory corruption; it is a low-complexity, repeatable kernel primitive that turns a user-land foothold into a kernel write/increment capability.- Attacker can call native Windows syscalls from the compromised process
- Target remains unpatched
- Kernel exploits are build-sensitive and can break across patch levels
- Application control or exploit prevention may block known PoC binaries or suspicious memory-manipulation behavior
Turn the primitive into token or memory abuse
- Reliable primitive on the exact target build
- Knowledge of kernel object layout or a KASLR bypass strategy
- Exploit reliability can drop on hardened fleets or slightly different builds
- EDR telemetry on token theft, process tampering, or suspicious child-process chains may expose the follow-on activity
Reach SYSTEM and disable trust boundaries
- Exploit succeeds without crashing the host
- No effective EDR containment before post-exploitation
- SYSTEM on one host is still one-host blast radius unless the actor can pivot
- Credential Guard, LSASS protection, network segmentation, and tiering can limit what the attacker does next
The supporting signals.
| In-the-wild status | No confirmed active exploitation in the sources reviewed. CISA ADP metadata shows Exploitation: none, and the CVE is not KEV-listed at assessment time. |
|---|---|
| Public exploit / PoC | Yes. Multiple feeds reference a public GitHub exploit by Ori Nimron: orinimron123/CVE-2026-40369-EXPLOIT. |
| EPSS | User-supplied EPSS is 0.00014 (~0.014% probability over 30 days), which is very low. Percentile was not verified from a primary EPSS response during this assessment. |
| KEV status | Not listed in CISA's Known Exploited Vulnerabilities Catalog as of this assessment. |
| CVSS vector meaning | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H means local, low-complexity, low-privilege, no-click exploitation with full host impact if the attacker is already on the box. |
| Affected versions | Windows 11 24H2 <10.0.26100.8457; Windows 11 25H2 <10.0.26200.8457; Windows 11 26H1 <10.0.28000.2113; Windows Server 2025 <10.0.26100.32860. |
| Fixed versions | Patch to at least Windows 11 24H2 10.0.26100.8457, Windows 11 25H2 10.0.26200.8457, Windows 11 26H1 10.0.28000.2113, and Windows Server 2025 10.0.26100.32860. |
| Exposure reality | This is not an internet-scannable service flaw. Shodan/Censys/FOFA-style counts are not the right lens; exposure is the size of your Windows endpoint/server population plus how often low-privilege code execution occurs there. |
| Disclosure date | Published by Microsoft and NVD on 2026-05-12. |
| Research / reporting | Microsoft is the CNA for the CVE record. Public exploit reporting and technical discussion are widely attributed to Ori Nimron after disclosure. |
noisgate verdict.
The decisive friction is that this bug requires a pre-existing local foothold; it is not an entry vector and it is not directly internet-reachable. It stays in HIGH anyway because the affected population is broad across modern Windows builds and there is public exploit material that makes the post-compromise jump to SYSTEM much more operationally useful.
Why this verdict
- Downward pressure: requires prior compromise —
AV:L/PR:Lmeans the attacker already has code running locally or has valid low-privilege access. That implies post-initial-access, which materially narrows reachable population compared with network bugs. - Upward pressure: broad Windows footprint — this hits mainstream Windows 11 branches and Windows Server 2025, so once you own a foothold, there is a large real-world host population where the exploit target exists.
- Upward pressure: public exploit chain exists — public PoC/exploit references reduce attacker development cost and make this much more than a theoretical kernel bug, especially for actors chaining browser or userland execution into SYSTEM.
Why not higher?
It is not unauthenticated remote code execution, not a wormable service, and not a pre-auth edge-device issue. There is also no verified KEV entry or active exploitation evidence in the reviewed sources, so calling it CRITICAL would overstate the immediacy.
Why not lower?
This is still a kernel-to-SYSTEM escalation on very common Windows builds, and public exploit availability matters. In a 10,000-host estate, any malware, browser compromise, or misused user context becomes much more dangerous if SYSTEM is one syscall path away.
What to do — in priority order.
- Tighten application control on user space — Use WDAC/AppLocker/allow-listing to cut down the number of low-privilege processes that can execute arbitrary code in the first place. For a HIGH verdict, deploy or tighten this within 30 days where you cannot patch immediately, because the prerequisite foothold is the cleanest choke point.
- Harden browsers and isolate high-risk users — Because public reporting ties this bug to browser-sandbox-escape value, prioritize browser exploit prevention, extension control, and isolation for admins, developers, and internet-facing staff. Treat this as a compensating control to deploy within 30 days on unpatched populations.
- Enforce least privilege and remove standing local admin — This does not stop the bug outright, but it reduces the number of initial contexts an attacker can weaponize and limits post-SYSTEM blast radius by keeping privilege boundaries tighter across the fleet. Apply within 30 days for systems that will remain on vulnerable builds during patch waves.
- Tune EDR for token abuse and defense tampering — You are unlikely to get perfect detection on the exact kernel transition, so focus on catching the aftermath: token manipulation, suspicious service creation, LSASS access, security product tampering, and unusual child-process chains. Put the tuning in place within 30 days while remediation proceeds.
- Perimeter firewalls do not materially help; this is a local kernel bug, not a network listener flaw.
- MFA does not block exploitation once code is already executing locally under a user context.
- Gateway IPS alone is not enough; even when a network security vendor publishes a signature, the exploit path is fundamentally host-side.
Crowdsourced verification payload.
Run this on the target Windows host or through your EDR/management shell. Example: powershell.exe -ExecutionPolicy Bypass -File .\check-CVE-2026-40369.ps1 from an elevated shell is preferred, but standard-user rights are usually enough because the script only reads OS version metadata from the registry and CIM.
# check-CVE-2026-40369.ps1
# Determines likely exposure to CVE-2026-40369 based on Windows build/version.
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=ERROR
$ErrorActionPreference = 'Stop'
function Get-OsInfo {
$cvPath = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
$cv = Get-ItemProperty -Path $cvPath
$productName = [string]$cv.ProductName
$displayVersion = [string]$cv.DisplayVersion
$currentBuild = [int]$cv.CurrentBuildNumber
$ubr = [int]$cv.UBR
$buildLabEx = [string]$cv.BuildLabEx
$cs = Get-CimInstance Win32_ComputerSystem
$os = Get-CimInstance Win32_OperatingSystem
return [pscustomobject]@{
ProductName = $productName
DisplayVersion = $displayVersion
CurrentBuild = $currentBuild
UBR = $ubr
BuildLabEx = $buildLabEx
DomainRole = $cs.DomainRole
Caption = [string]$os.Caption
Version = [string]$os.Version
}
}
function Test-Vulnerable {
param(
[Parameter(Mandatory=$true)]$Info
)
$pn = $Info.ProductName.ToLowerInvariant()
$dv = $Info.DisplayVersion.ToLowerInvariant()
$build = [int]$Info.CurrentBuild
$ubr = [int]$Info.UBR
# Windows Server 2025 / Server Core: vulnerable if build 26100 and UBR < 32860
if ($pn -like '*server 2025*' -or $Info.Caption.ToLowerInvariant() -like '*server 2025*') {
if ($build -eq 26100) {
return ($ubr -lt 32860)
}
return $false
}
# Windows 11 24H2: build 26100, UBR < 8457
if (($pn -like '*windows 11*') -and ($dv -eq '24h2' -or $build -eq 26100)) {
if ($build -eq 26100) {
return ($ubr -lt 8457)
}
return $false
}
# Windows 11 25H2: build 26200, UBR < 8457
if (($pn -like '*windows 11*') -and ($dv -eq '25h2' -or $build -eq 26200)) {
if ($build -eq 26200) {
return ($ubr -lt 8457)
}
return $false
}
# Windows 11 26H1: build 28000, UBR < 2113
if (($pn -like '*windows 11*') -and ($dv -eq '26h1' -or $build -eq 28000)) {
if ($build -eq 28000) {
return ($ubr -lt 2113)
}
return $false
}
throw 'Platform/version not in the published affected list.'
}
try {
$info = Get-OsInfo
$isVuln = Test-Vulnerable -Info $info
if ($isVuln) {
Write-Output 'VULNERABLE'
exit 1
} else {
Write-Output 'PATCHED'
exit 0
}
}
catch {
Write-Output 'UNKNOWN'
exit 2
}
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.