Exposed SSH is still a patching problem with a name: CVE-2024-6387

In July 2024, Qualys published CVE-2024-6387, a race condition in OpenSSH’s server on many glibc-based Linux systems. The nickname, regreSSHion, did the job nicknames do: it made a patch Tuesday feel like a brand. Under the brand was a plainer fact. A service left on the open internet inherits every bug in that service, including the ones that are awkward to exploit and still unacceptable on a host that accepts administrative logins.

Qualys described the issue on July 1, 2024. Upstream OpenSSH shipped a fix in the 9.8 release. Distributions then shipped their own backports, which is why a banner that does not literally read 9.8 can still be patched, and a banner that shows an older number can still be vulnerable. The authoritative check is the distro advisory, not a guess from a version string grabbed off the internet. The National Vulnerability Database entry is the stable public index.

This briefing stops at that altitude on purpose. The race, the timing, and the conditions under which a researcher could demonstrate code execution are documented by the people who found it. Copying those details does not help an operator who needs to know whether port 22 on a forgotten image is still their problem. The impact statement is enough. A remote, unauthenticated attacker might be able to run code in the context of the SSH service, on affected and unpatched builds, if the race goes their way. Researchers described reliable exploitation as non-trivial. Non-trivial is not the same word as harmless. An exposed admin login that is unpatched is an emergency whether or not a particular lab has published a tidy demo.

Why it was still sitting there

OpenSSH is plumbing. Plumbing does not get a product owner. It gets a base image, a “temporary” debug port, an appliance nobody has logged into since the migration, and a jump host that was going to move behind a VPN in the next quarter. CVE-2024-6387 did not create those hosts. It addressed them by name.

The hosts that worry a defender are not the ones in the configuration-management dashboard with a green check. They are the ones the dashboard does not know about. Cloud accounts accumulate them. Acquisitions import them. A vendor ships an image with a service enabled because the installer needed it once. Two years later the image is a fleet, and the fleet’s idea of “current” is the day it was baked.

A race-condition bug in a daemon is also a communication problem. People hear “hard to exploit” and translate it to “not this week.” That translation is how a July advisory becomes an October surprise on a host that was never in the patch ring. Difficulty for a researcher in a lab is not a control. Exposure is the control you can actually count.

What to do, in order

Inventory first. You cannot patch a service you have not admitted is reachable. Look for SSH listening on internet-facing addresses, including addresses that belong to projects someone spun up with a credit card. The goal is a list with an owner next to each row, not a trophy scan.

Patch second, from the vendor or distribution advisory, including the backports that do not change the number you hoped to see. Reboot or restart when the advisory says the fix is not live until you do. Confirm the package version the advisory names, not the version in a slide from 2024.

Reduce the audience third. Administrative SSH does not need to greet the whole internet. A VPN, an identity-aware proxy, or a simple allow-list of office and bastion addresses turns a theoretical race into a bug that a stranger cannot reach. Prefer that over a folklore hardening guide. Turning off password authentication and disabling direct root login are ordinary hygiene. They are not a substitute for the patch, and they are not steps this desk needs to expand into a configuration manual. Your distro already has one.

Watch the image pipeline fourth. The next fleet will be baked from something. If that something is unpatched, you have scheduled the incident. Pin a rebuild to the advisory, not to a calendar quarter.

How to read the next CVE

The days after a famous CVE are loud. Proof-of-concept rumors travel faster than packages. A useful reading order is dull.

Start with exposure. Is the affected service reachable by people you do not already trust? A bug in a daemon bound to localhost on a single workstation is not the same work item as the same bug on a public address.

Then read the vendor advisory, not a screenshot of a social-media thread. Advisories say which builds, which configurations, and which fixed packages. They also say when the bug is only a crash, and when it is code execution. Believe the advisory over a nickname.

Then look at known-exploited lists if you have to rank work you cannot finish today. The CISA Known Exploited Vulnerabilities catalog is a public priority queue for flaws already being used, not a complete map of what matters. A bug can be urgent on your network before it is added, and a bug on the list can be irrelevant if you do not run the product. Use the list to break ties. Use your own exposure to decide.

Ignore, for operational purposes, anyone offering a guaranteed exploit in a reply thread. Patch the package. Shrink who can reach the port. Write down the owner. That is the whole lesson regreSSHion still has to teach, and it did not require the nickname.

This briefing describes the public impact of CVE-2024-6387 and how to prioritize a fix. It does not include exploit details.