CVE-2024-6387: regreSSHion, when a patched bug comes back
July 30, 2026
Most advisories are about a new mistake. This one is more interesting: a bug that was fixed, and then quietly returned years later. regreSSHion is a useful teaching case because it shows that "we patched that" is a statement with an expiry date.
What it is
CVE-2024-6387, nicknamed regreSSHion, is a remote code execution flaw in OpenSSH's server, sshd. According to the OpenSSH release notes, "a critical vulnerability in sshd(8) was present in Openssh versions between 8.5p1 and 9.7p1," and a race condition in the signal handler could, on non-OpenBSD systems using glibc, lead to remote code execution as root.
The word "regression" is in the name for a reason. The underlying issue was originally fixed years earlier, then reintroduced in version 8.5p1 when an unrelated change removed the guard. So a codebase that had genuinely been safe became unsafe again, silently, through a refactor.
Who is affected
Affected: OpenSSH portable 8.5p1 up to, but not including, 9.8p1.
Fixed in: OpenSSH 9.8 / 9.8p1.
Very old releases (before 4.4p1) are also affected unless separately patched; the safe middle era was 4.4p1 through 8.5p1.
The flaw is a race condition, so exploitation is not trivial and takes many attempts, but "hard" is not "impossible," and the payoff is root.
The real lesson: regressions are a security event
The thing worth internalizing here is not the specific race. It is that a fixed vulnerability is not permanently fixed. Code changes. Guards get removed by someone who did not know why they were there. The defenses that catch this are process, not cleverness:
Regression tests for security fixes, not just features. When you patch a security bug, add a test that fails if the vulnerable behavior ever comes back. This is the single highest-leverage habit.
Periodic retesting, not one-and-done. This is why our security sprints end in a retest and why we recommend testing on a cadence: the thing you fixed last year is exactly the thing a refactor can un-fix.
Keep infrastructure current. A boring patch cadence on SSH, your web server, and your base images closes this whole class of issue before it reaches anyone's exploit toolkit.
What to do
Check your OpenSSH version (ssh -V) and update anything in the affected range. More broadly, if your team fixes security findings but has no test that proves they stay fixed, that gap is worth more of your attention than any single CVE. It is one of the first things we look for in a security assessment.
This advisory is an educational write-up of a public vulnerability, not a finding against any specific customer.