CVE-2025-6589: With MultiBlocks enabled and a user who is suppressed via a MultiBlock, a user without 'hideuser' can see the hidden username in the BlockList
Closed, ResolvedPublicSecurity
Actions

Assigned To

Authored By

	Dreamy_Jazz
	Apr 8 2025, 11:52 AM

Description

When a user is blocked with a hideuser block on a wiki with MultiBlocks enabled, the Special:BlockList shows these blocks with the username redacted.

However, if a user with the block and not the hideuser right loads the page they can see "unblock" and "change block" links which show the hidden username in those URLs.

Steps to reproduce

Open Special:Block with MultiBlocks enabled and while logged in as a user who has the hideuser right
Add a block which is normal (does not hide the user)
Add a block which hides the username
Log in to a user who has the block right but not the hideuser right
Open Special:BlockList
Hover over either the "remove block" or "change block" action links for the block added in step 2

Additional notes

This does not seem to occur when MultiBlocks are not enabled, because only one block could exist.

Details

Risk Rating: Low
Author Affiliation: WMF Product

Related Changes in Gerrit:

Subject	Repo	Branch	Lines +/-
SECURITY: BlockList: Hide rows containing suppressed users	mediawiki/core	REL1_43	+46 -9
SECURITY: BlockList: Hide rows containing suppressed users	mediawiki/core	REL1_42	+46 -7
SECURITY: BlockList: Hide rows containing suppressed users	mediawiki/core	master	+46 -9
SECURITY: BlockList: Hide rows containing suppressed users	mediawiki/core	REL1_44	+46 -9

Customize query in gerrit

Related Objects
Search...

Status	Subtype	Assigned	Task
Resolved		Reedy	T389313 Formally EOL MW 1.42
			Restricted Task
			Restricted Task
Resolved	Release	jnuche	T392178 1.45.0-wmf.8 deployment blockers
Resolved	Security	tstarling	T391343 CVE-2025-6589: With MultiBlocks enabled and a user who is suppressed via a MultiBlock, a user without 'hideuser' can see the hidden username in the BlockList

Event Timeline

Dreamy_Jazz created this task.Apr 8 2025, 11:52 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 8 2025, 11:52 AM

Dreamy_Jazz renamed this task from With MultiBlocks enabled and a user who is suppressed via a MultiBlock, a user without `hideuser' to With MultiBlocks enabled and a user who is suppressed via a MultiBlock, a user without 'hideuser' can see the hidden username.Apr 8 2025, 11:59 AM

Dreamy_Jazz updated the task description. (Show Details)

Dreamy_Jazz added a project: Multiblocks.

Restricted Application added a project: Community-Tech. · View Herald TranscriptApr 8 2025, 11:59 AM

Dreamy_Jazz updated the task description. (Show Details)Apr 8 2025, 12:00 PM

kostajh added subscribers: MusikAnimal, dmaza, tstarling and 2 others.Apr 8 2025, 12:29 PM

sbassett added a project: Vuln-Infoleak.Apr 8 2025, 2:56 PM

Dreamy_Jazz renamed this task from With MultiBlocks enabled and a user who is suppressed via a MultiBlock, a user without 'hideuser' can see the hidden username to With MultiBlocks enabled and a user who is suppressed via a MultiBlock, a user without 'hideuser' can see the hidden username in the BlockList.Apr 8 2025, 4:38 PM

sbassett edited projects, added SecTeam-Processed; removed Security-Team.Apr 8 2025, 5:49 PM

Log in to a user who has the block right but not the hideuser right

@Dreamy_Jazz Could you share the exact permissions that the user had in your testing? Or which user groups?

On my local, I have a sysop account who is not a suppressor (meeting the criteria above), and I don't see a row for the hidden user at all at Special:BlockList.

MusikAnimal moved this task from Backlog to Actual multiblocks on the Multiblocks board.Apr 10 2025, 11:44 PM

MusikAnimal edited projects, added Multiblocks (Actual multiblocks); removed Multiblocks.

In T391343#10732030, @MusikAnimal wrote:

Log in to a user who has the block right but not the hideuser right

My user had the sysop group. I don't think it had anything that was for viewing suppressed content.

Okay I repro'd finally. Thanks!

MusikAnimal moved this task from Backlog - groomed to In Development on the Community-Tech (Sea Lion Squad) board.Apr 11 2025, 9:34 PM

For review:

T391343.patch3 KBDownload

MusikAnimal added a project: Patch-For-Review.Apr 12 2025, 2:11 AM

MusikAnimal added a subscriber: HMonroy.

In T391343#10735140, @MusikAnimal wrote:

For review:

T391343.patch3 KBDownload

CR+1, I guess this does affect at least a few production wikis, so we should deploy it as a security patch to Wikimedia production. We typically do that during the Monday afternoon (North America) security deployment windows. Would anyone be available to help test on an mwdebug or post-deployment?

In T391343#10740594, @sbassett wrote:

CR+1, I guess this does affect at least a few production wikis, so we should deploy it as a security patch to Wikimedia production. We typically do that during the Monday afternoon (North America) security deployment windows. Would anyone be available to help test on an mwdebug or post-deployment?

Yes, let's do it.

Looks like rMWa5372218b750: block: Deprecate and stop using $wgBlockTargetMigrationStage is likely to blame?

Reedy added a parent task: Restricted Task.Apr 14 2025, 9:55 PM

So, the patch caused some issues and was reverted during today's security deployment window.

Relevant logstash errors:

SAL entries:

T391343-v2.patch3 KBDownload

The original patch was only tested against SQLite. MySQL does not allow expressions in the WHERE clause to refer to aliases defined in the field list. So every request to Special:BlockList for a user without the hideuser right failed with an exception.

The test in the patch passed when it was run against MySQL, because it was not integrated with the database.

Patch v2 changes:

Put the hide user expression in the WHERE condition.
Wrote an integrated regression test

Manual tests done:

On master
Added another sitewide block to user that was already hidden
Set $wgGroupPermissions['sysop']['hideuser'] = false;
Confirmed the bug
Applied patch
Confirmed that the hidden user disappeared
Set $wgGroupPermissions['sysop']['hideuser'] = true;
Reload the page, confirmed that the hidden user was shown
Copied the query from the debug log for the hideuser=false case, ran it with EXPLAIN on production ruwiki and enwiki. Ran the query itself on enwiki.

Automated tests done:

phpcs
phan
Confirmed that the regression test fails against master
phpunit core only, MariaDB 10.11.8, PHP 8.1
phpunit with PHP 7.4

In T391343#10741869, @tstarling wrote:

T391343-v2.patch3 KBDownload

…

CR +1 from me, tested locally (on SQLite :)

Thanks for taking this over, Tim! I guess I need to get MariaDB installed.

MusikAnimal reassigned this task from MusikAnimal to tstarling.Apr 15 2025, 2:11 AM

T391969: Wikimedia\Rdbms\DBQueryError: Error 1054: Unknown column 'hu_deleted' in 'WHERE' Function: MediaWiki\Pager\IndexPager::buildQueryInfo (MediaWiki\Pager\BlockListPager) looks related to the logstash errors @sbassett mentions above..

In T391343#10743909, @TheresNoTime wrote:

T391969: Wikimedia\Rdbms\DBQueryError: Error 1054: Unknown column 'hu_deleted' in 'WHERE' Function: MediaWiki\Pager\IndexPager::buildQueryInfo (MediaWiki\Pager\BlockListPager) looks related to the logstash errors @sbassett mentions above..

Thanks, yes, that's almost certainly related. The re-deploy of the previous known good version went fine, according to scap, so I'm hoping this isn't like one k8 that didn't pick up the deployment or something.

Hey @MusikAnimal @tstarling @TheresNoTime - should we try to deploy Tim's updated patch during today's security window? Would anyone be around to help test in production or on an mwdebug? Thanks.

Deployed Tim's rev2 patch from T391343#10741869: https://sal.toolforge.org/log/NWZ8fpYBvg159pQrCdDz. Logs seem fine. Thanks for the production-testing, @tstarling!

sbassett changed the task status from Open to In Progress.Apr 28 2025, 10:24 PM

sbassett triaged this task as Low priority.

sbassett changed Author Affiliation from N/A to WMF Product.

sbassett changed Risk Rating from N/A to Low.

Is the patch backported to master yet? If so, I think this can be closed.

MSantos moved this task from Blocker to Not a blocker on the MW-1.44-release board.May 5 2025, 2:33 PM

In T391343#10789630, @MusikAnimal wrote:

Is the patch backported to master yet? If so, I think this can be closed.

No, per T391343#10741609, the task and patch should stay protected for now (not pushed to gerrit) since it will need to be a part of the upcoming security release (T389302).

MusikAnimal moved this task from Feedback and Review to Following on the Community-Tech (Sea Lion Squad) board.May 29 2025, 3:50 PM

Reedy added a subscriber: GerritBot.Jun 24 2025, 8:12 PM

Reedy closed this task as Resolved.Jun 24 2025, 8:26 PM

Reedy removed a project: Patch-For-Review.

Reedy renamed this task from With MultiBlocks enabled and a user who is suppressed via a MultiBlock, a user without 'hideuser' can see the hidden username in the BlockList to CVE-2025-6589: With MultiBlocks enabled and a user who is suppressed via a MultiBlock, a user without 'hideuser' can see the hidden username in the BlockList.Jun 24 2025, 11:26 PM

tstarling mentioned this in T397595: CVE-2025-6927: Autoblocks from global account suppressions are publicly visible.Jun 30 2025, 4:16 AM

Reedy added a project: MW-1.42-release.Jun 30 2025, 1:42 PM

Reedy edited subscribers, added: gerritbot; removed: GerritBot.

Change #1165070 had a related patch set uploaded (by Reedy; author: Tim Starling):

[mediawiki/core@REL1_43] SECURITY: BlockList: Hide rows containing suppressed users

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

gerritbot added a project: Patch-For-Review.Jun 30 2025, 6:04 PM

Change #1165096 had a related patch set uploaded (by Reedy; author: Tim Starling):

[mediawiki/core@REL1_44] SECURITY: BlockList: Hide rows containing suppressed users

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

Change #1165111 had a related patch set uploaded (by Reedy; author: Tim Starling):

[mediawiki/core@master] SECURITY: BlockList: Hide rows containing suppressed users

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

Change #1165096 merged by jenkins-bot:

[mediawiki/core@REL1_44] SECURITY: BlockList: Hide rows containing suppressed users

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

Change #1165137 had a related patch set uploaded (by Reedy; author: Tim Starling):

[mediawiki/core@REL1_42] SECURITY: BlockList: Hide rows containing suppressed users

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

Change #1165111 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: BlockList: Hide rows containing suppressed users

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

Change #1165137 merged by Reedy:

[mediawiki/core@REL1_42] SECURITY: BlockList: Hide rows containing suppressed users

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

Change #1165070 merged by Reedy:

[mediawiki/core@REL1_43] SECURITY: BlockList: Hide rows containing suppressed users

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

Reedy mentioned this in T398253: Partial backport of DatabaseBlockStore::insertBlockWithParams() to REL1_43.Jun 30 2025, 10:18 PM

Patch 04-T391343.patch is currently failing to apply for the most recent code in the mainline branch of core. This is blocking MediaWiki release 1.45.0-wmf.8(T392178)

If the patch needs to be rebased

To unblock the release, a new version of the patch can be placed at the right location in the deployment server with the following Scap command:

REVISED_PATCH=<path_to_revised_patch>
scap update-patch --message-body 'Rebase to solve merge conflicts with mainline code' /srv/patches/1.45.0-wmf.8/core/04-T391343.patch "$REVISED_PATCH"

If the patch has been made public

To unblock the release, the patch can be removed for the right version from the deployment server with the following Scap command:

scap remove-patch --message-body 'Remove patch already made public' /srv/patches/1.45.0-wmf.8/core/04-T391343.patch

(Note that if patches for the version don't exist yet, they will be created and the patch you specified removed)

Patch removed

sbassett lowered the priority of this task from Unbreak Now! to Low.Jul 8 2025, 9:05 PM

sbassett removed a project: Patch-For-Review.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".

sbassett changed the edit policy from "Custom Policy" to "All Users".

sbassett moved this task from Watching to Our Part Is Done on the Security-Team board.Jul 8 2025, 9:09 PM

	F59065606: T391343-v2.patch
	Apr 15 2025, 12:33 AM

	F59044755: T391343.patch
	Apr 11 2025, 9:59 PM

CVE-2025-6589: With MultiBlocks enabled and a user who is suppressed via a MultiBlock, a user without 'hideuser' can see the hidden username in the BlockListClosed, ResolvedPublicSecurityActions