Blank password is not necessary. Any password provided on initial attempt WILL BECOME the root password. Blank is being circulated simply because that's what was discovered first.

Edit: Which also means it's possible to "secure" a vulnerable (unexploited) machine simply by attempting to log in as root with a long random password.

So by my logic - if you tried this exploit and it failed the first time, then worked the second time: No one else has tried it before you. Otherwise it would either have worked the first time (if you guessed the same pass) or not worked at all (if the first time it was tried a different pass was used).

Or is this not a permanent password set?

Well, I suppose if someone had exploited your system with this, they could probably install some remote access tool, and then disable the root account and unset the password, and remove all evidence they were there.

But, if you don't have Screen Sharing or Remote Management enabled and exposed to the WAN, you're probably safe unless someone untrusted had physical access.

It's hard to know how long this vulnerability was "known." The initial report on Nov 13th looks second hand, so it may have been circulating earlier.

If that's true (and certainly sounds plausible from what is known so far), that's a very valuable heuristic.

Not only enabled it but actually set an empty-string password. Usually the stored hash for a disabled account is not in the hash space, so it was either overwritten, or root account password was actually empty string out of the factory. That and the enabling of the account both point to debug code accidentally left in (or intentional backdoor by the disgruntled).

Login screen is probably already running as root in the first place, so it already had permission to enable shell/GUI access