Steps taken to reproduce:
- On one device/IP address, create two new accounts on metawiki, both with an email address linked to the account:
- Test-20250911-01
- Test-20250911-02
- While logged into Test-20250911-02 (as the legitimate account owner), navigate to https://aa.wikipedia.org/, and click the "Log in" button.
- On another device & IP address (now putting myself in the shoes of a malicious actor), login to the accounts as follows:
- Login to Test-20250911-01 on dewiki (not a member of the 'closed' dblist)
- This login is prompted for an EmailAuth code.
- Login to Test-20250911-02 on aawiki (which is a member of the 'closed' dblist)
- This login is not prompted for an EmailAuth code, but I can now use other (non-closed) SUL wikis while logged into this account (despite the fact that, had I used a non-closed wiki to login, I would have been prompted for such a code).
- Login to Test-20250911-01 on dewiki (not a member of the 'closed' dblist)
tl;dr: if an SUL account is attached to a closed wiki (which is public information via Special:CentralAuth), I believe that any applicable EmailAuth checks for that account can be bypassed by a malicious actor logging in via that closed wiki.
Someone else should probably check my working here, to ensure I haven't accidentally got this wrong, though.
My immediate thought is that this might be because MediaWiki-extensions-WikimediaEvents - which contains the EmailAuthHooks.php logic that decides whether or not to issue an email verification challenge - isn't loaded on wikis in the 'closed' dblist (xref T158721: Disable WikimediaEvents extension on closed wikis). [Noticing this is what prompted me to check for this vulnerability.]
If that is the cause, it's potentially another reason in favour of T401939: Create a Wikimedia* extension for site customizations (which I assume could/would be loaded on all Wikimedia wikis by default).
(FWIW, I believe the fact that I could reproduce this with brand-new accounts is somewhat related to T401640: ClosedWikiProvider stopped working; although fixing that bug wouldn't mitigate this issue for anyone that already has their SUL account attached to a closed wiki, AFAICS).