An independent re-analysis by Goldberg Security Research of a publicly disclosed vulnerability: our breakdown of root cause, exploitation, and defence. Discovery credit belongs to the original researchers (see references).

Summary

regreSSHion is a pre-authentication remote code execution flaw in OpenSSH's sshd on glibc-based Linux, exploitable in the default configuration with no user interaction — and it runs as root. With ~14 million internet-exposed instances at disclosure, the potential blast radius was enormous, even though practical exploitation is hard.

Root cause — and the "regression"

The name says it: this is a regression. The underlying bug, an unsafe function reachable from a signal handler, was originally fixed years ago as CVE-2006-5051. A later code change (around 8.5p1) inadvertently reintroduced it. When a client doesn't authenticate within LoginGraceTime, sshd raises SIGALRM; its handler calls functions that are not async-signal-safe (e.g., logging paths that reach malloc/free). Interrupting the heap at the wrong moment corrupts state.

Exploitation

Winning the race turns that corruption into code execution as root. In practice it's difficult: the original research needed thousands of connection attempts (hours on 32-bit; harder on 64-bit) and is sensitive to ASLR and glibc specifics. It's a "hard but real" RCE — not a point-and-click, but absolutely worth patching urgently given the target.

Remediation

  • Upgrade OpenSSH to 9.8p1+ (or your distro's backported fix).
  • Interim mitigation: set LoginGraceTime 0 in sshd_config (note: this can enable connection-exhaustion DoS — a trade-off).
  • Restrict SSH exposure with network ACLs / bastion + key-only auth; don't leave sshd open to the whole internet.

Takeaway

Two durable lessons: signal handlers must only call async-signal-safe functions (a perennial footgun), and regressions are first-class risk — old, fixed bugs can silently return through refactors, so security regression tests matter as much as the original fix.

References