Closed, ResolvedPublicSecurity
Actions

Description

When using AbuseFilter to examine recent changes, I can see the IP Reputation variables even if I am logged out or logged in as a user without correct permissions.

Steps to reproduce

Setup ipoid locally
Install the AbuseFilter and IPReputation extension on your local mediawiki environment
On your local mediawiki install, go to Special:AbuseFilter/new
In the conditions field, enter something like

ip_reputation_tunnel_operators |
ip_reputation_risk_types |
ip_reputation_client_proxies |
ip_reputation_client_behaviors |
ip_reputation_client_count |
ip_reputation_ipoid_known

Find an IP which your local ipoid knows about and simulate having that IP locally
While logged out (or logged in as a temporary user) make an edit
Connect to the database of your wiki, execute SELECT rc_id FROM recentchanges ORDER BY rc_id DESC LIMIT 1;
Get the ID returned by the database query and, while still logged out, go to Special:AbuseFilter/examine/<rc id>

Details

Risk Rating: Medium
Author Affiliation: WMF Technology

Related Changes in Gerrit:

Subject	Repo	Branch	Lines +/-
SECURITY: Apply protected variable access restrictions on RC examine	mediawiki/extensions/AbuseFilter	REL1_43	+312 -44
SECURITY: Apply protected variable access restrictions on RC examine	mediawiki/extensions/AbuseFilter	master	+173 -1
SECURITY: Apply protected variable access restrictions on RC examine	mediawiki/extensions/AbuseFilter	REL1_44	+173 -1

Customize query in gerrit

Related Objects
Search...

Status	Subtype	Assigned	Task
			Restricted Task
Resolved		kostajh	T294511 2021 Security Team wikireplicas audit
Declined		None	T284948 Raw IPs of logged-out users disclosed in wiki-replicas
Resolved		Niharika	T324492 Temporary accounts - MVP
Resolved		kostajh	T357776 [Epic] Mitigate abilities to abuse temporary accounts
Stalled	Feature	None	T380917 Ability to configure a wiki to auto block open proxies
Stalled		None	T166817 Globally block identifiable open proxies
Resolved		Dreamy_Jazz	T354599 [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter
Resolved	Security	Dreamy_Jazz	T396750 CVE-2025-53495: Do not show IP Reputation AbuseFilter variables to those without permission in Special:AbuseFilter/examine/<rc id>

Event Timeline

dom_walden created this task.Jun 12 2025, 1:23 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 12 2025, 1:23 PM

dom_walden added projects: Trust and Safety Product Team, AbuseFilter, MediaWiki-extensions-IPReputation.Jun 12 2025, 1:25 PM

dom_walden added subscribers: Dreamy_Jazz, kostajh, Tchanders and 5 others.

kostajh added a project: Trust and Safety Product Sprint (Sprint Carrot Cake (May 26 - June 13)).Jun 12 2025, 3:01 PM

sbassett added projects: Vuln-Infoleak, Vuln-MissingAuthz.Jun 12 2025, 3:16 PM

It looks like we need to duplicate the logic used in showExaminerForLogEntry for showExaminerForRC. It would be nice if we could do this via a Gerrit change. There's one AbuseFilter making use of the new variables on nlwiki, though. In theory, someone could use Quarry to look up rc_ids and run these through Special:AbuseFilter, though this seems a bit far-fetched.

@XXBlackburnXx could you please disable https://nl.wikipedia.org/wiki/Speciaal:Filter/114 until we have pushed a fix for this issue? We should be able to do that early next week.

Johannnes89 subscribed.Jun 13 2025, 6:25 AM

In T396750#10911879, @kostajh wrote:

@XXBlackburnXx could you please disable https://nl.wikipedia.org/wiki/Speciaal:Filter/114 until we have pushed a fix for this issue? We should be able to do that early next week.

done.

XXBlackburnXx unsubscribed.Jun 13 2025, 11:44 AM

kostajh edited projects, added Trust and Safety Product Sprint (Sprint Baklava (June 16 - July 4)); removed Trust and Safety Product Sprint (Sprint Carrot Cake (May 26 - June 13)).Jun 16 2025, 6:14 AM

kostajh moved this task from Priority Backlog to Ready on the Trust and Safety Product Sprint (Sprint Baklava (June 16 - July 4)) board.

Dreamy_Jazz claimed this task.Jun 16 2025, 11:34 AM

sbassett moved this task from Incoming to Watching on the Security-Team board.Jun 16 2025, 4:19 PM

sbassett added a project: SecTeam-Processed.

Dreamy_Jazz added a parent task: T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter.Jun 17 2025, 9:02 AM

I think there may be also an issue with the abusefiltercheckmatch API in a similar way. I'll file that as a separate task to avoid overcomplicating this.

Proposed patch:

T396750.patch9 KBDownload

Filed T397196: CVE-2025-53499: AbuseFilter 'abusefiltercheckmatch' API does not check protected variable access restrictions for the other issue I found while fixing this one.

This lgtm - tested it locally and confirmed that:

my user w/access maintains access
my user w/o access can no longer see protected variables
logs correctly go to abuse filter's protected variables view log (as IP reputation variables don't get redirected to the CU temp accounts logs)

Dreamy_Jazz added a subscriber: Stashbot.Jun 19 2025, 4:24 PM

Patch for this has been deployed to wmf.6 (and wmf.5 in case of train rollback).

Dreamy_Jazz moved this task from Needs Review to Needs QA on the Trust and Safety Product Sprint (Sprint Baklava (June 16 - July 4)) board.Jun 19 2025, 4:35 PM

Dreamy_Jazz mentioned this in T389312: Write and send supplementary release announcement for extensions and skins with security patches (1.39.13/1.42.7/1.43.2).Jun 19 2025, 4:42 PM

Fix only needs backporting to REL1_43 and REL1_44, because protected filters did not exist before bf28dbce0e5084340cda84365e4ffe65f020124c which was first present in release 1.43.

In T396750#10912888, @XXBlackburnXx wrote:

In T396750#10911879, @kostajh wrote:

@XXBlackburnXx could you please disable https://nl.wikipedia.org/wiki/Speciaal:Filter/114 until we have pushed a fix for this issue? We should be able to do that early next week.

done.

@XXBlackburnXx You should be able to re-enable the filter now. Thanks for your patience!

In T396750#10932717, @Dreamy_Jazz wrote:

Patch for this has been deployed to wmf.6 (and wmf.5 in case of train rollback).

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

For a large number of AbuseFilter logs and recent changes on my local wiki, I tested visiting:

Special:AbuseLog/<log id
Special:AbuseFilter/examine/log/<log id>
Special:AbuseFilter/examine/<rc id>

and checking that:

no protected variables appear when the user does not have abusefilter-access-protected-vars
no protected variables appear if the filter is not protected (for abuse logs)
no protected variables appear for named users unless it is for a createaccount or autocreateaccount action
otherwise, accessing these protected variables is logged

kostajh closed this task as Resolved.Jun 27 2025, 9:44 AM

• Jly renamed this task from Do not show IP Reputation AbuseFilter variables to those without permission in Special:AbuseFilter/examine/<rc id> to CVE-2025-53485: Do not show IP Reputation AbuseFilter variables to those without permission in Special:AbuseFilter/examine/<rc id>.Jun 30 2025, 7:23 PM

• Jly renamed this task from CVE-2025-53485: Do not show IP Reputation AbuseFilter variables to those without permission in Special:AbuseFilter/examine/<rc id> to CVE-2025-53495: Do not show IP Reputation AbuseFilter variables to those without permission in Special:AbuseFilter/examine/<rc id>.Jun 30 2025, 7:26 PM

• Jly added a subscriber: gerritbot.Jul 2 2025, 11:48 PM

Change #1166040 had a related patch set uploaded (by Jly; author: Jly):

[mediawiki/extensions/AbuseFilter@master] SECURITY: Apply protected variable access restrictions on RC examine

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

Change #1166042 had a related patch set uploaded (by Jly; author: Jly):

[mediawiki/extensions/AbuseFilter@REL1_44] SECURITY: Apply protected variable access restrictions on RC examine

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

Change #1166043 had a related patch set uploaded (by Jly; author: Jly):

[mediawiki/extensions/AbuseFilter@REL1_43] SECURITY: Apply protected variable access restrictions on RC examine

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

Change #1166042 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@REL1_44] SECURITY: Apply protected variable access restrictions on RC examine

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

Change #1166040 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] SECURITY: Apply protected variable access restrictions on RC examine

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

Patch 01-T396750.patch is currently failing to apply for the most recent code in the mainline branch of extensions/AbuseFilter. This is blocking MediaWiki release 1.45.0-wmf.9(T392179)

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.9/extensions/AbuseFilter/01-T396750.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.9/extensions/AbuseFilter/01-T396750.patch

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

Patch removed from production as uploaded to the master branch.

Dreamy_Jazz removed a parent task: T392179: 1.45.0-wmf.9 deployment blockers.Jul 8 2025, 6:59 AM

sbassett changed Author Affiliation from N/A to WMF Technology.Jul 8 2025, 8:43 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 changed Risk Rating from N/A to Medium.

Change #1166043 abandoned by Dreamy Jazz:

[mediawiki/extensions/AbuseFilter@REL1_43] SECURITY: Apply protected variable access restrictions on RC examine

Reason:

We do not need to backport this to REL1_43 after all. This is because in REL1_43:
* The only protected variable was 'user_unnamed_ip' and you could not define additional variables via a hook
* The user_unnamed_ip variable in REL1_43 is not defined if generating the value for a RecentChange object (i.e. a past change)

Therefore, the variable displays nothing for RC examine and therefore there is no need to fix it in this version.

Fixing it in this version is technically possible but I don't think it's worth the effort given that you could never reproduce the problem unless the site admin defines additional protected variables.