SEKurity GmbH Logo
CVE Research

InSEKurity of the Week (CW17/2026): Windows TCP/IP IPv6 + IPsec RCE (CVE-2026-33827)

Critical pre-auth race condition in the Windows TCP/IP stack lets remote attackers run code over IPv6 against any IPsec-enabled host -- wormable, no credentials, no user interaction

SEKurity Team

Offensive Security Experts

18 min read
Share:

This week in our InSEKurity of the Week series: a critical race-condition flaw in the Windows TCP/IP stack that lets unauthenticated remote attackers execute code on any Windows or Windows Server host where IPv6 and IPsec are enabled. By winning a race in the kernel-mode TCP/IP driver with crafted IPv6 packets, an attacker reaches kernel-context code execution before any authentication ever happens. Microsoft and the Zero Day Initiative have flagged the bug as wormable on IPv6 + IPsec deployments, and the patch landed in the April 14, 2026 Patch Tuesday rollup — one of the largest in Microsoft’s history at 165+ CVEs. If you operate domain-isolated networks, IPsec-protected Windows fleets, or cloud Windows VMs reachable on IPv6, this one needs to be at the top of your patch queue.

🚨 Summary

  • CVE ID: CVE-2026-33827
  • CVSS 3.1 Score: 8.1 (High)
  • CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
  • CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization — “Race Condition”)
  • Affected Software: Windows TCP/IP driver (tcpip.sys) on Windows 10 (1607, 1809, 21H2, 22H2), Windows 11 (22H2, 23H2, 24H2, 25H2, 26H1), and Windows Server 2012 / 2012 R2 / 2016 / 2019 / 2022 / 2025 / 23H2 — including Server Core
  • Attack Vector: Network (remote, unauthenticated) — IPv6 packets toward an IPsec-enabled endpoint
  • Authentication Required: None
  • User Interaction: None
  • Impact: Remote code execution in the Windows TCP/IP stack (kernel context); wormable on IPv6 + IPsec hosts
  • Patch Status: ✅ Available (Microsoft, April 14, 2026 Patch Tuesday)
  • Published: April 14, 2026 (NVD)
  • Exploitation Status: No public PoC at time of writing; ZDI rates race-condition exploitability as proven (Pwn2Own precedent); high risk of weaponization
  • CISA KEV: Not listed (as of publication, 2026-04-28)

🖥️ What is the Windows TCP/IP Stack?

The Windows TCP/IP stack is implemented primarily in tcpip.sys, a kernel-mode driver that owns IPv4, IPv6, ICMP, TCP, UDP, and the integration points with IPsec, the Windows Filtering Platform (WFP), and the Network Driver Interface Specification (NDIS). Because it lives in the kernel, any code-execution flaw in tcpip.sys translates directly into ring-0 control: no syscall boundary, no user-mode sandbox, no per-process token to negotiate.

IPv6 has been enabled by default on every Windows SKU since Windows Vista, and Microsoft explicitly recommends against disabling it. IPsec in turn is the foundation of several common Windows security configurations — domain isolation, server isolation, the “boundary” and “encryption” connection-security rules in Windows Defender Firewall, and most VPN tunnel modes. When both are enabled, the affected code path in the IPv6 / IPsec processing logic in tcpip.sys becomes reachable from any host that can send packets to the target.

Typical Use Cases

  • Domain isolation and server isolation zones using Windows Defender Firewall connection-security rules with IPsec (AuthIP / IKEv2).
  • IPsec-protected Always On VPN clients and RRAS gateways that terminate IPsec tunnels.
  • Site-to-site IPsec tunnels between Windows-based gateways and branch / cloud peers.
  • Cloud Windows VMs in Azure, AWS, or GCP with IPv6 enabled and IPsec applied via Group Policy or Defender Firewall.
  • Enterprise networks with native IPv6 rollout where IPsec is used for compliance with secure-by-default architectures.
  • Hybrid Active Directory environments that enforce IPsec authentication for inter-server communication.

Because tcpip.sys is loaded on every Windows host and IPv6 is on by default, the attack surface scales with how many machines additionally enable IPsec. In domain-isolated estates, that can mean every Windows host in the environment.

🔍 Technical Analysis

Vulnerability Description

CVE-2026-33827 is a race condition (CWE-362) in the IPv6 and IPsec processing path of the Windows TCP/IP stack. According to Microsoft, an unauthenticated attacker can send specially crafted IPv6 packets to a Windows host with IPsec enabled and exploit a window of unsynchronized access to a shared resource in tcpip.sys. Winning the race corrupts kernel state in a way that can be groomed into arbitrary code execution.

The race sits before any authentication or IPsec security-association establishment with the attacker — the vulnerable code path executes during early packet ingestion, while the stack is still classifying and dispatching the IPv6 datagram. Authentication is therefore not a prerequisite for the attacker; it only needs to be enabled on the victim (because it is the IPsec inspection path that contains the racy code).

Root Cause Analysis

  1. Concurrent access to a shared structure in the IPv6 / IPsec ingestion path in tcpip.sys: multiple kernel threads can touch the same datagram metadata under high-throughput or high-concurrency conditions.
  2. Improper synchronization (CWE-362): a lock or interlocked sequence is missing or applied too narrowly, leaving a small but reachable TOCTOU window between validation and use of the structure.
  3. Crafted IPv6 packets can deterministically trigger the parallel paths — typically by combining fragmented or extension-header-laden IPv6 datagrams with the IPsec inspection logic.
  4. Heap / pool corruption primitive: winning the race lets the attacker free, reuse, or overwrite a kernel structure while another thread still holds a reference. Modern Windows kernel heaps make this exploitable for controlled writes.
  5. Reachable pre-authentication: the IPsec layer must be enabled on the host, but the attacker does not need to be an authenticated IPsec peer — the race is in code that runs before authentication completes.
  6. Same code on every supported Windows SKU: client and server share tcpip.sys, so domain controllers, member servers, workstations, and cloud VMs are all in scope.

Attack Vector

A typical exploitation flow looks like this:

# Step 1: Discover Windows hosts reachable on IPv6 (link-local or
# globally routed) that respond to ICMPv6 echo. Replace fe80::/10 with
# the target subnet, and use the correct egress interface.
nmap -6 -sn -PE -e eth0 fe80::/10 -oG ipv6-hosts.gnmap

# Step 2: Probe whether IPsec is enabled on the target by looking at
# IKEv2 / AuthIP responders on UDP/500 and UDP/4500. A responsive IKE
# stack is a strong indicator that IPsec is configured on the host.
nmap -6 -sU -p 500,4500 --open <target_ipv6>

# Step 3: Trigger the race condition by sending crafted IPv6 datagrams
# at high concurrency. This is illustrative pseudo-code -- a real PoC
# requires precise timing and heap-grooming primitives.
python3 - <<'PY'
from scapy.all import IPv6, IPv6ExtHdrFragment, IPv6ExtHdrHopByHop, send
import threading

target = "2001:db8::10"

def storm():
    # Fragmented IPv6 packet with an unusual extension-header chain to
    # exercise the racy IPsec inspection path in tcpip.sys.
    pkt = IPv6(dst=target) / IPv6ExtHdrHopByHop() / IPv6ExtHdrFragment(
        offset=0, m=1, id=0xdeadbeef
    ) / b"A" * 1200
    while True:
        send(pkt, verbose=False)

# Spin up many sender threads to maximise the chance of winning the
# race on the receiver side. Real exploits also pin CPU affinity and
# spray the kernel pool in parallel.
for _ in range(64):
    threading.Thread(target=storm, daemon=True).start()

input("Pressing Enter stops the storm... ")
PY

# Step 4: On a successful win, kernel-context code execution lets the
# attacker stage a SYSTEM payload over the same network channel. Catch
# the resulting beacon / reverse shell.
nc -nvlp 4444

The snippet above is illustrative only — it does not trigger CVE-2026-33827. The actual flaw is in the IPv6 + IPsec inspection path of tcpip.sys; any functionally equivalent traffic that drives concurrent access to the racy structure can reach the bug.

A simplified packet-level view of the attack:

Attacker                                            Victim (Windows + IPv6 + IPsec)
   |                                                          |
   |  IPv6 datagrams (fragmented / extension-header heavy)    |
   |--------------------------------------------------------->|  tcpip.sys ingests
   |  N parallel streams                                      |  on multiple cores
   |                                                          |  IPsec inspection
   |                                                          |  path races against
   |                                                          |  itself on shared
   |                                                          |  packet metadata
   |                                                          |  => pool corruption
   |                                                          |
   |<-- kernel-context shellcode / C2 beacon ----------------<|  controlled write
   |                                                          |  -> code execution
   v                                                          v

Exploitation in the Wild

  • 2026-04-14 — Microsoft releases CVE-2026-33827 in the April Patch Tuesday rollup; exploitability rated as one of the riskier items in the release.
  • 2026-04-14 — Zero Day Initiative calls the bug wormable on IPv6 + IPsec hosts and remarks that race conditions of this class are “exploited at Pwn2Own all the time,” pushing back on the assumption that AC:H is an effective barrier.
  • 2026-04-15 / 16 — Cisco Talos publishes Snort coverage and CrowdStrike issues advisory guidance prioritising this CVE alongside the actively exploited SharePoint zero-day in the same release.
  • 2026-04-17 — NVD publishes the CVSS 3.1 assessment (8.1 HIGH).
  • 2026-04-15 — 2026-04-28 — No verified public proof-of-concept and no confirmed in-the-wild exploitation at the time of writing. Given the wormable rating and the size of the affected fleet, weaponization is expected as a matter of when, not if. The CVE is not yet listed in the CISA KEV catalog.

Post-Exploitation Impact

  1. Kernel-context code execution: a successful exploit lands the attacker in tcpip.sys — below every user-mode security boundary on the host.
  2. Bypass of in-OS controls: AV, EDR user-mode hooks, host firewall rules, and Credential Guard’s user-mode protections are irrelevant once the attacker controls the kernel.
  3. Wormable propagation: every Windows host with IPv6 + IPsec enabled is a potential next hop. Domain-isolated networks effectively provide a built-in propagation surface.
  4. Domain compromise: a single foothold on a domain-isolated server is enough to extract machine credentials, manipulate Kerberos tickets, and pivot toward domain controllers.
  5. Persistence options: kernel implants, driver swap-outs, and EDR-evading rootkits all become available once SYSTEM / kernel context is reached.
  6. Denial of service: even unsuccessful exploitation attempts are likely to bugcheck the host (BSOD), taking critical Windows services offline.

⚠️ Impact Assessment

Immediate Impact

  • Pre-auth, network-reachable, CVSS 8.1: no credentials, no user interaction, exploitation only requires the victim to have IPv6 + IPsec enabled.
  • Kernel-context RCE: equivalent to full host takeover; no separate LPE required.
  • Wormable: every IPv6 + IPsec-enabled Windows host can be a lateral hop. Domain-isolated estates are particularly exposed.
  • Massive footprint: every supported Windows / Windows Server release ships the vulnerable code path in tcpip.sys.
  • AC:H is not a substitute for patching: race conditions of this exact class have been weaponized publicly multiple times (Pwn2Own, in-the-wild Windows TCP/IP CVEs in prior years).

Affected Versions

PlatformVulnerableFixed In
Windows 11 26H1 (x64 / ARM64)All pre-April 2026 buildsApril 2026 Cumulative Update
Windows 11 25H2 (x64 / ARM64)All pre-April 2026 buildsApril 2026 Cumulative Update
Windows 11 24H2 (x64 / ARM64)All pre-April 2026 buildsApril 2026 Cumulative Update
Windows 11 23H2 / 22H2 (x64 / ARM64)All pre-April 2026 buildsApril 2026 Cumulative Update
Windows 10 22H2 / 21H2 / 1809 / 1607 (x86 / x64 / ARM64)All pre-April 2026 buildsApril 2026 Cumulative Update
Windows Server 2025All pre-April 2026 buildsApril 2026 Cumulative Update
Windows Server 2022 / 23H2 (Server Core)All pre-April 2026 buildsApril 2026 Cumulative Update
Windows Server 2019All pre-April 2026 buildsApril 2026 Cumulative Update
Windows Server 2016All pre-April 2026 buildsApril 2026 Cumulative Update
Windows Server 2012 / 2012 R2 (ESU)All pre-April 2026 buildsApril 2026 Monthly Rollup (ESU)

Microsoft’s advisory is the authoritative source for the exact KB article and build number per product; always cross-reference MSRC CVE-2026-33827 before deploying.

Affected Environments

  • Domain-isolated estates: every member server and workstation participates in IPsec-authenticated communication and is therefore in scope.
  • IPsec-protected VPN gateways: RRAS, Always On VPN, and site-to-site IPsec endpoints with IPv6 enabled.
  • Cloud Windows VMs: Azure, AWS, GCP workloads where IPv6 is enabled (often by default in newer subscriptions) and IPsec is applied.
  • Hybrid AD: forests that require IPsec for inter-server communication or DC-to-DC replication on dual-stacked networks.
  • Internal IPv6 deployments: enterprises that have rolled out native IPv6 internally; link-local IPv6 is enabled on every Windows host by default and is reachable from any attacker in the same broadcast domain.
  • MSP / managed Windows fleets: shared IPsec policies amplify the blast radius across customers.

Attacker Profiles

  • Initial-access brokers: kernel-context RCE on a domain-isolated server is exactly the access ransomware affiliates pay for.
  • Ransomware operators: wormable kernel-level RCE on Windows is an obvious building block for the next mass-encryption event.
  • APT groups: long-term, low-noise compromise of tcpip.sys enables stealthy in-network movement below EDR visibility.
  • Internal attackers: link-local IPv6 reachability means any attacker already on the LAN can target neighbours — no routing required.
  • Hacktivists and opportunists: once a public PoC drops, the bar collapses to “scan, fire, profit.”

🛡️ Mitigation Strategies

Immediate Actions (Priority 1) ⚡

  1. Apply the April 2026 Cumulative Update on every Windows / Windows Server instance:

    # Run as Administrator on each host - inventory current build and
    # trigger Windows Update scan / install.
    Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber
    
    # Install missing updates non-interactively via the PSWindowsUpdate
    # module (install with: Install-Module PSWindowsUpdate -Force).
    Import-Module PSWindowsUpdate
    Get-WindowsUpdate -MicrosoftUpdate -Install -AcceptAll `
        -IgnoreReboot -Verbose
  2. Confirm tcpip.sys has been patched by checking its file version:

    # tcpip.sys lives in %SystemRoot%\System32\drivers. The April 2026
    # cumulative update bumps its FileVersion - compare against the
    # build listed in Microsoft's advisory for your specific OS.
    Get-Item C:\Windows\System32\drivers\tcpip.sys |
        Select-Object Name, VersionInfo
  3. Restrict inbound IPv6 to trusted sources at the perimeter and host firewall while patches roll out:

    # Host-level firewall rule - block inbound IPv6 from outside known
    # IPsec peers / management subnets. Adjust -RemoteAddress to your
    # actual trusted scope (this is an emergency stop-gap, not a fix).
    New-NetFirewallRule -DisplayName "Restrict Inbound IPv6 (CVE-2026-33827)" `
        -Direction Inbound -Action Block -Protocol IPv6 `
        -Profile Any
  4. Where IPsec is not actually required, suspend the Connection Security Rules until the host is patched:

    # Disable IPsec connection security rules - this removes the racy
    # inspection path from the ingress flow on hosts that do not need
    # IPsec for domain isolation or VPN.
    Get-NetIPsecRule -PolicyStore ActiveStore |
        ForEach-Object { Disable-NetIPsecRule -Name $_.Name }
  5. Where IPv6 is not in use end to end, do not disable it host-wide (Microsoft warns against this), but filter it at the perimeter so external IPv6 traffic cannot reach internal Windows hosts:

    # Example perimeter ACL pseudo-syntax - drop unsolicited inbound
    # IPv6 from the internet to internal Windows ranges.
    deny ipv6 any any        # default-deny inbound v6 at the edge
    permit ipv6 <established>  # allow return traffic only
  6. Reboot and verify: the patch only takes effect after the cumulative update is fully installed and the host is rebooted.

Detection Measures 🔍

No Microsoft-published IoCs exist at the time of writing. Hunt for the symptoms of exploitation: unexpected tcpip.sys bugchecks, surges of fragmented IPv6 traffic, and IPsec inspection failures.

# Look for kernel bugchecks involving tcpip.sys - failed exploit
# attempts will frequently bluescreen the host before they succeed.
Get-WinEvent -FilterHashtable @{
    LogName  = 'System'
    Id       = 1001
    ProviderName = 'Microsoft-Windows-WER-SystemErrorReporting'
} | Where-Object { $_.Message -match 'tcpip\.sys' } |
    Select-Object TimeCreated, Id, Message -First 50

# Pull recent BugCheck events (Event ID 1001 source BugCheck) and
# review the dump path - kernel pool corruption in tcpip.sys is the
# tell-tale signature.
Get-WinEvent -FilterHashtable @{
    LogName  = 'System'
    ProviderName = 'Microsoft-Windows-Kernel-General'
} -MaxEvents 200 |
    Where-Object { $_.Message -match 'BugCheck|tcpip' } |
    Select-Object TimeCreated, Id, Message

# IPsec / WFP operational log - abnormal negotiation failures from
# unexpected source IPs can precede or accompany exploitation.
Get-WinEvent -LogName 'Microsoft-Windows-IKEEXT/Operational' `
    -MaxEvents 200 |
    Where-Object { $_.LevelDisplayName -eq 'Error' } |
    Select-Object TimeCreated, Id, Message

EDR / Sysmon hunting:

# There is no clean process-creation signature for a kernel-context
# exploit. Hunt instead for:
#   - Unexpected SYSTEM-level processes spawned shortly after a
#     bugcheck / dump-write event.
#   - New kernel drivers loaded outside maintenance windows (Sysmon
#     Event ID 6).
#   - Surges of IPv6 fragmented traffic toward Windows hosts that do
#     not normally receive IPv6 traffic.

Network-side hunting:

  • Alert on spikes of fragmented IPv6 traffic toward Windows hosts.
  • Alert on IPv6 packets with unusual extension-header chains (Hop-by-Hop, Routing, Fragment combinations).
  • Watch perimeter IDS signatures for vendor coverage of CVE-2026-33827 (Suricata, Snort — Cisco Talos has published rules; Palo Alto, Fortinet, Cisco Firepower coverage to follow).
  • Alert on new inbound IPv6 flows from external sources to internal Windows hosts where IPv6 ingress is not expected.

Long-term Security Improvements

  1. Right-size IPv6 exposure: do not disable IPv6 on hosts (Microsoft warns this is unsupported), but ensure your perimeter and segmentation deliberately scope which IPv6 flows reach Windows hosts.
  2. Treat domain isolation as a tier-0 control: the same IPsec policy that hardens lateral movement can amplify a kernel-stack RCE. Pair it with strict patch SLAs.
  3. Patch SLAs for kernel-network components: tcpip.sys, http.sys, and IKEEXT deserve a 7-day critical-CVE SLA, not the default monthly cadence.
  4. Inventory IPv6 + IPsec posture continuously: know exactly which hosts have IPsec policies bound to IPv6, and alert on drift.
  5. Assume-breach playbooks for kernel-level RCE: rehearse incident response that assumes EDR-blind, kernel-context implants. Forensic capacity (memory acquisition, dump triage) should be exercised, not aspirational.
  6. Edge filtering for IPv6: even where IPv6 is rolled out internally, default-deny inbound IPv6 from the internet unless a service genuinely needs it.

🎯 Why is this Critical?

  1. Pre-auth, kernel-context RCE on Windows: among the worst bug classes the OS can produce.
  2. Wormable on IPv6 + IPsec: the affected code path lives on every Windows SKU; once a single host is taken, the rest of the IPsec fabric is reachable.
  3. Domain isolation amplifies the blast radius: the very control that makes IPsec attractive (every host authenticates every host) means every host is exposed to the same parser.
  4. AC:H is misleading: race-condition bugs in TCP/IP have repeatedly been turned into reliable exploits. The CVSS “high attack complexity” should not be read as “won’t be exploited.”
  5. Massive attack surface: every supported Windows release, including domain controllers, file servers, RDS hosts, and cloud VMs.
  6. Kernel context defeats in-OS controls: AV, host firewall, user-mode hardening, and many EDR features are bypassed once the attacker reaches tcpip.sys.
  7. Patch is the only durable answer: blocking IPv6 wholesale is unsupported and breaks modern Windows components; perimeter filtering and IPsec rule changes are stop-gaps, not fixes.

🚀 Timeline and Disclosure

  • 2026-04-14 — Microsoft publishes CVE-2026-33827 in the April 2026 Patch Tuesday release; the rollup addresses 165+ CVEs, one of the largest by CVE count in Microsoft’s history.
  • 2026-04-14 — Zero Day Initiative classifies the bug as wormable on IPv6 + IPsec hosts; CrowdStrike, SANS ISC, and Cisco Talos highlight it as a top-priority item alongside the actively exploited SharePoint zero-day.
  • 2026-04-17 — NVD publishes the CVSS 3.1 vector (8.1 HIGH, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).
  • 2026-04-15 — 2026-04-28 — No verified public PoC at the time of writing; vendor IDS coverage rolling out; CVE not yet added to the CISA KEV catalog.

🔗 Resources and References

💼 SEKurity Supports You

Vulnerabilities like CVE-2026-33827 are a reminder that the most dangerous attack surface on a modern Windows estate is rarely the application layer — it is the network stack itself, sitting in the kernel, reachable from anywhere a packet can travel. Domain-isolated networks, IPsec-protected fleets, and dual-stacked Windows environments all amplify the blast radius of a single tcpip.sys flaw. We help organizations measure their real exposure, validate that the right hosts are actually patched, and stress-test whether kernel-level compromises would be detected before they become a domain-wide incident.

Our Services

  • Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
  • Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
  • Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.


Contact:

🌐 Website: www.sekurity.de

📧 Inquiries: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH


Your SEKurity Team — Your Trusted Adversaries

The security of your Windows network stack is our drive.


Sources

About the Author

SEKurity Team

Offensive Security Experts

The SEKurity GmbH team consists of experienced penetration testers, security researchers, and cybersecurity consultants. Under the motto 'Your Trusted Adversaries', we support organizations in evaluating their IT security from an attacker's perspective and improving it.

Related Articles