Calif researchers have published a root exploit for OpenBSD 7.9 that traces back to a counter type in BSD code from the late 1980s. They went public only after OpenBSD had fixed both underlying bugs, which makes this a useful case study in how coordinated disclosure should work with a volunteer-run project.
What happened
On 16 October 2026, Andrew Griffiths of offensive research firm Calif published “Big Fish”, a writeup and proof of concept for a local privilege escalation to root on OpenBSD. Calif says it reported the vulnerabilities to the OpenBSD project earlier this year, in several cases with suggested patches, and held the research back until fixes had shipped.
According to The Hacker News, OpenBSD released the fixes as two 7.9 errata: errata 018 on 14 September and errata 026 on 30 September, both available through syspatch. The overflow fix was backported to 7.8 as well. When the research appeared, neither flaw had a CVE identifier and there was no evidence of exploitation in the wild.
The attack is local: an attacker must already be able to run code on the host, so this turns a low-privileged foothold into full control rather than offering a way in.
The detail
At a high level, the chain combines two separate kernel bugs. The first is an integer overflow in the counter that tracks System V shared memory attachments. That counter has been a signed 16-bit value since the original BSD sources, and OpenBSD inherited the type without widening it. The second is an unrelated out-of-bounds write elsewhere in the kernel. Neither alone gave Calif root.
What makes the research notable to defenders is the mitigations it got past. OpenBSD has a strong reputation for proactive hardening, and Calif reports success with KARL kernel relinking, SMAP and SMEP all enabled, and without needing a separate information leak. Griffiths argues that while KARL randomises where kernel code and data are linked, the kernel’s memory allocators are still deterministic, so certain early-boot structures land in the same place on the same hardware every time. In his words, those allocators “remain deterministic”.
Calif goes beyond the two fixes and proposes structural hardening: safe-unlinking checks on kernel linked lists (FreeBSD and NetBSD already have these), randomising the page table self-map, randomising the kernel allocator, and compiler-based bounds checking. GBHackers notes that the research does not confirm any of these extra measures has been adopted in supported releases.
Why it matters for UK organisations
OpenBSD is not a mainstream desktop or server platform in most UK estates, but it turns up in places that matter: firewalls and routers built on pf, VPN concentrators, jump hosts and appliances run by security-conscious teams that chose it precisely for its hardening record. If those boxes sit at your network edge, a local root bug is significant, because any lower-privileged foothold, whether from a compromised service account or a weak shell login, can become complete control of a perimeter device.
There is also a classification point. The Hacker News reports that OpenBSD shipped errata 018, which it ties to the integer overflow at the start of the chain, as a reliability fix rather than a security fix, though Calif’s writeup appears to pair the errata the other way round. Teams that triage patches by vendor label alone could easily have deprioritised it. Severity labels reflect what the maintainer knew at the time, not what a determined researcher can later build.
The disclosure model is worth noting too. OpenBSD runs no bug bounty. The project fixed the flaws, the researchers waited, and the full details arrived only once syspatch could deliver the fixes. That is exactly the outcome a well-run vulnerability disclosure policy is meant to deliver.
For UK researchers, the legal backdrop remains unsettled. During Lords Grand Committee on the Cyber Security and Resilience Bill on 7 September, the Government said the Home Office proposes a defence to Section 1 of the Computer Misuse Act for “accredited cyber security researchers”. No accreditation scheme has been described publicly, and Lord Clement-Jones withdrew his amendment, saying he may return to it at Report stage. Report stage is scheduled for 26 October, although that date may be provisional. For now, research of this kind done in the UK still depends on authorisation, careful scoping and good records.
Expert view
In my experience, the bugs that do the most damage are rarely the clever new ones. They are old assumptions nobody has revisited, like a 16-bit counter that was perfectly reasonable on 1980s hardware and became an attack primitive once machines could easily fork enough processes to overflow it. Long-lived codebases are full of these, and fresh eyes find them.
Calif’s writeup does not say AI tools were used to find these bugs, so I won’t claim they were. It does point out that AI-assisted vulnerability discovery makes it more important to mitigate whole classes of bugs rather than chase individual ones, and I agree. If discovery is getting faster and cheaper, the defender’s return comes from making each bug harder to weaponise: randomising what can be randomised and adding integrity checks where memory corruption tends to end up.
I would also credit OpenBSD here. A small volunteer team took the reports, shipped errata through its normal channels and let the researchers publish on their own timetable once users were protected. Plenty of well-funded vendors with paid bounty programmes handle reports far worse. Sending suggested patches with a report, as Calif says it often did, also earns trust and speeds fixes.
When we test perimeter kit, local privilege escalation is often waved away because an attacker would “need to be on the box first”. Edge devices are exactly where attackers seek that foothold.
What to do now
- Patch OpenBSD hosts. Run syspatch on every OpenBSD 7.9 system to apply errata 018 and 026, and confirm 7.8 systems have the integer overflow fix. This maps directly to the Cyber Essentials security update management control.
- Find the hidden OpenBSD. Check your asset inventory for appliances, firewalls and jump hosts built on OpenBSD, including ones managed by third parties or bought as turnkey products.
- Don’t triage by label alone. Review how your patch process handles fixes marked “reliability” or “stability” on security-relevant systems, especially edge and management infrastructure.
- Reduce local access. Limit shell accounts on perimeter devices, enforce MFA for administrative access and remove dormant users, in line with Cyber Essentials user access control.
- Check your disclosure route. Make sure your organisation publishes a clear vulnerability disclosure policy with a monitored contact, so researchers who find problems in your systems can report them safely.
- Researchers: keep records. Until any Computer Misuse Act defence is enacted, keep written authorisation, scope documents and disclosure correspondence for every engagement.
Bottom line
Big Fish is a reminder that decades-old design choices can still yield root on one of the most hardened operating systems available, and that strong mitigations raise the cost of exploitation without removing it. It is also a clean example of coordinated disclosure done properly. Patch your OpenBSD estate, take vendor reliability fixes on edge kit seriously, and keep an eye on Report stage of the Cyber Security and Resilience Bill on 26 October.
Sources
- Calif: Big Fish: Exploiting a 37-Year-Old Kernel Bug in OpenBSD
- The Hacker News: Researchers Demonstrate OpenBSD Root Exploit Chaining 37-Year-Old Shared-Memory Bug
- GBHackers: OpenBSD Kernel Flaw Dating Back 37 Years Enables Local Privilege Escalation to Root
- PK Sharma: A Computer Misuse Act defence, gated on accreditation that does not exist
- CSRB Guide: Cyber Security and Resilience Bill Report Stage, 26 October 2026
