I wrote a patch for this ticket.

@Rxy - a couple of thoughts:

1. So this patch just prevents a Special:Redirect based upon the numerical of a hidden user, correct? I believe the User: pages of hidden users are still publicly-viewable if they exist (i.e. they don't display the error message.) The intention here is to throw an error if anyone tries to Special:Redirect to them, to prevent some information disclosure, correct?
2. I'm not sure the permissions error message makes sense within the context of a Special:Redirect:

You do not have permission to block a username, hiding it from the public...

as it seems to be more directed at users with that permission as opposed to someone trying to visit a redirect. I agree that's the right permission to check but I might recommend something like this for throwing a more relevant error message:

throw new ErrorPageError( 'badaccess-group0', 'badaccess-group0' );

Otherwise, I think this seems fine and I can security-deploy it whenever, though honestly I'd view this more as a hardening measure that could probably be done in gerrit.

1. Yes, It is correct. If who knew hideuser-ed user name, they can directly access to user page or they can check account existence via trying account creation. I guess no need to shown message . The patch is prevent leaks hideuser-ed account name who aren't know hideuser-ed account name by trying increase .

2. Here is Patch Set 2:

Thanks for reviewing.

PS2 looks good to me. I can try to deploy this later today or tomorrow, since there's no train this week.

I'm deploying this now through gerrit. Will make this task public once deployed.

Deployed. Making task public. Backports already started in gerrit:

1. https://gerrit.wikimedia.org/r/530440
2. https://gerrit.wikimedia.org/r/530441
3. https://gerrit.wikimedia.org/r/530443

(Tested: https://test.wikipedia.org/wiki/Special:Redirect/user/6159)

Change 530441 merged by jenkins-bot:
[mediawiki/core@REL1_32] SECURITY: Add permission check for suppressed account

https://gerrit.wikimedia.org/r/530441

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/530440/ needs another CR+2 to tell Jenkins to merge - original gate-and-submit failed verification

Change 530443 merged by jenkins-bot:
[mediawiki/core@REL1_33] SECURITY: Add permission check for suppressed account

https://gerrit.wikimedia.org/r/530443

Hmm, this is the second issue with revdel & Special:Redirect :( [The other one being T187638]. Guess we need to be careful with this page

Change 530440 merged by Jforrester:
[mediawiki/core@REL1_31] SECURITY: Add permission check for suppressed account

https://gerrit.wikimedia.org/r/530440

Is there anything further to do on this?

@Reedy - CVE requested. I'll post here when they send over the ID, then we can definitely resolve this task. Is there a specific date/time this week you were thinking about for the new release and announcements?

Update: CVE-2019-16738.

Why was this not held for the security release?

@Legoktm - I think there was some confusion on my part here as I had originally just done this as a code-hardening measure in gerrit (T230402#5416849) since it was some lightweight information disclosure, and for information findable in other ways via trivial User: namespace searches, our data dumps, etc. Then @Reedy mentioned getting a CVE for it in T225160, which I thought I'd just do for good measure. And we still aren't tracking this task on the current security release tracking bug: T225152. If we want to protect any security-related bug for core (and bundled extensions?) going forward, even low/info disclosure issues like this, then I can do that. Though we'd probably want to update our security release doc (1, 2) to emphasize this point or provide some basic guidance around what types of security patches should remain protected until an official security release.

This issue of the redirect is affecting my Mediawiki instance. I have updated my instance to MW 1.34.2 hoping that the fix would be automatic, but my user's information is still available with the Special:Redirect/user/# hack. I have searched for how to suppress users, but have so far been unable to figure it out. No where on this issue page have I seen the steps to resolve the issue, only that fixes were made to Mediawiki to somehow prevent this. Can someone point me in the right direction? I've been given until Oct 5 to resolve this vulnerability. Thanks in advance.

Per comment

Can someone test this in WMF prod/master?

I'm interested if this is still is replicable there... Or whether something regressed?

The REL1_34 patch would've been master at the time

In T230402#6483672, @Mitchell.brown.erdc wrote:

This issue of the redirect is affecting my Mediawiki instance. I have updated my instance to MW 1.34.2 hoping that the fix would be automatic, but my user's information is still available with the Special:Redirect/user/# hack. I have searched for how to suppress users, but have so far been unable to figure it out. No where on this issue page have I seen the steps to resolve the issue, only that fixes were made to Mediawiki to somehow prevent this. Can someone point me in the right direction? I've been given until Oct 5 to resolve this vulnerability. Thanks in advance.

Looks like I misread a bit. The code fixed the redirect, but you have to have suppressed/'hide' the users

The userright you need is , which isn't default assigned to the sysop group.

There is a 'suppress' group

# $wgGroupPermissions['sysop']['deletelogentry'] = true;
# $wgGroupPermissions['sysop']['deleterevision'] = true;
// To hide usernames from users and Sysops
$wgGroupPermissions['suppress']['hideuser'] = true;
// To hide revisions/log items from users and Sysops
$wgGroupPermissions['suppress']['suppressrevision'] = true;
// To view revisions/log items hidden from users and Sysops
$wgGroupPermissions['suppress']['viewsuppressed'] = true;
// For private suppression log access
$wgGroupPermissions['suppress']['suppressionlog'] = true;
// Basic rights for revision delete
$wgGroupPermissions['suppress']['deleterevision'] = true;
$wgGroupPermissions['suppress']['deletelogentry'] = true;

So it's that, or you need to do

$wgGroupPermissions['sysop']['hideuser'] = true;

Then, from memory, when you block, there is a check box to suppress/hide the username

See also https://www.mediawiki.org/wiki/Manual:User_rights

Also https://www.mediawiki.org/wiki/Help:Blocking_users

Hide username from edits and lists: When selected, the blocked username or IP address will not be added to the block log, the active block list, or the user list. Other users with the ability to view these hidden entries will still be able to see and unblock the username or IP address. This option is not enabled in a default installation of MediaWiki; the person putting the block in place must have the hideuser permission. See Manual:User rights.