Page MenuHomePhabricator

CVE-2026-34090: Suggested investigations: Handle suppressed usernames
Closed, ResolvedPublicSecurity

Description

Summary

SI currently displays suppressed usernames (e.g. https://en.wikipedia.org/wiki/Special:SuggestedInvestigations/detail/299174c9).

Acceptance criteria

  • Hidden usernames are hidden from users who do not have the right to see them in Special:SuggestedInvestigations

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Should we handle this like a security patch? IMO the risk is low given that:

  • This is really only used on WMF wikis
  • The users with access to this tool already have signed ANPDP

Given the lots of recent modifications, I'd propose to handle this publicly but merge and backport quickly

JJMC89 changed the subtype of this task from "Task" to "Security Issue".Dec 3 2025, 9:28 PM

The current approach in CheckuserLog is that suppressed usernames are struck out and italicized. That should probably be replicated here?

The current approach in CheckuserLog is that suppressed usernames are struck out and italicized. That should probably be replicated here?

Yes that would be the approach to take

sbassett subscribed.

Untagging Security-Team for now, once there's a patch ready, we can help deploy it and/or add it to the next supplemental core security release.

next supplemental security release.

CheckUser is a bundled extension, so AFAIK it would need to made in the main release

next supplemental security release.

CheckUser is a bundled extension, so AFAIK it would need to made in the main release

Ah, yes, it has been there since 1.44.

@sbassett thoughts on this comment? @kostajh has already said this is a okay way forward

Should we handle this like a security patch? IMO the risk is low given that:

  • This is really only used on WMF wikis
  • The users with access to this tool already have signed ANPDP

Given the lots of recent modifications, I'd propose to handle this publicly but merge and backport quickly

@sbassett thoughts on this comment? @kostajh has already said this is a okay way forward

Should we handle this like a security patch? IMO the risk is low given that:

  • This is really only used on WMF wikis
  • The users with access to this tool already have signed ANPDP

Given the lots of recent modifications, I'd propose to handle this publicly but merge and backport quickly

This sounds low-risk enough IMO to push up to gerrit with a timely Wikimedia production deployment.

The code has stabilised enough that I think we can use a normal security patch

Proposed patch:

CR+2

One non-blocking question, though:
Do we want the Investigate button to be enabled if all users in a case are hidden? In this situation, it's useless, as the current user cannot do anything about investigating the case. We don't have to do it right now, as it's not a security-related issue.

Should we add a isUserVisible() function in SuggestedInvestigationsCasesPager.php, would help avoid repeated code.

Will there be extra queries for every single user?

Should we add a isUserVisible() function in SuggestedInvestigationsCasesPager.php, would help avoid repeated code.

Given that this is a security patch, I'd want to avoid the possibility of merge conflicts. If we add a helper method it would increase the risk that a rebase is required if we were to add a helper method in a similar area.

Additionally, I think the logic is simple enough here that a helper method would likely add more lines of code overall?

Will there be extra queries for every single user?

Yes, but there is not a way to batch load this information in MediaWiki as it stands.

Given this is a security patch and is the method followed by all other CheckUser interfaces (and interfaces in core etc.), I'd want to avoid adding code likely to MediaWiki core as part of a security patch which could merge conflict, and instead improve it if we think it's needed once the patch is made public and we don't have to worry about merge conflicts

One non-blocking question, though:
Do we want the Investigate button to be enabled if all users in a case are hidden? In this situation, it's useless, as the current user cannot do anything about investigating the case. We don't have to do it right now, as it's not a security-related issue.

Perhaps, though maybe it's better to show it as disabled? We probably want to ask Design about the correct approach. Happy to leave it as-is if you think it's not blocking


Thanks for the code review (both Marcin and Maxim)

One non-blocking question, though:
Do we want the Investigate button to be enabled if all users in a case are hidden? In this situation, it's useless, as the current user cannot do anything about investigating the case. We don't have to do it right now, as it's not a security-related issue.

Perhaps, though maybe it's better to show it as disabled?

Yes, that was what I meant (that it's currently enabled and useless, so we might make it disabled).

One non-blocking question, though:
Do we want the Investigate button to be enabled if all users in a case are hidden? In this situation, it's useless, as the current user cannot do anything about investigating the case. We don't have to do it right now, as it's not a security-related issue.

Perhaps, though maybe it's better to show it as disabled?

Yes, that was what I meant (that it's currently enabled and useless, so we might make it disabled).

Ah, yeah. I think I misread your comment to remove the button entirely. Thanks

I've deployed the patch to production.

@sbassett the issue is present in release 1.45. I want to ask if we still can publicly upload the patch now given that, or if we should wait for a security release? I still believe the risk is low because I don't see anyone using this feature except for WMF wikis, but given that CheckUser is bundled I want to check

Actually I see that this was discussed already. I'm going to go forward with making the patch public and backporting

I have uploaded the fix publicly and backported it to release 1.45.

sbassett changed the task status from Open to In Progress.Feb 18 2026, 3:44 PM
sbassett triaged this task as Low priority.

I've deployed the patch to production.
...
I have uploaded the fix publicly and backported it to release 1.45.

Ok. No need to keep this bug private then. For reference:

@sbassett the issue is present in release 1.45. I want to ask if we still can publicly upload the patch now given that, or if we should wait for a security release? I still believe the risk is low because I don't see anyone using this feature except for WMF wikis, but given that CheckUser is bundled I want to check

CheckUser is bundled so we'd generally like to hold that for the primary security release. But I know it can be a volatile codebase and since this only landed in one release version, this was fine to do IMO.

sbassett changed Author Affiliation from N/A to WMF Product.Feb 18 2026, 3:48 PM
sbassett changed the visibility from "Custom Policy" to "Custom Policy".
sbassett changed the edit policy from "Custom Policy" to "Custom Policy".
sbassett changed Risk Rating from N/A to Low.
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett removed a subscriber: gerritbot.
sbassett added a subscriber: gerritbot.
sbassett added a parent task: Restricted Task.Feb 18 2026, 3:52 PM
dom_walden subscribed.

I see suppressed usernames are replaced with (username removed).

I have raised a follow up bug T417868 that we might want to look at.

Change #1240641 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/CheckUser@master] SI: Disable Special:Investigate action if all users hidden

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

Change #1240641 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] SI: Disable Special:Investigate action if all users hidden

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

SecurityPatchBot changed the task status from In Progress to Open.Feb 20 2026, 12:54 AM
SecurityPatchBot raised the priority of this task from Low to Unbreak Now!.
Patch is blocking upcoming release

Patch 01-T411366.patch is currently failing to apply for the most recent code in the mainline branch of extensions/CheckUser. This is blocking MediaWiki release 1.46.0-wmf.17(T413808)


If the patch needs to be rebased

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' /srv/patches/next/extensions/CheckUser/01-T411366.patch "$REVISED_PATCH"

If the patch has been made public

The patch can be dropped in the deployment server with the following Scap command:

scap remove-patch --message-body 'Dropping patch already made public' /srv/patches/next/extensions/CheckUser/01-T411366.patch
Dreamy_Jazz lowered the priority of this task from Unbreak Now! to Low.Feb 20 2026, 11:29 AM

If the patch has been made public

The patch can be dropped in the deployment server with the following Scap command:

scap remove-patch --message-body 'Dropping patch already made public' /srv/patches/next/extensions/CheckUser/01-T411366.patch

Ran this command on production, as we made the patch public

Reedy renamed this task from Suggested investigations: Handle suppressed usernames to CVE-2026-34096: Suggested investigations: Handle suppressed usernames.Wed, Mar 25, 7:20 PM
Reedy edited projects, added MW-1.45-release; removed Patch-For-Review.
Reedy renamed this task from CVE-2026-34096: Suggested investigations: Handle suppressed usernames to CVE-2026-34090: Suggested investigations: Handle suppressed usernames.Wed, Mar 25, 7:52 PM