Page MenuHomePhabricator

CVE-2025-32698: LogPager.php: Restriction enforcer functions do not correctly enforce suppression restrictions
Closed, ResolvedPublicSecurity

Description

includes/logging/LogPager.php currently contains checks in enforceActionRestrictions() and enforcePerformerRestrictions() that - when the user searching log events holds deletedhistory rights (but not suppression rights) - do not correctly filter out suppressed titles/performers from log results (reproduction steps below).

In the case of (e.g.) enforceActionRestrictions(), this appears to be because it adds an SQL condition to check whether the bitwise AND of the log_deleted column and LogPage::SUPPRESSED_ACTION is not equal to LogPage::SUPPRESSED_USER, when (to enforce the action restriction) it should be checking that the bitAnd() result is not equal to LogPage::SUPPRESSED_ACTION. (For enforcePerformerRestrictions(), it appears to be the same, but with LogPage::SUPPRESSED_ACTION & LogPage::SUPPRESSED_USER swapped around.)

Looking at 60aa90500668 & T188145, it seems like the LogPage::SUPPRESSED_USER on line 430 (as of that commit) should have been swapped with the LogPage::SUPPRESSED_ACTION on line 449 - it seems like that may have been inadvertently missed when that commit was made. I believe that swapping these two statements (on what are currently lines 526 & 543 of LogPager.php) would rectify this issue.


Steps to reproduce - suppressed performer

  1. Create a user account with the name Suppressible user name.
  2. While logged into that account, create a page with any title.
  3. Log out of that account and log into an account with suppressor rights.
  4. Delete the created page with the "Suppress data from administrators as well as others" box checked.
  5. Navigate to Special:Log?user=Suppressible_user_name, select all the log entries that appear, and click "Change visibility of selected log entries". Set the option labelled "Editor's username/IP address" to "Hidden" & set the option labelled "Suppress data from administrators as well as others" to "Suppress", and click "Apply to selected revisions".
  6. Log out of the account with suppressor rights, and log into an account with deletedhistory rights.
  7. Navigate to Special:Log?user=Suppressible_user_name.
    • MediaWiki returns log entries performed by this user that their username has been suppressed from, thus revealing the username that was suppressed from the returned log entries/revealing the user that performed these actions to a user who does not hold suppression rights.
      Suppressible_user_name log page (Admin view).png (901×1 px, 94 KB)
    • When logged-out (or logged into an account that does not hold deletedhistory rights), MediaWiki correctly filters out the log events with the log-suppressed performer.
      Suppressible_user_name log page (logged-out view).png (1×2 px, 233 KB)

Steps to reproduce - suppressed target

  1. While logged in as any user, create a page with the name Test page name 1.
  2. Log into an account with suppressor rights.
  3. Delete Test_page_name_1 with the "Suppress data from administrators as well as others" box checked.
  4. Navigate to Special:Log?page=Test_page_name_1, select the checkbox next to the creation log entry for Test page name 1, and click "Change visibility of selected log entries". Check the boxes labelled "Hide target and parameters" & "Suppress data from administrators as well as others", and click "Apply to selected revision".
  5. Log out of the account with suppressor rights, and log into an account with deletedhistory rights.
  6. Navigate to Special:Log?page=Test_page_name_1.
    • MediaWiki returns log events relating to this title that the title has been suppressed from, thus revealing the title that was suppressed from the returned log entries to a user who does not hold suppression rights.
      Test_page_name_1 log page (Admin view).png (949×1 px, 87 KB)
    • When logged-out (or logged into an account that does not hold deletedhistory rights), MediaWiki correctly filters out the log events with the log-suppressed title.
      Test_page_name_1 log page (logged-out view).png (1×2 px, 237 KB)

Event Timeline

matmarex subscribed.

Yep, you're right.

To summarize key points:

  • This bug allows users who can see deleted log entries, but who shouldn't be able to see suppressed data in log entries, to verify the existence of some suppressed data in log entries.
  • The cause is an incomplete fix for another security issue in 60aa90500668, which swapped constants in two places in the code but missed a third one.

This affects MediaWiki versions since 1.31. It's probably not a very severe issue in practice (I imagine log suppression is rare, abusing the information leak requires knowing or brute-forcing a suppressed username or page title, and we only leak information to users who already have some advanced permissions). I also reviewed other uses of bitAnd() in MediaWiki core and haven't found any similar mistakes.

Patch with the fix you suggested:

sbassett claimed this task.
sbassett triaged this task as Medium priority.
sbassett moved this task from Incoming to In Progress on the Security-Team board.
sbassett added subscribers: Jly, sbassett.

@Jly from the Security-Team will plan to review the above patch.

sbassett changed Author Affiliation from N/A to Wikimedia Communities.
sbassett changed Risk Rating from N/A to Medium.

Good catch, thanks for raising this. I can also replicate this and CR+1 on the patch. We will look to get this deployed

sbassett added a parent task: Restricted Task.

Do we know offhand how long this has been around for?

Looking at 60aa90500668 & T188145, it seems like the LogPage::SUPPRESSED_USER on line 430 (as of that commit) should have been swapped with the LogPage::SUPPRESSED_ACTION on line 449 - it seems like that may have been inadvertently missed when that commit was made. I believe that swapping these two statements (on what are currently lines 526 & 543 of LogPager.php) would rectify this issue.

Looks like patch is trivially applied to all branches. Marking as resolved for ease of tracking what is where.

Reedy renamed this task from LogPager.php: Restriction enforcer functions do not correctly enforce suppression restrictions to CVE-2025-32698: LogPager.php: Restriction enforcer functions do not correctly enforce suppression restrictions.Apr 9 2025, 12:57 PM

Change #1135769 had a related patch set uploaded (by Reedy; author: Bartosz Dziewoński):

[mediawiki/core@REL1_39] SECURITY: Fix log entry search revealing suppressed data to users with 'deletedhistory' rights

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

Change #1135774 had a related patch set uploaded (by Reedy; author: Bartosz Dziewoński):

[mediawiki/core@REL1_42] SECURITY: Fix log entry search revealing suppressed data to users with 'deletedhistory' rights

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

Change #1135782 had a related patch set uploaded (by Reedy; author: Bartosz Dziewoński):

[mediawiki/core@REL1_43] SECURITY: Fix log entry search revealing suppressed data to users with 'deletedhistory' rights

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

Change #1135769 merged by jenkins-bot:

[mediawiki/core@REL1_39] SECURITY: Fix log entry search revealing suppressed data to users with 'deletedhistory' rights

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

Change #1135774 merged by jenkins-bot:

[mediawiki/core@REL1_42] SECURITY: Fix log entry search revealing suppressed data to users with 'deletedhistory' rights

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

Change #1135793 had a related patch set uploaded (by Reedy; author: Bartosz Dziewoński):

[mediawiki/core@master] SECURITY: Fix log entry search revealing suppressed data to users with 'deletedhistory' rights

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

Change #1135782 merged by jenkins-bot:

[mediawiki/core@REL1_43] SECURITY: Fix log entry search revealing suppressed data to users with 'deletedhistory' rights

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

Change #1135793 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Fix log entry search revealing suppressed data to users with 'deletedhistory' rights

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

Now that the security release announcement has gone out, should this task be made public? (Apologies if this is already in the pipeline; I’m not sure what the timescales usually are for this sort of thing!)

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