Page MenuHomePhabricator

CVE-2025-53498: AbuseFilter batch testing tool do not log when protected variables are in the test pattern
Closed, ResolvedPublicSecurity

Description

When using the AbuseFilter Special:AbuseFilter/test page, I can compare against the value of protected variables without creating a log entry. This allows me to work out the value of the variable by trial-and-error without logging that I viewed the value of the variable.

Steps to reproduce

  1. Setup ipoid locally
  2. Install the AbuseFilter and IPReputation extension on your local mediawiki environment
  3. Find an IP which your local ipoid knows about and simulate having that IP locally
  4. Make a few test edits either while logged out or using a temporary account
  5. Go to Special:AbuseFilter/test while logged in to an account with the checkuser and sysop groups
  6. In the Rules to test field, enter something like:
ip_reputation_client_count = 1
  1. Press the "Test" submit button at the bottom of the form

What happened
The Special page tells you which recent actions match against the filter conditions, such that you can know which actions have the client_count of 1 if they match the pattern. For example:

image.png (87×1 px, 33 KB)

What should have happened
The special page should have allowed this, but should have created a log entry indicating that the performer accessed the value of protected variables for the users in the results.

Acceptance criteria

  • The AbuseFilter Special:AbuseFilter/test page creates protected variable value access logs when the test pattern includes a protected variable and the RecentChange entry has the protected variable value defined (i.e. not null) - For example, this should create logs when using an MediaWiki-extensions-IPReputation variable using the steps above.

Event Timeline

Dreamy_Jazz renamed this task from AbuseFilter batch testing tools to not log when protected variables are in the test pattern to AbuseFilter batch testing tool to not log when protected variables are in the test pattern.Jun 17 2025, 3:31 PM
Dreamy_Jazz claimed this task.
Dreamy_Jazz added a project: AbuseFilter.
Dreamy_Jazz renamed this task from AbuseFilter batch testing tool to not log when protected variables are in the test pattern to AbuseFilter batch testing tool do not log when protected variables are in the test pattern.Jun 18 2025, 10:39 AM
Dreamy_Jazz added subscribers: dom_walden, Djackson-ctr.

(Removed comment, sorry, I thought this one had been deployed.)

This lgtm - tested it locally and confirmed that if I test a filter that uses protected variables, the hits are logged to the table as expected. Filters that don't do not.

Patch deployed.

Thanks, and thanks for adding this to the appropriate tracking tasks!

Calling Special:AbuseFilter/test with various abuse filter patterns, including those with protected variables, I checked that:

  • unauthorised users could not use patterns with protected variables
  • otherwise, any pattern which used a protected variable created an access log

A couple of things to note:

  • By default, recent changes that did not match the pattern are not returned. Nevertheless, access of those recent changes will still be logged. I think this makes sense: not matching a pattern tells you as much as matching it. But it might be confusing to users that a batch test which returns no results will still create access logs.
  • Access logs aren't made for recent changes whose protected variables are null. I didn't have a reliable way to determine this for every recent change, so this might affect the accuracy of the checks I performed above (i.e. I may have attributed a missing access log to protected variables being null when in fact they were not).
Jly renamed this task from AbuseFilter batch testing tool do not log when protected variables are in the test pattern to CVE-2025-53483: AbuseFilter batch testing tool do not log when protected variables are in the test pattern.Jun 30 2025, 7:23 PM
Jly renamed this task from CVE-2025-53483: AbuseFilter batch testing tool do not log when protected variables are in the test pattern to CVE-2025-53498: AbuseFilter batch testing tool do not log when protected variables are in the test pattern.Jun 30 2025, 7:26 PM

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

[mediawiki/extensions/AbuseFilter@master] SECURITY: Update AbuseFilterViewTestBatch to log protected vars access

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

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

[mediawiki/extensions/AbuseFilter@REL1_44] SECURITY: Update AbuseFilterViewTestBatch to log protected vars access

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

Change #1166853 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@REL1_44] SECURITY: Update AbuseFilterViewTestBatch to log protected vars access

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

Change #1166844 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] SECURITY: Update AbuseFilterViewTestBatch to log protected vars access

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

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Low.

I was initially confused and thought of a bug when I noticed that according to the logs I had viewed protected variables of experienced users, bots, or even sysops that never even triggered an abusefilter, or did it years ago. Eventually, I was able to reproduce it by using Special:AbuseFilter/test to test filter 785 against recent changes.

As I understand it, logs should only be generated when an entry has not null protected variables. I thought IPReputation variables such as ip_reputation_ipoid_known were only available for logged out users or during account creation.

Is this the intended behavior, or should I file a new bug report? You can see what I mean by inspecting the log on itwiki.

I was initially confused and thought of a bug when I noticed that according to the logs I had viewed protected variables of experienced users, bots, or even sysops that never even triggered an abusefilter, or did it years ago. Eventually, I was able to reproduce it by using Special:AbuseFilter/test to test filter 785 against recent changes.

As I understand it, logs should only be generated when an entry has not null protected variables. I thought IPReputation variables such as ip_reputation_ipoid_known were only available for logged out users or during account creation.

Is this the intended behavior, or should I file a new bug report? You can see what I mean by inspecting the log on itwiki.

When was this log created? We have made other changes to the logging code, so it's possible that this has already been fixed.

Additionally, it would be useful to link the specific log and log entry created when viewing it.

I was initially confused and thought of a bug when I noticed that according to the logs I had viewed protected variables of experienced users, bots, or even sysops that never even triggered an abusefilter, or did it years ago. Eventually, I was able to reproduce it by using Special:AbuseFilter/test to test filter 785 against recent changes.

As I understand it, logs should only be generated when an entry has not null protected variables. I thought IPReputation variables such as ip_reputation_ipoid_known were only available for logged out users or during account creation.

Is this the intended behavior, or should I file a new bug report? You can see what I mean by inspecting the log on itwiki.

I have found a specific example now. I was confused as to what you meant by "logs" because this task is specific to logging to Special:Log when someone looks at a Special:AbuseLog entry.

We specifically do set the MediaWiki-extensions-IPReputation AbuseFilter variables on account creation of named accounts when those accounts are created by themselves (i.e. not when another named user creates an account for someone else). This is an intended behaviour, so there is no need to file a bug report. https://www.mediawiki.org/wiki/Extension:IPReputation/AbuseFilter_variables#Where_can_I_use_these_variables contains more detail on when these variables are available for use.

I was initially confused and thought of a bug when I noticed that according to the logs I had viewed protected variables of experienced users, bots, or even sysops that never even triggered an abusefilter, or did it years ago. Eventually, I was able to reproduce it by using Special:AbuseFilter/test to test filter 785 against recent changes.

As I understand it, logs should only be generated when an entry has not null protected variables. I thought IPReputation variables such as ip_reputation_ipoid_known were only available for logged out users or during account creation.

Is this the intended behavior, or should I file a new bug report? You can see what I mean by inspecting the log on itwiki.

When was this log created? We have made other changes to the logging code, so it's possible that this has already been fixed.

Additionally, it would be useful to link the specific log and log entry created when viewing it.

A few hours ago: to reproduce it I used /test with filter 785 against recent changes and 50+ entries were created for experienced registered users (not temporary accounts nor account creations). I'm talking about "Abuse filter protected variables log".

I was initially confused and thought of a bug when I noticed that according to the logs I had viewed protected variables of experienced users, bots, or even sysops that never even triggered an abusefilter, or did it years ago. Eventually, I was able to reproduce it by using Special:AbuseFilter/test to test filter 785 against recent changes.

As I understand it, logs should only be generated when an entry has not null protected variables. I thought IPReputation variables such as ip_reputation_ipoid_known were only available for logged out users or during account creation.

Is this the intended behavior, or should I file a new bug report? You can see what I mean by inspecting the log on itwiki.

When was this log created? We have made other changes to the logging code, so it's possible that this has already been fixed.

Additionally, it would be useful to link the specific log and log entry created when viewing it.

A few hours ago: to reproduce it I used /test with filter 785 against recent changes and 50+ entries were created for experienced registered users (not temporary accounts nor account creations). I'm talking about "Abuse filter protected variables log".

Then I would recommend filing a new bug. I am not sure when we (the Product Safety and Integrity team) will have the time to look at this