Understanding the Avast Sandbox

Part 2 Completes the Chain From Sandbox Entry to SYSTEM

SAFA Team published “CVE-2025-13032: Entering and Breaking the Avast Antivirus Sandbox Part 2” on September 18, 2026, and it closes the loop the first post left open. Part 1, released December 1, 2025, documented four kernel heap overflows and two local denial-of-service bugs in Avast’s aswSnx driver, plus the counterintuitive discovery that the vulnerable IOCTL only accepted calls from processes already inside the Avast sandbox. That meant reaching the bug required breaking into the sandbox rather than escaping it. Part 2 finishes the job: it walks through how a controlled paged-pool overflow was turned into an arbitrary kernel read/write primitive on an up-to-date Windows 11 system, how a kernel address leak was obtained to aim it, and how token theft delivered SYSTEM privileges.

Key Takeaways:

• SAFA Team’s Part 2, published September 18, 2026, shows full exploitation of CVE-2025-13032 on a patched Windows 11 host, ending in SYSTEM via token theft.
• The flaw is a double fetch in Avast’s aswSnx sandbox kernel driver, classified as CWE-367 (TOCTOU race condition), affecting Avast Antivirus, Avast One, and AVG Antivirus on Windows prior to version 25.3.
• cvefeed.io records a CVSS 3.1 base score of 9.9 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), reflecting a low-privilege local attacker with no user interaction.
• The exploit corrupts the RegBuffers array of an I/O Ring object, turning a paged-pool overflow into arbitrary kernel read/write.
• Windows user-mode accessors, now used by the current kernel and drivers, would block the specific technique described in the writeup.

The Double Fetch: One Field, Two Reads

The root cause sits in a single routine that captures a user-supplied _UNICODE_STRING structure. The driver calls ProbeForRead to confirm the structure and its buffer live in userland, then hands the structure to a helper that allocates a pool buffer sized to the string’s Length field. The problem is that Length is read from user memory twice: once to size the allocation, and again to drive the copy. Between those two reads, a second thread in the attacker’s process can flip the field from a small value to a large one, so fewer bytes are allocated than are copied. The result is a pool overflow in which both the allocation size and the overflow payload are attacker-controlled.

SAFA describes the race as narrow but winnable: one thread runs in a tight loop toggling Length between a safe value and a large malicious one (the writeup cites 0x1000, larger than the allocated buffer), while the main thread calls the vulnerable IOCTL repeatedly. When the timing lines up, the kernel reads the small value for ExAllocatePoolWithTag and the large value for the memmove. This is textbook CWE-367, the time-of-check time-of-use race condition that the SentinelOne vulnerability database entry assigns to the CVE. The fix Gen Digital shipped, per SentinelOne, captures user-supplied values into kernel-controlled storage before validation and use, which removes the race window entirely.

Corrupting the I/O Ring RegBuffers Array

The overflow lands in paged pool, which the Windows Segment Heap groups by size class, so same-sized allocations tend to sit near each other. SAFA chose the I/O Ring object as the corruption target for several stated reasons. The object’s RegBuffers field is itself allocated in paged pool, matching where the overflow occurs. Its size is fully user-controlled, since registering N buffers produces an array of N eight-byte pointers, giving precise control over allocation size. And corrupting a single pointer in that array is enough to gain a full arbitrary read/write primitive.

The primitive works because registered I/O Ring buffers are validated once at registration and then reused without re-checking. SAFA redirects a RegBuffers entry to point at a fake _IOP_MC_BUFFER_ENTRY structure the attacker controls in userland. When the kernel performs a subsequent I/O operation through that entry, it dereferences the fake structure and reads its Address field as the transfer target. This is only possible because Windows does not implement SMAP (Supervisor Mode Access Prevention), which would otherwise stop the kernel from dereferencing a userland pointer. From there, IoRingReadFile becomes an arbitrary kernel write and IoRingWriteFile becomes an arbitrary kernel read, with the Address field updated from userland to redirect each operation.

The technique is not novel to this research. SAFA credits the Windows Internals writeup on I/O Ring objects as prior public work establishing the same read/write primitive, which is exactly why defenders should treat this object class as a known target rather than a curiosity. The Avast-specific contribution is the path from the double fetch to that object.

Heap Spray, MDL Leak, and the Teardown Repair

Landing the overflow on a live RegBuffers allocation requires a heap spray. SAFA picks a buffer count N that places the RegBuffers allocation in the same pool bucket as the overflowing string buffer, which is allocated at Length + 16 bytes. That sizing matters: it ensures the freed RegBuffers holes are exactly the right size to receive the overflowing allocation. The strategy is to allocate many RegBuffers structures, free a subset to create right-sized holes, then trigger the vulnerability so the overflow lands in a hole and corrupts an adjacent entry. Because the low-fragmentation heap randomizes slot selection within its subsegments, precise placement is not possible, so the approach floods the pool to make adjacency reliable.

With the primitive in place, the exploit still needs a kernel address to target, specifically the attacker process’s own _EPROCESS structure for the token theft. Kernel addresses are randomized, so SAFA leaks one through MDL introspection: the registered buffer’s _IOP_MC_BUFFER_ENTRY holds an _MDL pointer, and walking that structure yields a kernel address. The writeup also notes that repairs are needed to avoid a blue screen on teardown, since the corrupted structures must be restored before the process exits cleanly.

One caveat undercuts the longevity of the technique. SAFA notes that current Windows kernels and drivers use user-mode accessors to verify each kernel access to user-mode memory, and that this mitigation would prevent the specific exploitation method described. That places the writeup in a specific window: it is a complete, working chain against the state of Windows 11 at the time of discovery, not a permanent recipe.

Affected Versions and the Patch Timeline

Avast and AVG products on Windows before version 25.3 are affected. The CVE record was modified on June 17, 2026 to add the affected-product list: Avast Antivirus (Free, Premium, and Ultimate), Avast One, and AVG Antivirus (Free, Internet Security, and Ultimate), all with versions less than 25.3 on the Windows platform. The same June 17 update recorded a CISA Coordinator SSVC entry with an exploitation status of “none” and technical impact of “total,” which is a snapshot of exploitation activity as of that assessment rather than a permanent guarantee.

The disclosure and patch timeline is unusually fast for a kernel bug in a widely deployed security product. Per Cyber Security News, most of the vulnerabilities were fixed within about 12 days of initial acceptance, and CVE-2025-13032 was officially published on November 11, 2025. The research targeted Avast 25.2.9898.0. The affected code is not necessarily unique to Avast: SAFA noted strings suggesting the kernel components are shared across Gen Digital antivirus products including Avast, AVG, Norton, and Avira, though the team did not verify whether the implementations are identical. That caveat matters for anyone scoping exposure, because it means the true blast radius could extend beyond the products named in the CVE record.

Detection and Monitoring Guidance

Detecting exploitation of this flaw means watching for the artifacts a race-based kernel overflow leaves behind. SentinelOne’s detection guidance lists kernel pool corruption bugchecks such as BAD_POOL_HEADER, BAD_POOL_CALLER, and KERNEL_SECURITY_CHECK_FAILURE on hosts running Avast or AVG builds earlier than 25.3. Those bugchecks are the same class of crash a failed race produces, so a cluster of them on one endpoint is a signal worth escalating rather than dismissing as hardware flakiness.

Process-integrity transitions are the second signal. SentinelOne recommends monitoring for token manipulation, where a non-privileged process suddenly executes with NT AUTHORITY\SYSTEM integrity, and for unexpected SYSTEM-level child processes spawned from medium- or low-integrity parents. For log pipelines, the guidance is to forward Windows kernel crash dumps and Event ID 1001 (BugCheck) entries to a central platform for correlation, and to track new services, scheduled tasks, or registry persistence created shortly after an antivirus driver crash on the same host. The race itself can be hunted: high-frequency DeviceIoControl calls to Avast or AVG driver device objects in tight loops match the double-fetch exploitation pattern.

A Mitigation Checklist for Windows Fleets

No vendor-supplied workaround exists for CVE-2025-13032; the 25.3 update is the only supported remediation per SentinelOne. That makes the update the center of any response, but the surrounding controls limit exposure while it rolls out.

• Inventory and patch. Enumerate installed Avast and AVG versions across the fleet and flag every build below 25.3. Prioritize multi-user systems, jump hosts, and developer workstations, where a local attacker has the interactive session the exploit requires.
• Restrict local logon. Reduce local interactive logon rights on sensitive hosts to shrink the population of users who can trigger the attack, since the vector demands local access and a low-privileged authenticated session.
• Enforce allowlisting where patching lags. SentinelOne recommends application allowlisting to block unauthorized binaries from interacting with the vulnerable driver on hosts where the update is delayed.
• Remove unnecessary local tooling. Strip local administrative tooling from shared Windows hosts until the update is deployed.
• Alert on driver-interaction anomalies. Build detections for unsigned or suspicious processes opening handles to the Avast or AVG sandbox driver device object, and for integrity-level transitions that cross from Medium to System without a documented elevation path.

The transferable lesson is about where the bug lived. A sandbox is supposed to contain untrusted code, and here the sandbox driver’s own IOCTL surface was the entry point, reachable only after registering a process into the sandbox configuration through a read-only-permission IOCTL. Kernel drivers that parse user-supplied structures must copy those structures into kernel memory once and validate the copy, never re-read fields from user memory after a check. The same discipline that prevents double fetches in any kernel component applies with more force to security software, whose drivers run in Ring 0 on every protected endpoint. The Linux kernel’s own history with local privilege escalation through memory corruption, including the Copy Fail and Dirty Frag flaws covered in Help Net Security’s reporting on CVE-2026-31431, shows the pattern is not specific to any one operating system or vendor. What changes is the target, and a security product’s kernel driver is a high-value one.

Related Reading

More in-depth coverage from this blog on closely related topics:

• F-Droid 2.0 App Store Update and Features
• AI Market Cap Comparison
• What Is Vision Pro and Its Features
• AI Inference Cost Trends and Economics
• Opus 5.5 Update: Features and Review

Sources and References

Sources cited while researching and writing this article:

• CVE-2025-13032: Avast Antivirus Privilege Escalation Flaw
• Windows Internals writeup on I/O Ring objects
• user-mode accessors
• CVE-2025-13032 : Double fetch in sandbox kernel driver in Avast/AVG Antivirus <25.3 on windows