Public PoC Released for Windows Kernel Flaw That Grants SYSTEM Access

Public proof-of-concept exploit code is now available for CVE-2026-42980, a high-severity Windows NT OS Kernel vulnerability. A low-privileged local attacker could exploit the flaw to elevate privileges and obtain NT AUTHORITY\SYSTEM access.

The vulnerability results from an integer underflow that can lead to a heap-based buffer overflow in a Windows kernel component. Microsoft assigned it a CVSS 3.1 score of 7.8 and patched affected Windows clients and servers in June 2026.

The exploit requires an attacker to authenticate locally or already execute code under a low-privileged account. It does not provide an unauthenticated remote entry point, but it can help an attacker expand control after an initial compromise.

What is CVE-2026-42980?

Category	Details
Vulnerability	Windows NT OS Kernel elevation of privilege
CVE	CVE-2026-42980
Severity	High
CVSS score	7.8
Weaknesses	Integer underflow and heap-based buffer overflow
Attack vector	Local
Required privileges	Low
User interaction	None
Potential result	Privilege escalation to NT AUTHORITY\SYSTEM
Patch released	June 9, 2026

The official CVE-2026-42980 entry classifies the problem under CWE-191, integer underflow, and CWE-122, heap-based buffer overflow. Both weaknesses can contribute to unsafe memory handling inside privileged kernel code.

Microsoft’s CVSS vector records low attack complexity, low required privileges, and no user interaction. A successful attack could have a high effect on the confidentiality, integrity, and availability of the affected computer.

How the Windows kernel flaw works

An integer underflow occurs when an arithmetic operation produces a value below the range that the program expects. The result can wrap into a much larger positive value and cause later size calculations to become incorrect.

In this case, the incorrect calculation can lead to unsafe heap memory handling within the Windows kernel. The public research associates the vulnerable path with Windows Management Instrumentation, commonly known as WMI.

An attacker who controls the relevant inputs can trigger the faulty calculation and corrupt kernel memory. Reliable exploitation can then redirect execution or manipulate kernel state to gain privileges beyond those assigned to the original account.

1. The attacker first gains access to a low-privileged Windows account.
2. The attacker runs code that reaches the vulnerable kernel path.
3. A crafted input triggers the integer underflow.
4. The incorrect calculation causes unsafe heap memory behavior.
5. The exploit manipulates the resulting kernel state.
6. The attacker obtains NT AUTHORITY\SYSTEM privileges.

Public exploit code is available on GitHub

A security researcher using the name G4sp4rCS published a GitHub repository for CVE-2026-42980. The repository describes the project as a public exploit and research disclosure for vulnerable Windows laboratory systems.

The project includes C source code, helper files, build scripts, technical explanations in English and Spanish, and an image showing a SYSTEM-level command prompt. The repository specifically identifies the targeted area as a Windows kernel WMI path.

The researcher labels the code for educational, defensive, and authorized security testing. Administrators should not run untrusted exploit code on production systems or ordinary workstations, even when a repository includes a safety notice.

Repository component	Purpose
C source files	Implement the proof-of-concept privilege-escalation technique
WMI helper definitions	Interact with the targeted Windows component
Build scripts	Compile the research project with Windows development tools
Technical write-ups	Explain the vulnerability and research process
Demonstration image	Shows SYSTEM privileges on a vulnerable laboratory build

A PoC release does not confirm active attacks

Public exploit code can help defenders reproduce a vulnerability and confirm that patches work. It can also lower the effort required for malicious actors to study and adapt the technique.

However, publishing a PoC does not establish that attackers have used it against real organizations. Neither Microsoft’s public information nor the available vulnerability records confirm in-the-wild exploitation of CVE-2026-42980.

The research repository demonstrates exploitation on vulnerable laboratory builds. Its results should not be interpreted as evidence that every affected Windows release can be compromised with identical reliability.

Why local privilege escalation remains dangerous

A local vulnerability cannot provide the attacker’s initial connection by itself. Someone must first gain a user account, physical access, or another method of running code on the target machine.

Attackers frequently combine local privilege-escalation flaws with phishing, stolen credentials, malicious documents, browser vulnerabilities, exposed remote services, or existing malware. The first technique provides access, while the kernel flaw removes local privilege restrictions.

SYSTEM access gives an attacker extensive control over Windows. Depending on other protections, the attacker could access protected data, change security settings, create privileged accounts, install services, or interfere with endpoint defenses.

• Access files unavailable to the original user
• Install software with system privileges
• Create or modify privileged accounts
• Change services and system configuration
• Read credentials available to privileged processes
• Establish persistence on the affected computer
• Use the compromised host to support further network attacks

Which Windows versions are affected?

CVE-2026-42980 affects multiple supported and extended-support Windows releases. The list includes Windows 10, Windows 11, and Windows Server editions from Windows Server 2012 through Windows Server 2025.

Microsoft records specific fixed build thresholds for each release. Systems below the listed build remain vulnerable unless Microsoft or an enterprise servicing channel has supplied an equivalent correction.

Windows release	Fixed build or later
Windows 10 Version 1607	10.0.14393.9234
Windows 10 Version 1809	10.0.17763.8880
Windows 10 Version 21H2	10.0.19044.7417
Windows 10 Version 22H2	10.0.19045.7417
Windows 11 Version 23H2	10.0.22631.7219
Windows 11 Version 24H2	10.0.26100.8655
Windows 11 Version 25H2	10.0.26200.8655
Windows 11 Version 26H1	10.0.28000.2269
Windows Server 2012	6.2.9200.26132
Windows Server 2012 R2	6.3.9600.23228
Windows Server 2016	10.0.14393.9234
Windows Server 2019	10.0.17763.8880
Windows Server 2022	10.0.20348.5256
Windows Server 2025	10.0.26100.32995

Some affected releases require Extended Security Updates or another eligible servicing arrangement. Administrators should use Microsoft’s product-specific guidance instead of assuming that every older Windows installation automatically receives the patch.

Microsoft patched the flaw in June 2026

Microsoft fixed CVE-2026-42980 through the cumulative security updates released on June 9, 2026. Since Windows cumulative updates include earlier fixes, installing a later supported cumulative update should also address the vulnerability.

The Microsoft Security Response Center advisory provides the authoritative product and update mapping. Organizations should verify both successful installation and the active Windows build.

Microsoft does not provide a configuration workaround that fully removes the underlying kernel flaw. Installing the appropriate security update remains the primary remediation.

1. Open Settings and select Windows Update.
2. Check for available security and cumulative updates.
3. Install the update offered for the Windows release.
4. Restart the computer when Windows requests it.
5. Run winver to check the active build.
6. Compare the build with Microsoft’s fixed version for that release.

How organizations should prioritize patching

Security teams should prioritize systems where many users can sign in or execute applications. Examples include Remote Desktop Session Hosts, shared workstations, virtual desktop systems, build servers, and administrative jump boxes.

Internet-facing servers also deserve attention even though the flaw itself is local. An attacker who compromises a vulnerable service could use CVE-2026-42980 to move from the service account to SYSTEM.

The 7.8 CVSS assessment reflects the need for local access, but it also records complete confidentiality, integrity, and availability impact after successful exploitation.

• Confirm that June 2026 or later cumulative updates are installed.
• Prioritize shared systems and servers with multiple local users.
• Restrict interactive and remote logon rights.
• Use application control to block unauthorized executables.
• Prevent users from disabling endpoint security products.
• Monitor unusual process and privilege changes.
• Apply least-privilege policies to service and user accounts.

What defenders should monitor

A successful privilege-escalation attempt may appear after another intrusion event. Defenders should correlate new SYSTEM processes with suspicious downloads, script execution, unusual user logons, and endpoint-security alerts.

Application allow-listing can make it harder to run copied or recompiled exploit binaries. However, allow-listing does not repair the vulnerability and should support patching rather than replace it.

Organizations that find unexplained SYSTEM-level execution should investigate the full attack chain. They should determine how the attacker gained initial access, which credentials were exposed, and whether persistence remains on the host.

Public PoC code should remain in isolated labs

Security teams may use a proof of concept to validate vulnerability scanners, test endpoint detections, and confirm patch effectiveness. Any such testing should occur only on isolated systems owned by the organization or explicitly authorized for security research.

Running public exploit code creates additional risk because repositories can change, contain errors, or include unexpected behavior. Teams should review source code and monitor the test system before executing any security research tool.

The official Microsoft CVE guidance and installed build information provide safer ways to determine patch status on production endpoints. Exploit testing should not form the primary method for identifying vulnerable business systems.

FAQ