The 27-Year-Old Bug: Under the Hood of Bugmageddon

If you have not read my original post on Anthropic Mythos, I encourage you to read it before diving into this one: here is the link.

This post is about what is actually underneath it. One specific bug. A 27-year-old flaw sitting inside OpenBSD, a security-focused operating system used in important internet-facing infrastructure. It survived years of testing and review before Mythos surfaced it.

Here is what it actually was, and why this case matters.

First, how do computers actually talk to each other?

When two computers send data over the internet, the data does not travel as one big block. It breaks into small numbered chunks called packets. Think of them as numbered envelopes.

Computer A sends envelopes 1 through 10 to Computer B. If envelope 5 goes missing, Computer B needs to tell Computer A which ones arrived and which ones did not.

The old way was wasteful. Computer B could only say: "I received everything up to envelope 4." So Computer A had to resend 5, 6, 7, 8, 9, and 10, even the ones that had already arrived safely.

In 1996, a smarter system was introduced. It was called SACK, which stands for Selective Acknowledgement. Now Computer B could say: "I am missing envelope 5, but I already have 6 through 10. Only resend 5." Much more efficient. OpenBSD added SACK in 1998.

That is exactly where the bug was hiding.

One Concept First

TCP sequence numbers are like In-N-Out order numbers on a very busy day. The screen counts from 1 to 99. After 99, it starts again at 1.

So if someone says "I served orders 95 to 15," it sounds wrong at first. But if the numbers wrapped around, it makes sense: 95, 96, 97, 98, 99, 1, 2, 3 … 15.

TCP sequence numbers are 32-bit unsigned integers. They go from 0 to 4.29 billion, then wrap back to 0.

What the Attacker Actually Did

• OpenBSD sends packets 1–100 to System B
• System B replies: "I got 1–10. I also got 15–100"
• OpenBSD infers the gap — writes: Missing: 11–14 — resends them
• Attacker sends malicious SACK range: 95–15
• TCP wrap-around: 95 → 96 → 99 → 0 → 1 → 2 → 15 — 95 appears before 11
• OpenBSD reads: "95–15 covers 11–14" — deletes Missing: 11–14
• OpenBSD infers: what about 15–94?
• Tries to write: Missing: 16–94
• Reaches for old 11–14 entry — already deleted
• Pointer is null — writes through it anyway
• Kernel panic

In computing, writing to nothing is called a null pointer. It does not produce a wrong answer. It does not slow things down. It crashes the machine. In this case, that crash could be triggered remotely, and repeated.

No physical access needed. No password. Just one crafted message sent over the internet.

So why did nobody catch this for 27 years?

Because the bug needed a very specific chain.

Normal traffic would not send a weird SACK range like 95–15. OpenBSD first had to accept that malformed range. Then wrap-around math had to make it look like it covered 11–14. Then OpenBSD had to delete the only missing-range entry. Then: OpenBSD infers: what about 15–94?

That exact sequence is rare.

It was a hidden interaction between input validation, TCP wrap-around math, and missing-list bookkeeping. That is why it survived for decades.

That is what makes this moment feel like Bugmageddon.

Not because someone made a mistake last week. Because old code across critical systems may be carrying hidden technical debt that is only now becoming easier to discover.