← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-40369 · CWE-822 · Disclosed 2026-05-12

Untrusted pointer dereference in Windows Kernel

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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

"Not a perimeter fire, but a very usable post-compromise escalator on widely deployed Windows builds."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land low-privilege code execution

The attacker first needs code execution on the target as a normal user or inside a constrained sandbox. In practice this comes from malware, a phishing-delivered payload, a browser renderer compromise, or a valid but unprivileged local session. CVSS captures this as AV:L/PR:L, and that prerequisite is the biggest downward pressure on severity.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Exposure scanners can identify vulnerable OS builds well; attack-path detection is weaker because the prerequisite is generic user-mode execution rather than a network signature.
STEP 02

Trigger the kernel primitive with public tooling

Public exploit material tied to Ori Nimron's GitHub repo describes abusing 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.
Conditions required:
  • Attacker can call native Windows syscalls from the compromised process
  • Target remains unpatched
Where this breaks in practice:
  • 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
Detection/coverage: There is public PoC coverage in threat feeds; host telemetry is the realistic detection layer. Check Point also published IPS coverage, but for a local kernel bug host controls matter more than gateway controls.
STEP 03

Turn the primitive into token or memory abuse

Once the primitive is established, the attacker can target kernel memory structures to obtain stronger read/write capability or directly tamper with security-relevant state such as process privileges and tokens. This is the point where a browser sandbox escape or low-privilege malware execution becomes a full host compromise event.
Conditions required:
  • Reliable primitive on the exact target build
  • Knowledge of kernel object layout or a KASLR bypass strategy
Where this breaks in practice:
  • 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
Detection/coverage: Traditional network IDS has little to work with here. EDR, Sysmon, and kernel telemetry are the practical controls.
STEP 04

Reach SYSTEM and disable trust boundaries

Successful exploitation gives the attacker SYSTEM-level control on the endpoint or server. At that point they can dump credentials, disable defenses, persist as a service or driver, and pivot deeper into the estate using the host as a trusted launch point.
Conditions required:
  • Exploit succeeds without crashing the host
  • No effective EDR containment before post-exploitation
Where this breaks in practice:
  • 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
Detection/coverage: High-quality EDR should catch a lot of the post-exploitation behavior even if it misses the exact kernel transition.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 / PoCYes. Multiple feeds reference a public GitHub exploit by Ori Nimron: orinimron123/CVE-2026-40369-EXPLOIT.
EPSSUser-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 statusNot listed in CISA's Known Exploited Vulnerabilities Catalog as of this assessment.
CVSS vector meaningCVSS: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 versionsWindows 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 versionsPatch 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 realityThis 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 datePublished by Microsoft and NVD on 2026-05-12.
Research / reportingMicrosoft is the CNA for the CVE record. Public exploit reporting and technical discussion are widely attributed to Ori Nimron after disclosure.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.1/10)

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.

HIGH Affected version mapping and fixed build thresholds
MEDIUM Operational exploitability across heterogeneous enterprise builds
MEDIUM Absence of active exploitation at time of assessment

Why this verdict

  • Downward pressure: requires prior compromiseAV:L/PR:L means 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a HIGH post-compromise escalator across your Windows 11 and Server 2025 fleet: identify affected builds, patch the internet-facing admin workstations, developer endpoints, jump boxes, and browser-heavy user populations first, and put compensating controls on any delayed rings. Per the noisgate mitigation SLA, get the temporary risk reduction in place within 30 days; per the noisgate remediation SLA, finish the actual Microsoft patch rollout within 180 days.

Sources

  1. Microsoft Security Update Guide advisory
  2. NVD CVE record
  3. OpenCVE record with affected version ranges
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS project
  6. FIRST EPSS API documentation
  7. Check Point advisory / protection coverage
  8. BleepingComputer May 2026 Patch Tuesday coverage
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.