Microsoft's attempt to seal a kernel security hole has backfired. A patch originally shipped in October 2024 to fix CVE-2024-43511 inadvertently created a new vulnerability—tracked as CVE-2025-53136—that reliably exposes kernel memory addresses on fully updated Windows 11 24H2 and Windows Server 2022 24H2 systems. The flaw grants even low‑privilege, sandboxed attackers a simple way to read kernel pointers, completely undermining Kernel Address Space Layout Randomization (KASLR) and enabling local privilege escalation (LPE) when chained with other bugs.

Security researcher reports and public proof‑of‑concept demonstrations confirm that CVE-2025-53136 is not a theoretical weakness. “This vulnerability can be easily chained with other vulnerabilities to obtain a complete exploit on the latest version of the system,” noted researchers from Crowdfense, who performed early analysis. The bug turns what should have been a routine hardening exercise into a textbook case of how a security fix can introduce a fresh, exploitable entry point.

How the October 2024 patch planted the seeds

To understand CVE-2025-53136, start with CVE-2024-43511, a separate kernel issue Microsoft addressed in October 2024. As part of that remedial work, the kernel function RtlSidHashInitialize() received modified parameters. Previously, the function operated on internal kernel structures safely isolated from user memory. After the change, it began receiving a pointer to the TOKEN.UserAndGroups field—a kernel‑space address—as its first argument, while the third argument pointed to a user‑supplied buffer.

During initialization, the patched code momentarily writes that sensitive kernel pointer into the user buffer. It then overwrites the value with a benign placeholder, but the microsecond‑wide gap is enough. An attacker that can race against the overwrite can capture the raw kernel address straight from user land. The root cause is a classic time‑of‑check‑time‑of‑use (TOCTOU) condition introduced by the very patch meant to harden token handling.

The trigger: racing NtQueryInformationToken

Exploiting CVE-2025-53136 requires two concurrent threads operating from a process running at any integrity level—even Low IL or inside an AppContainer sandbox. One thread repeatedly calls the NtQueryInformationToken() system call with the TokenAccessInformation information class. This invokes the modified RtlSidHashInitialize path, triggering the brief pointer disclosure. A second thread simultaneously reads from the user buffer at the exact offset where the kernel pointer is exposed. By spinning rapidly, it almost always wins the race, capturing a non‑zero kernel address before it is sanitized.

Proof‑of‑concept code circulating in security communities shows that the technique is highly reliable. Researchers report success rates near 100 % in controlled tests, and the window is wide enough that even modest thread scheduling delays do not prevent the leak. Because both threads reside in user mode, the attack can be launched by any unprivileged application—malware, a sandboxed browser process, or a compromised document macro.

Why a leaked kernel address breaks the bank

KASLR randomly arranges the kernel’s code and data sections each boot, making it harder for attackers to predict where critical structures live. A single leaked kernel pointer instantly de‑randomizes that layout for the attacker’s process. Armed with the address of TOKEN.UserAndGroups, an adversary can compute offsets to virtually any kernel symbol or structure. This turns a local information disclosure—often rated as medium severity—into a powerful primitive that enables full system compromise when paired with a write‑what‑where bug or a use‑after‑free in a driver.

Chain attacks are well documented. Once the address is known, a subsequent kernel write vulnerability can overwrite the Privileges field of the current process token, granting SYSTEM rights. From there, the attacker can disable security software, persist, move laterally, or steal credentials. CVE-2025-53136 thus acts as a reliable decryption key for kernel memory, slashing the effort needed to escalate from limited user to domain administrator.

Affected systems and patch status

Microsoft’s security advisory, along with third‑party vulnerability databases, confirms that only Windows 11 24H2 and Windows Server 2022 24H2 builds are impacted. Earlier Windows versions and older server releases are not vulnerable because they do not contain the flawed RtlSidHashInitialize patch.

Reports on patch availability have evolved. Early coverage indicated that Microsoft had not yet released a fix, but public datasets now list cumulative updates that address CVE-2025-53136. IT teams should consult the Microsoft Security Update Guide for the exact Knowledge Base (KB) article numbers and deploy the appropriate patches immediately. The updates are delivered through Windows Update, WSUS, and the Microsoft Update Catalog. Organizations must verify installation across their fleets, paying special attention to endpoints that run multi‑tenant workloads, accept user logins, or host sandboxed applications.

Immediate mitigation before you can patch

While patch deployment remains the primary fix, compensating controls can substantially reduce risk in the interim:

  • Enforce least privilege: Strip SeDebugPrivilege and SeImpersonatePrivilege from all non‑administrative accounts. Limit local admin memberships to essential personnel.
  • Restrict code execution: Use Windows Defender Application Control (WDAC) or AppLocker to block untrusted binaries. A well‑crafted policy prevents unknown malware and sandboxed exploits from running the exploit code.
  • Harden sandbox configurations: For AppContainer and Low IL processes, reduce the number of allowed capabilities and disallow access to token‑querying APIs where possible.
  • Isolate critical servers: Segment Windows Server 2022 24H2 systems behind privileged access workstations (PAWs) and limit inbound connections from user endpoints.

These measures do not close the leak, but they raise the bar significantly, making it harder for an attacker to leverage the vulnerability in a real‑world chain.

Detecting exploitation and post‑exploit behavior

Security operations centers (SOCs) can tune their telemetry to spot the distinctive patterns that accompany CVE-2025-53136 abuse:

  • Anomalous token queries: Watch for processes making abnormally high numbers of NtQueryInformationToken calls with the TokenAccessInformation class.
  • Rapid user‑buffer reads: Sandboxed or low‑privilege processes that spin in tight loops reading from their own memory at offsets corresponding to token structures merit investigation.
  • Sudden privilege escalations: Any process that unexpectedly gains SeDebugPrivilege or transitions to SYSTEM integrity level should trigger an immediate alert.
  • Irregular token modifications: EDR solutions should monitor for integrity level changes and token structure alterations that deviate from normal patterns.

Many endpoint detection and response (EDR) vendors are releasing updated signatures. Ingest these updates and create custom correlation rules that combine multiple indicators—for instance, a low‑IL process repeatedly querying tokens followed by a privilege escalation event.

A catalyst for better patch engineering

CVE-2025-53136 is more than a one‑off mistake. It exposes a systemic tension between performance optimization and security correctness in kernel code. The RtlSidHashInitialize change was likely a well‑intentioned micro‑optimization, but it lacked sufficient concurrent‑use testing. When a kernel function writes privileged data into a user‑accessible buffer even for an instant, modern multi‑threaded environments will almost certainly find a way to sniff it.

Software vendors should treat security fixes with the same rigorous threat modeling and fuzzing applied to new code. Specifically, any kernel patch that touches user‑buffer interactions must be tested under heavy race‑condition stress, with automated concurrency test suites designed to catch TOCTOU windows. Independent researchers who reported CVE-2025-53136 followed a responsible disclosure process that began in early April 2025; Microsoft’s subsequent assignment of the CVE and release of a fix highlight the value of coordinated vulnerability disclosure, but the bug’s existence underscores the need for more proactive internal testing.

What this means for enterprise defenders

For IT security teams, CVE-2025-53136 demands swift, decisive action. The vulnerability does not require administrative privileges to exercise, and it neutralizes one of the core defenses that make modern Windows kernels resilient. Even if no in‑the‑wild attacks had been confirmed at the time of initial disclosure, the publication of reliable PoC code makes active exploitation inevitable. History shows that when primitives this useful become public, targeted attacks follow within weeks.

Organizations should prioritize the following:

  1. Patch all 24H2 systems with the latest cumulative updates, verifying KB applicability via the Microsoft Security Update Guide.
  2. Harden the local attack surface using WDAC/AppLocker, least privilege, and restricted sandbox capabilities.
  3. Update detection pipelines with EDR signatures and custom SIEM rules to flag token‑race behaviors.
  4. Conduct regression tests on upcoming patches to ensure no new user‑buffer exposure is introduced.
  5. Prepare incident response playbooks that include memory forensics and rapid isolation procedures for affected hosts.

CVE-2025-53136 will likely be a favored pivot in future red‑team exercises and real‑world intrusions. By patching quickly and layering detections, defenders can blunt the impact and make their environments a harder target.

Conclusion

Microsoft’s attempt to close one kernel door inadvertently left another wide open. CVE-2025-53136 is a stark reminder that even minor code changes in security‑critical components can produce outsized consequences. The leaked kernel address breaks KASLR, simplifies exploit chains, and forces a sprint toward patch deployment. Organizations that combine rapid patching with proactive monitoring and sane security baselines will weather this threat better than those that wait. The lesson is clear: treat every patch as a potential source of new attack surface, and test accordingly.