This is a really interesting vulnerability, but *the Internet is not on fire.* Please read the actual advisory before spreading FUD. If you can’t understand the original advisory, please get someone to explain it to you. In short, the exploit has only been proven against x86 versions – NOT x64. That’s important because finding the right address to return to in x64 is exponentially harder in x64 than x86. This is definitely a “don’t delay patching” moment, but not a “OMG, get an outage window NOW” moment. Monitor for updates though, that could change (though highly unlikely IMO). This is also a great time to talk about zero trust. The foundational principle here is “deny all, permit by exception.” Most orgs don’t need SSH open to the whole Internet. Yes, ACLs are a pain to use. But you’re getting a lot back in security. That’s true for times like these, but it’s also makes credential compromises harder to meaningfully exploit. As an aside, if you can’t do IP ACLs for SSH (and everyone *can*, it’s just a question of overhead to maintain), consider changing the default port for SSH. In some testing, that’s dropped my failed login attempts by more than 95% (98%+ if you don’t make it something obvious like 2200, 2222, or 2022). Finally, let’s talk monitoring. It took @qualys researchers about a week to get a root shell. And that’s for the x86 version (which again, is infinitely easier to trigger than in x64). So even if you can’t just allow list a few IP addresses, you can for sure block list IPs that are hammering your server with ~10,000 exploit attempts. And before someone says “but Jake, what if they use a distributed network” – okay, but still block the obviously malicious IPs? Great work by the Qualys team. There aren’t many that can turn something like this into RCE – even in controlled environments.
Susan Bradley Patch Lady/Prudent patcher
