CentralAuth caches CentralAuthUser objects based on the md5 of the username. This can be a security risk because when you log in, MediaWiki can be convinced to log you in on one account, while checking the global account details (locked status, password, etc) of the other. Thus a vandal might be able to register two accounts, and as long as one of them stays unlocked they can still log in to the other one even after it is locked (however local blocks cannot be bypassed).

I experimented, and was able to get this to work on patch demo: This edit https://6484352b88.catalyst.wmcloud.org/w/index.php?title=Main_Page&diff=prev&oldid=143 was made by an account that was locked at the time.

Steps to reproduce

• Create two accounts that collide. You can use a tool like hashclash to generate them. If you need a pair for testing you can use TEXTCOLLBYfGiJUETHQ4hAcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak and TEXTCOLLBYfGiJUETHQ4hEcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak
  • As far as i am aware, ascii chosen prefix collisions (i.e. Where the two account names start with different text) are not yet viable for md5, but they would be ideal for an attacker to not be suspicious. As long as you are ok with the same prefix, the attacker does have a fair amount of control over the text of the collision, although at least part of it is going to look fairly random. When using off the shelf scripts, either the 21st, 85th, or 149th letter will have a difference of 4.
• Vandalize with the first one, get locked by steward
• Wait 24 hours or do something to flush cache (e.g. change password, email on second account)
• Do something to make second account loaded into cache (Special:CentralAuth is useful for this)
• Log in using username of first account but password of second
• Continue to make edits, they are attributed to first account name
• people try and lock it but they can't because they already locked it. Vandal continues vandalilizing forever (or until locally blocked)

From an attacker's perspective, the main limitation of course is having two weirdly named accounts with identical prefixes is going to be suspicious, and when one is locked stewards will likely notice the other. Nonetheless this seems like something that could cause a lot of confusion.

It also might result in some special pages returning incorrect results about the user. Special:CentralAuth is a good test bed because it uses the cached results on a GET but the DB results on a POST.

Suggested fix: Stop using md5 in CentralAuthUser::getCacheKey. md5 is always a bad choice. SHA-256 is almost the same speed due to cpus having special instructions. If you really care about speed use blake3 instead. If you extra care about speed and don't care about security i guess you can use murmur. If you're worried about length of hash you can truncate sha256. There is basically no valid reason to use md5 ever.