CVE-2026-68820
AFD WinSock: unsynchronised socket-state access races a free against a dereference, giving kernel read and write
Exploited in the Wild
Used as a zero-day by Lazarus Group for roughly five weeks before the August 2026 patch, to deploy FudModule v3.1.
Summary
| Field | Value |
|---|---|
| Driver | afd.sys |
| Vulnerability Class | Use-after-free from a race condition |
| Vulnerable Build | 10.0.26100 and 10.0.26200 before the August 2026 update |
| Fixed Build | 10.0.26100.9168 and 10.0.26200.9168 (KB5121003, 11 August 2026) |
| Exploited ITW | Yes, by Lazarus Group |
| CVSS | 7.0, rated Important by Microsoft |
Affected Functions
Not public. Microsoft's advisory names no symbol, and no vendor writeup has published the racing paths, the offsets, or the object involved. Everything below is at the level the published sources actually support.
Verdict basis
cited, as of 2026-09-07. The vulnerability, the patch and the attribution are confirmed
by Microsoft's own servicing note and by Check Point Research. The internals are not, so
nothing here should be read as a reversing result.
Context
afd.sys is the Ancillary Function Driver for WinSock. Every socket call any process makes
lands here, so the driver is reachable from any privilege level without configuration and
cannot be removed. It is also the third most productive component in this corpus.
That combination is the whole story. See the AFD deep dive for why the same bug shape keeps reappearing in it.
Root Cause
afd.sys maintains per-socket state. Under conditions Microsoft has not detailed, two of the
driver's own code paths can operate on that state at the same time without synchronisation. One
path frees the allocation while the other still holds a pointer into it, so the second path
dereferences memory that has been returned to the pool.
The exploitable window is between the free and the dereference. An attacker who can place controlled data into the freed block during that window chooses what the second path reads back.
This is the same shape as CVE-2026-21241, where the race was in the
spinlock release around AfdNotifyPostEvents, and as CVE-2025-60719, a
race between socket teardown and a concurrent operation. Whether CVE-2026-68820 touches the same
paths is unknown.
Exploitation
Lazarus Group used this as a zero-day in Operation Dream Job, their long-running campaign of fake job offers aimed at defense, aerospace, aviation, drone, robotics and military technology organisations. Exploitation ran for roughly five weeks before Microsoft shipped the fix on 11 August 2026.
The bug is not remotely reachable. Sockets are serviced by afd.sys in kernel mode, but nothing
about the flaw is exposed to a remote peer. It becomes valuable only after a foothold, which the
campaign obtained through social engineering. That places it in the same role as every other
entry in this corpus: not the way in, but the way up.
Exploitation Primitive
The race converts to an arbitrary kernel read and write, and from there to SYSTEM by rewriting the process token. See token swapping.
Why a signed Microsoft driver, and not a dropped one
This is the second time this actor has chosen a driver Windows already ships rather than bringing a vulnerable one. The first was CVE-2024-21338, the AppLocker driver, also used to deploy FudModule.
The reasoning is the same both times, and it is a gap in a whole category of defense. The
vulnerable-driver blocklist, HVCI's signing policy and driver-load telemetry all answer the
question "should this driver be allowed to load". For afd.sys the answer is yes on every
Windows machine, because networking does not work otherwise. No blocklist entry is possible, no
load event is anomalous, and no signature check fails.
What the access was spent on
FudModule v3.1 is the payload, and it is a direct illustration of what a kernel primitive buys against user-layer defenses. Reported behaviour:
- Strips telemetry callbacks, the kernel notification registrations EDR products depend on.
- Disables minifilters.
- Kills the NT Kernel Logger.
- Blinds over 90 ETW providers, using a kill-list close to earlier versions.
- Tampers with Smart App Control's verified-and-reputable policy.
- Drops the dedicated Defender-disabling routines earlier versions carried, in favour of generic suppression.
Every item on that list is a decision recorded in kernel memory. None of them is defeated in the sense of being broken; each is edited. That is the pattern the Protected Process Light page argues in the abstract, and this is it happening in the field.
Note what is absent. Nothing in the reported behaviour touches Credential Guard, because the secrets it protects do not live in memory the kernel can reach.
Detection
The load of afd.sys is not a signal; it is present on every machine. Detection has to move to
what the access was used for.
Behavioural Indicators
- Kernel notification callback arrays losing entries, particularly process, thread, image and object callbacks belonging to a security product.
- ETW providers going silent in bulk. A kill-list of 90 or more providers disabled in a short window is not a configuration change any administrator makes.
- The NT Kernel Logger session stopping without an operator action.
- Minifilter altitude changes or unexpected detach.
- Smart App Control policy state changing outside a Windows update.
Bulk telemetry loss is itself the alert. A sensor that stops reporting is reporting something.
Patch state
KB5121003 moves 24H2 and 25H2 to 26100.9168 and 26200.9168 respectively. As with any
kernel patch, the running image is unchanged until the machine reboots, so an installed-but-not-
rebooted host stays exploitable. Inventory on build number, not on update status.
Broader Significance
This is the fourth in-the-wild afd.sys bug in this corpus and the second time Lazarus has
reached SYSTEM through a Microsoft-signed driver that was already loaded. Treating BYOVD as the
threat model misses both.
It is also worth noting where it lands relative to this site's own coverage. The bug affects 26100 and 26200, the two newest builds, which are exactly where the bypass matrix currently cannot distinguish one configuration from another. A live zero-day on those builds is a reminder that an absent verdict is not a safe one.