The root account always exists.

Playing around with disable/enable and the exploit: Root always has a /bin/sh shell "Disable root user" removes the ShadowHashData from the directory services entry for root The bug sets ShadowHashData to the hash of an empty string.

Now, ShadowHashData is a complex DS entry. I've never seen passwords represented this way in other OSX versions. I think this password storage format is new.

I strongly suspect the bug here is one related to OSX attempting to upgrade the password to the new storage format and when it does that, it inadvertently stores the password with a hash of null.

This should be very trivial for Apple to fix that (and thus "disable" the root user) by just removing any ShadowHashData that is solvable by an empty string.

Your comment suggests that it is related to users with older, pre-High Sierra directory entries. That is, upgraded rather than freshly installed machines that leave older, pre-ShadowHashData intact. Is this correct?

No, sorry, I did not mean that or mean to imply it.

I think the feature that caused this is related to upgrading pre-high-sierra user password hashes to high-sierra-style hashes.

The fact that it works for situations where the password is null is a/the bug.

Ah, yes, but that is what I meant in suggesting that it was related to a High Sierra upgrade.

If we assume that ShadowHashData hash was introduced in High Sierra, I thought it was safe to assume that a crypt hash would only origin from a pre-High Sierra install. Unless, of course, they are used as some form of default value (such as when disabling the user)...

No, I reproduced on freshly-installed High Sierra on two machines.

Odd. No reasonable amount of attempts would reproduce it on my wife's few-weeks-old work machine, where the root user was visibly disabled.

The factors that differed from my laptop, where it worked until I set a root password, as that her machine was a fresh install, and she is not admin (a managed machine).

Works with El Capitan too.