I'm not saying this isn't an issue, but I do wonder how many of these containers that contain the backdoor can feasibly trigger it. Wouldn't you need to run OpenSSH in the container? It's not unheard of, but it's atypical.
Running OpenSSH in a container is highly atypical; doing it for anything other than a workload which specifically requires SSH (like, say, running a ssh+git server) is an indication that you may not be using containers appropriately.
While I do agree, I've definitely seen some container images that do actually intentionally export SSH for debugging, and run an init system. Personally, that goes against my sensibilities, but it's not a strictly invalid way to use Docker either, and Docker has a lot of weird features that would let you use it in really counter-intuitive ways (like using `commit` to save a mutated container's changes back to an image...) that don't match the typical container-oriented workflow.
But honestly, I kinda suspect in this case there's no real reason to argue over the (lack of) merits of exposing an SSH server from a Docker container, since there's really no evidence any of these images with the vulnerable package even contain OpenSSH, less a way for it to get executed and exposed...