OpenSSH is arguably the most reviewed piece of security software in the world. It's open source, widely deployed on hundreds of millions of servers, and scrutinized by security professionals, cryptographers, and paranoid sysadmins for nearly three decades. When CVE-2024-6387 was disclosed in July 2024, it was a reminder that none of that is enough.
The vulnerability — dubbed regreSSHion by Qualys researchers — was a race condition in the signal handler of OpenSSH's server process. A race condition means the bug only manifests when two events occur in a specific, narrow timing window. The more dangerous variant had actually been fixed in 2006, but the fix was incomplete: it addressed the immediate symptom without closing the underlying race. The vulnerability was reintroduced by a subsequent change that restored the original broken state. It sat undetected from 2006 to 2024.
Why Race Conditions Survive Code Review
Race conditions are uniquely hard to catch by reading code. The bug isn't in any single line — it's in the relationship between two code paths that can interleave at runtime in ways that aren't apparent statically. A reviewer examining the signal handler in isolation sees correct code. A reviewer examining the preceding change that reintroduced it sees a reasonable refactor. The bug only exists in the composition.
Qualys found it using a combination of AI-assisted static analysis and deep domain knowledge about the signal-handling patterns that tend to produce race conditions. The process involved systematically enumerating signal handler invocations across the codebase, flagging those that accessed non-reentrant functions, and reasoning about which of those could be exploited given OpenSSH's authentication flow. This is work that requires holding the entire system model simultaneously — exactly where AI augmentation provides the greatest leverage.
"The vulnerability wasn't hidden. It was hiding in plain sight — too distributed across time and context for any single reviewer to assemble the complete picture."
The Regression Pattern
What makes regreSSHion especially instructive is the regression. The bug was introduced twice, fixed once, and the fix was undone by a change that didn't know about it. This is a pattern that should terrify anyone responsible for a long-lived codebase: the context that makes a change safe decays faster than the change itself. Git blame and commit messages help, but they require a human to know what to look for.
AI-assisted code review that maintains semantic understanding of why a change was made — not just what it changed — is the tool that could have caught this regression. The research direction now is toward AI systems that can track invariants across code history: flagging any change that violates a constraint established by a previous security fix, regardless of when that fix was made. This is a fundamentally different capability from current static analysis, and it's the capability that the regreSSHion class of vulnerability demands.