It's worse than that. You're enabling the root user EVERY time you use this vulnerability. Even if you disable the root user in Directory Utility, logging in with root and no password will re-enable the root user.
And you might want to disable the root account again with `dsenableroot -d` as well, so that the root account stays disabled after the vulnerability is patched.
Unlike doing this through the GUI, this seems to retain the root password and prevent this vuln from re-occuring.
Bizarrely though, you can still use the root user (with the password that you set) to login to the Directory Utility even while it is supposed to be disabled... This behaviour seems super weird.
As far as I can tell, "dsenableroot -d" seems to have no useful effect. After having "* Successfully disabled root user." with it, I can still log in to the root account with the password I set, both at the command line with "login" and from a remote machine via screen sharing.
To be flippant, I might say HN discussions seem to QA using Apple methods.
I haven't upgraded to High Sierra yet and this doesn't happen on my install atm. Does adding a password to the root user stop this vulnerability? If it does then that seems way better than disabling the account until this is fixed.
Having tested this by both approaches (disabling through GUI & shell), the above (through shell) seems to prevent this from re-occurring when you attempt to perform this bogus login again. Disabling the account via the GUI causes the failure to re-occur.
It is disabled by default[1] (meaning you can't login as it), this vulnerability appears to enable the root user without setting a password. If the root user has already been enabled it doesn't work.
Anyone who does this should probably set a password for now and then disable the root user account once it has been patched.