Page MenuHomePhabricator

CVE-2026-5762: ReportIncident DiscussionTools integration causes slow requests with occasional timeouts on large talk pages
Closed, ResolvedPublicSecurity

Description

Summary

The queries to validate the Incident-Reporting-System MediaWiki-extensions-CommunityConfiguration configuration is slow on pages with many DiscussionTools reply links, such as large user talk page archives

Background

  • The excimer profile is shown below (both left heavy and time order):

image.png (2,876×874 px, 166 KB)

image.png (2,560×1,162 px, 364 KB)

  • The issue is that the validation of the config seems to involve some kind of DB query that ends up being uncached and repeated for each DiscussionTools reply link

Steps to replicate the issue (include links if applicable):

  1. Open https://pt.wikipedia.org/wiki/Usu%C3%A1rio_Discuss%C3%A3o:K%C3%A1ssio_Santiago/arquivo01

What happens?:
The request takes a long time and may cause a RequestTimeoutException

What should have happened instead?:
The timeout should not happen and the page should load in a reasonable time

Event Timeline

Dreamy_Jazz updated the task description. (Show Details)
Dreamy_Jazz added a subscriber: STran.

We shouldn't be making DB calls in the validator. There is a suggestion to do it in a provider so that it's cached and doesn't happen more than once per request

At the moment it seems we repeat multiple DB calls per title we validate for each Reply tool button, which are not cached in PHP

Dreamy_Jazz set Security to Software security bug.Jan 14 2026, 2:42 PM
Dreamy_Jazz changed the visibility from "Public (No Login Required)" to "Custom Policy".
Dreamy_Jazz changed the subtype of this task from "Bug Report" to "Security Issue".

Potential DDoS vector - I've seen replica DBs lag due to the issue in logstash

STran added a subscriber: sbassett.

Patch is backported. cc @sbassett is it ok to make this task public? Thanks!

Patch is backported. cc @sbassett is it ok to make this task public? Thanks!

Sure. Was this issue only ever on master? If not, then we should try to backport to supported release branches as well where the bug was relevant.

master patch: https://gerrit.wikimedia.org/r/1226884

sbassett changed Author Affiliation from N/A to WMF Product.
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed Risk Rating from N/A to Low.

Sure. Was this issue only ever on master? If not, then we should try to backport to supported release branches as well where the bug was relevant.

master patch: https://gerrit.wikimedia.org/r/1226884

I'm unfamiliar with the Incident-Reporting-System code, but it looks like the function being modified by that patch may have been introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ReportIncident/+/1105680; ie., in (what's now) the REL1_44 branch.

Sure. Was this issue only ever on master? If not, then we should try to backport to supported release branches as well where the bug was relevant.

master patch: https://gerrit.wikimedia.org/r/1226884

I'm unfamiliar with the Incident-Reporting-System code, but it looks like the function being modified by that patch may have been introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ReportIncident/+/1105680; ie., in (what's now) the REL1_44 branch.

The issue was added in 7d6d26fcf6af093346e59b1c7c0756480f17f9d0 when uncached DB queries were added

The issue was added in 7d6d26fcf6af093346e59b1c7c0756480f17f9d0 when uncached DB queries were added

Ok, then that confirms it was only on master.

ASanford-WMF renamed this task from ReportIncident DiscussionTools integration causes slow requests with occasional timeouts on large talk pages to CVE-2026-5762: ReportIncident DiscussionTools integration causes slow requests with occasional timeouts on large talk pages.Apr 7 2026, 6:43 PM