If you run Linux servers — and let’s be honest, who among us doesn’t — you need to pay attention to CVE-2024-6387, disclosed this week by Qualys. Dubbed “regreSSHion,” this vulnerability is a signal handler race condition in OpenSSH’s server that can lead to unauthenticated remote code execution as root. Yes, you read that correctly. Unauthenticated. Root. On the thing that guards the front door to virtually every server on the internet.
What Makes regreSSHion Different#
We’ve seen OpenSSH vulnerabilities before, but this one carries a particular sting. The underlying bug is a regression of CVE-2006-5051, a vulnerability that was patched eighteen years ago. Somewhere along the way — specifically in OpenSSH 8.5p1, released in March 2021 — a code change accidentally reintroduced the vulnerable condition. The race condition sits in the SIGALRM handler during authentication timeout processing, where async-signal-unsafe functions like syslog() get called in a signal handler context.
For those of us who’ve written C for decades, signal handler safety is one of those lessons you learn early and respect forever. The list of async-signal-safe functions is deliberately short for a reason. When a signal handler calls malloc() or free() indirectly through logging functions, you’re playing with fire in the form of heap corruption.
The Scope of Exposure#
OpenSSH versions from 8.5p1 through 9.7p1 are affected if running on glibc-based Linux systems. That’s a lot of servers. Qualys identified approximately 14 million potentially vulnerable OpenSSH instances exposed to the internet through Shodan and Censys searches. The practical exploitation difficulty is non-trivial — the Qualys team reportedly needed around 10,000 connection attempts on average to win the race on a 32-bit system, and 64-bit exploitation with ASLR is considerably harder. But “hard to exploit” and “impossible to exploit” are very different things, especially when the payoff is root access.
The versions before 4.4p1 are also vulnerable unless they were patched for the original CVE-2006-5051. OpenBSD is explicitly not affected due to its secure signal handling mechanisms — something the OpenBSD team has quietly gotten right for years.
Patching and Mitigation#
OpenSSH 9.8p1, released on July 1, fixes the vulnerability. If you can’t patch immediately, setting LoginGraceTime 0 in your sshd_config eliminates the race condition by disabling the authentication timeout. The trade-off is that this makes your server susceptible to denial-of-service through connection exhaustion, as unauthenticated sessions will never time out. It’s not ideal, but it’s better than RCE.
For those running configuration management — Ansible, Puppet, Chef, or whatever your shop prefers — this is the moment where having automated patching pipelines pays for itself. I had our staging environments patched within two hours of the advisory going public, and production followed after a quick smoke test. If you’re still SSH-ing into boxes manually to run apt upgrade, I’d argue this CVE is your sign to invest in automation.
The Regression Problem#
What really gets me about regreSSHion isn’t the vulnerability itself — it’s the regression. We fixed this class of bug in 2006. Someone (and I’m not pointing fingers at any individual contributor) made a change in 2021 that undid that fix, and it took three years for anyone to catch it.
This is a systemic problem in software maintenance. Regression testing for security properties is genuinely hard. A unit test might verify that authentication works correctly, but how do you automatically test that a signal handler doesn’t call async-signal-unsafe functions? Static analysis tools can catch some of these patterns, but they generate enough false positives in large C codebases that findings get ignored.
I’ve been bitten by similar regressions in my own projects over the years, though thankfully never with stakes this high. The lesson I keep relearning: when you fix a security bug, write a comment explaining why the code must remain this way, and if possible, add a test that will scream if someone changes it.
My Take#
The OpenSSH project remains one of the most impressive pieces of security-critical open source software in existence. One regression in eighteen years, in software that runs on effectively every Linux server on the planet, is a remarkable track record. But this CVE is a reminder that even the best projects need more eyes, more static analysis, and more paranoia about regression.
If you’re a sysadmin or DevOps engineer reading this on a holiday week, I’m sorry — go patch your servers. If you’re a developer, take a moment to look at your own signal handling code. And if you’re running OpenSSH on OpenBSD, enjoy your long weekend.
Patch, verify, and update your inventories. This one matters.