
ALPC You Later: CVE-2025-64721 Sandbox Escape Smashing The Heap Over IPC
ALPC You Later: CVE-2025-64721 Sandbox Escape Smashing The Heap Over IPC | depthfirst
CVE-2025-64721 is a Sandboxie vulnerability in the SYSTEM service SboxSvc.exe, reachable over the raw ALPC port \RPC Control\SbieSvcPort. The RC4Crypt handler never checks value_len against the message length, giving an out-of-bounds heap read and, via a 32-bit integer overflow (0xFFFFFFF1), a 4GB heap write. The post explains a two-thread vtable-hijack plan to escape the sandbox. It was reported and patched on 12 November 2025.
What it is
CVE-2025-64721 is a heap bug in the Sandboxie service SboxSvc.exe, which runs as SYSTEM. A sandboxed process can reach it over the raw ALPC port \RPC Control\SbieSvcPort. The flaw is in the RC4Crypt handler (SbieIniServer::RC4Crypt, message ID MSGID_SBIE_INI_RC4_CRYPT, 0x180F) in Sandboxie/core/svc/sbieiniserver.cpp. The author, a depthfirst researcher (not named on the page), presents it as a sandbox escape to SYSTEM.
How it works
The handler checks h.length against the struct size but never checks value_len against h.length. The client controls both fields, so two primitives follow.
- Out-of-bounds read: A 20-byte message with
value_lenset to 1000 makesmemcpycopy about 996 bytes of adjacent service heap into the reply. The reply is RC4-encrypted, but the client can send it back to the same API to decrypt it. This leaks pointers, vtables and heap metadata, and the heap is otherwise randomized. - Heap write: Setting
value_lento 0xFFFFFFF1 makes16 + value_lenwrap in a 32-bit ULONG, so the allocator is asked for 1 byte. Sandboxie's pool allocator hands back a 128-byte cell. Thememcpystill uses the originalvalue_len, so it writes up to 4GB from that cell.
The page's exploitation plan uses two threads. It first grooms the heap so a C++ object with a vtable sits right after the reply cell. Thread A loops calling a function that uses that object. Thread B sends the malicious packet, and the copy overwrites the vtable. Thread A then jumps into a ROP chain, whose first job is to suspend the copying thread before the copy hits an unmapped page. The page says shared DLLs sit at the same addresses inside and outside the sandbox, so ROP gadgets are at known locations. The author leaves the full exploit "as an exercise for the reader" and gives no working code.
Preconditions / Affected
- The attacker must already run code inside a Sandboxie sandbox, since the port is reached through SbieDll.dll's IPC channel.
- Without the grooming and the thread race, the result is an access violation (0xC0000005) in the service. That is a denial of service for every sandboxed process on the host.
- The page names no affected version range and no fixed release number.
What to do
Update Sandboxie to a build that includes the fix. DavidXanatos patched it within an hour of the report, but the page does not say which release contains it.
Timeline from the page:
- 12 November 2025: reported and patched.
- 11 December 2025: advisory published.
- 23 December 2025: technical details published.
Caveats
The author tested only in a local environment. The exploit chain is described but not demonstrated or released.
Organisations named here
- depthfirst
- heap overflow
- vtable hijack
CVEs named here
- CVE-2025-64721
Technologies named here
- Windows
- C
- ALPC (Advanced Local Procedure Call)
- depthfirst
- Sandboxie
- Sandboxie (SboxSvc.exe service, SbieIniServer component, sbieiniserver.cpp RC4Crypt handler for MSGID_SBIE_INI_RC4_CRYPT 0x180F); the page gives no affected version range
- SbieDll.dll
- SbieDrv.sys
- SboxSvc.exe
- Windows x64 (platform where the 32-bit ULONG addition wraps)
Techniques named here
- Out-of-bounds read
- Integer Overflow
- Sandbox escape
- ROP
- Denial of service via access violation
- Heap buffer overflow
- Heap grooming
- Vtable hijacking / ROP chain
Also named here
- ALPC
Related in Offensive Security