Back to blog
dns Published: AEU DNS Newsroom

AI surfaces 27-year-old OpenBSD TCP SACK bug

AI surfaces 27-year-old OpenBSD TCP SACK bug

Anthropic's Mythos agent found a 27-year-old bug in OpenBSD's TCP SACK code, showing AI-driven vulnerability discovery can outpace patch cycles.

An AI-driven vulnerability discovery system has resurfaced a 27-year-old bug in the OpenBSD operating system's network code, underlining the limits of patch-based defense as artificial intelligence changes how fast security flaws are found. The bug was a signed-integer comparison error in OpenBSD's TCP SACK implementation, which handles selective acknowledgments, a mechanism that lets a receiver tell a sender which parts of a data stream it already has, so only missing parts are retransmitted. Niels Provos, a computer security practitioner with a PhD from the University of Michigan and career roles at Google, Stripe and Lacework, originally committed the code in November 1998. The mistake could drive a NULL dereference and panic the kernel, the core part of an operating system that manages hardware and system resources. On April 7, 2026, Anthropic's Mythos AI agent surfaced the flaw, exactly twelve years after the public disclosure of OpenSSL Heartbleed. Provos, writing as one of the founders of Activ8te, notes the group marked the same anniversary with a dance pop song called Heartbleed.

Thirty years ago, finding such a vulnerability depended on one person reading the right code. Provos recalls that in 1996 he read Wietse Venema's TCP Wrappers source, noticed a flaw involving loose source-routing options, built an attack and later demonstrated it live at HIP'97. The Secure Networks Inc. advisory followed in February 1997, credited to Provos through Oliver Friedrichs, making that the first hard timestamp of his vulnerability research. Today an AI harness does the same work autonomously. Mythos ran on the kernel source and surfaced the bug. Provos says he independently reproduced the result with his open-source IronCurtain framework against Opus 4.7, Sonnet 4.6 and Z.AI's open-weight GLM 5.1. His previous post details the orchestration mechanics, but the key point is that vulnerability discovery is an orchestration problem, not a frontier-model problem.

IronCurtain is open source, so the capability is neither a defender's secret nor an attacker's. Provos argues the right baseline assumption is parity on capability. The discipline that closes the gap with frontier capability is a finite-state machine, a workflow controller that is not itself a large language model. It routes specialized agents through predetermined states: analyse, hypothesize, build harness, validate and triage. Each state starts with a fresh context window rebuilt from an append-only journal on disk. States can only emit verdicts from a fixed set, and bounded loops have visit caps; if an investigation stalls, it escalates to a human instead of allowing a model to end the run by declaring a false 'looks fine'. The workflow does not require frontier weights. Open-weight GLM 5.1 served from Z.AI drove autonomous discovery on a foundational library with no manual steering. The model is large and does not run on a laptop, but anyone who can pay for an API endpoint or rent a multi-GPU instance can drive it. Per-audit cost runs in the tens to low hundreds of dollars, low enough that every dependency in a production stack is in scope for routine review.

For the past decade, the standard chief information security officer posture has been a vulnerability-management program, third-party SaaS for posture management and threat detection, and a triage cycle that never empties. That model held while the rate at which bugs surfaced was bounded by human labour available to find them. AI has removed that bound. Discovery now scales with API credit, but patch consumption does not. The window between disclosure and weaponization keeps shrinking, while the window between patch availability and patch propagation through downstream consumers does not. The second failure mode is structural: vulnerability management is reactive by design. It chases bugs the world has already discovered without eliminating the attack surface or stacking the defence in depth that would make the next one less consequential. Provos says the constraint is rarely analysis; it is budget, executive priority and access to engineers who can build proactive controls. Those engineers were in tight supply and routed by economic gravity into a handful of large technology companies. A CISO without that talent or budget can fund a vendor and a triage queue, but proactive work stalls, and when an incident lands the CISO is the named person on the postmortem.

The response, Provos argues, is not to find bugs faster but to build infrastructure that takes attack classes off the critical path of ongoing human security decisions. He calls these security invariants: machine-enforced constraints applied consistently across an infrastructure that impede one or more steps of an attack kill chain without requiring a per-incident human judgment. The bug may still exist; what changes is whether an attacker can complete the chain. Instead of asking which bugs an adversary will find, ask what an adversary can do after finding any bug. In a companion analysis of public breach disclosures on securityblueprints.io, Provos found that three machine-enforced invariants applied consistently would have impeded a majority of incidents in the dataset, on the order of 65%.

Hardware two-factor authentication replaces shared-secret authentication with cryptographic proof of possession of a registered device. It removes credential phishing as a viable initial-access vector. Google deployed this internally beginning around 2010 after Operation Aurora and has reported zero successful credential-phishing compromises of an employee since. The example is fifteen years old, yet most enterprises still run on shared-secret authentication because the rollout disrupts legacy integrations built on the assumption that passwords are sufficient. Egress control means default-deny outbound network traffic from production. An attacker who compromises an externally exposed service and gains code execution is usually not done; the meaningful damage follows the arrival of a second-stage payload and the establishment of command-and-control. Egress control removes that step. The log4j campaigns of December 2021 are the canonical illustration: every initial-access exploitation that mattered relied on the compromised host reaching outbound to fetch a next stage. A production environment that cannot make arbitrary outbound calls renders the entire vulnerability class less consequential, irrespective of whether the underlying log4j bug ever gets patched on that particular host. Positive execution control means only allowlisted binaries are permitted to run. Social-engineering attacks where an attacker poses as IT support and asks a target to download and execute a diagnostic tool become structurally impossible. The target's machine refuses the binary regardless of how convincing the pretext was. Microsoft has made the same observation around Smart App Control, and several large enter

Terms explained

zero-day
A security hole that is unknown to the software maker until it is found or attacked, leaving no time to patch before first use.
kernel
The core part of an operating system that manages hardware and system resources.
SACK
Selective Acknowledgment, a network protocol feature that lets a receiver tell a sender which parts of a data stream safely arrived.
security invariant
A machine-enforced rule applied consistently across systems that blocks part of an attack without needing a human decision each time.
egress control
A rule that blocks outbound network connections from production servers by default, so a compromised system cannot easily fetch attacker tools.
allowlisting
Allowing only approved programs to run, so anything not on the approved list is refused automatically.
memory tagging
A hardware feature that attaches a label to each block of memory, making many memory safety bugs crash at the moment of misuse instead of silently corrupting data.
CADA
Context-Aware Data Access, a control that only lets a support account see or change data when a current, independently verifiable business reason exists.

How to protect yourself

  1. Turn on two-factor authentication for your email and any account that controls your website, using an authenticator app or a hardware security key.
  2. Keep your devices and website software updated, because updates often close security holes before attackers can use them.
  3. Do not download or run programs or plugins from unknown sources, even if someone claiming to be support asks you to.
  4. Use a password manager to create unique passwords for every account, so a single stolen password does not open others.
  5. If you run a website, check that your hosting provider limits outbound connections and restricts access to customer data to the minimum needed for a task.
  6. Back up your website and important files regularly, and test that you can restore them.
Get private, encrypted DNS