Key points
- The exploit chains an integer overflow in a shared memory counter with a use-after-free vulnerability.
- OpenBSD released fixes in Errata 018 and 026 before the proof-of-concept was published on October 16, 2026.
- The attack bypassed KARL, SMAP, and SMEP protections by targeting predictable kernel allocator behavior.
Security researchers at Calif published a proof-of-concept exploit on October 16, 2026, demonstrating how local users can gain root access on OpenBSD systems. The attack chains two distinct kernel flaws, including a bug originating in the original BSD source code approximately 37 years ago. OpenBSD developers had already issued patches for both issues prior to this public disclosure.
The primary vulnerability involves the shared memory attachment counter, named shm_nattch, which uses a signed 16-bit value. By repeatedly forking processes that create shared memory records, an attacker can push this counter past its maximum limit of 32,767. This causes the number to wrap into a negative value, triggering an integer overflow that leads to a race condition and a subsequent kernel use-after-free error.
Technical Mechanics of the Exploit
The second flaw involves a conditional out-of-bounds write that allows the attacker to leverage the memory corruption for code execution. The exploit maps 127 shared memory segments, removes those mappings, and forks 259 processes to force the counter wrap. It then shapes kernel heap memory and monitors allocator data using sysctl(KERN_MALLOCSTATS). One process marks a shared memory object for removal with IPC_RMID, while a helper process attempts to attach a new segment at the precise moment to create a size-confused kernel allocation.
Researchers place IP socket objects near the freed memory and use IP_MULTICAST_TTL to create a persistent struct ip_moptions object. The out-of-bounds write alters two membership counters within this structure. Closing the socket initiates atomic counter changes that modify OpenBSD’s self-referencing page-table mapping, making user-space mapping available to supervisor mode and allowing the overwrite of a predictable kernel pointer.
Affected Environments and Mitigations
This exploit chain works even with OpenBSD protections such as KARL, SMAP, and SMEP enabled, and it does not require a separate information leak. Although KARL randomizes kernel code and data addresses at boot, Calif found that parts of the kernel memory allocator remain predictable on identical hardware. Early boot objects can land at stable locations, allowing the exploit to target the lo0 and enc0 ioctl handler pointers. OpenBSD addressed the integer overflow in Errata 018 and the reference-counting use-after-free in Errata 026.
Next steps
System administrators should verify that their OpenBSD installations have received the updates corresponding to Errata 018 and 026. Since the research does not report active use in real-world attacks, immediate threat hunting is not required, but ensuring patch compliance is essential to close this local privilege escalation path. Teams should review their update deployment processes to ensure kernel patches are applied promptly.
Signals worth monitoring
Teams usually monitor for unusual process forking patterns that might indicate an attempt to exhaust kernel resources or manipulate shared memory counters. Check whether local accounts are generating excessive shared memory segments without corresponding application activity. Look for unexpected changes in kernel memory allocator statistics or anomalous sysctl queries related to memory management. Contain potential compromises by isolating affected hosts and reviewing local user activity logs for signs of privilege escalation attempts.
What to do and how to stay safe: OpenBSD
- Verify that your OpenBSD systems are patched against Errata 018 and 026 to mitigate the integer overflow and use-after-free flaws.
- Monitor local user processes for abnormal forking behavior or excessive shared memory segment creation that could indicate exploitation attempts.
- Review kernel logs for unexpected memory allocation errors or race conditions that may signal an attacker manipulating kernel state.
- Ensure that once the vendor provides an update for any future related issues, it is deployed immediately to maintain system integrity.
Step-by-step guide: Emergency Patching Checklist for Critical System Fixes
General security guidance from the SecOps Monitor newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Is there evidence of this OpenBSD flaw being used in the wild?
The published research covers a local privilege escalation exploit and does not report active use in real-world attacks.
How does the exploit bypass OpenBSD's kernel protections?
The exploit bypasses KARL, SMAP, and SMEP by targeting predictable locations in the kernel memory allocator on the same hardware.
Which OpenBSD errata address these specific vulnerabilities?
OpenBSD addressed the integer overflow in Errata 018 and the reference-counting use-after-free in Errata 026.
