Well, in this case the fix is fairly trivial (adding root passwords, though thankfully that’s part of good systems policy 101), but in the general sense of what would have to be done - if there were an external service affected by a “0-day” vulnerability like this, without a fix, you’d have to lock it down as best you could:
- remove from public access entirely - if you can’t do this then
- lock down access to the bare minimum of IPs that should be able to access it, or
- otherwise harden the systems so that if they do become compromised, you can rebuild them easily while also
- ensuring that compromised systems have no further access to the internal network itself.
Of course, in the abstract most of that doesn’t mean much, and I can’t think of a remotely-exploitable issue that was so egregious you ever really got past step 2 above. Part of that, though, is because it’s been a long time since someone released information about a vulnerability like this into the wild that wasn’t done with responsible disclosure in mind in the first place.