FYI - Beta scap is broken due to T411235: Beta cluster scap using php8.1 container; php8.2 is now required

Phabricator is a completely separate system with a separate authentication system.

In T397900#11068528, @Dreamy_Jazz wrote:

The second fix (the MediaWiki core one) seems to reduce many more logs than the other one (though both are still needed).

For example https://logstash.wikimedia.org/goto/1204feae3a5687f4dc1e81bc7fd37a3b shows all such warnings fixed by the second patch (2 million in the last week).

Therefore, we should probably also backport the fix to MediaWiki core as well to fix the logs for affects-Miraheze.

In T397900#11068574, @Dreamy_Jazz wrote:

There are also a million other such warnings in the last week, but these do not appear to be caused by us (instead the Vector (legacy skin) skin).

I guess that should be split off into another task then

I suspect it's similar to https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/3DNR7FALKHAU4L5ZUBRNP4Q4YWXLGABB/

In T389312#10972300, @RhinosF1 wrote:

In T389312#10969468, @sbassett wrote:

In T389312#10968698, @RhinosF1 wrote:

I'm extremely late adding them so if I'm too late then apologies but I added the 2 other ManageWiki CVEs that I forgot to add here

Since they are tracked outside of Phab/Gerrit and have CVEs assigned and merged patches already, it should be fairly trivial to include them for this release.

Thanks, I added the 5 CVEs from the last citizen release too. I'll try and think of a good way of tracking the ones we find that are from non-Wikimedia maintained extensions. It shouldn't be too difficult now both me and @Paladox have security access to create a Miraheze equivalent we can sync up to here close to the release for the next one. Obviously not sharing anything from here the other way around, just us sharing up to you.

T394869: CVE-2025-7056: Stored XSS through a system message in UrlShortener and T394612: CVE-2025-7057: Stored XSS through a system message in Extension:Quiz are WMF tracked and missing off the list too

In T389312#10969468, @sbassett wrote:

In T389312#10968698, @RhinosF1 wrote:

I'm extremely late adding them so if I'm too late then apologies but I added the 2 other ManageWiki CVEs that I forgot to add here

Since they are tracked outside of Phab/Gerrit and have CVEs assigned and merged patches already, it should be fairly trivial to include them for this release.

I'm extremely late adding them so if I'm too late then apologies but I added the 2 other ManageWiki CVEs that I forgot to add here

In T389312#10968398, @mmartorana wrote:

Subject: MediaWiki Extensions and Skins Security Release Supplement (1.39.13/1.42.7/1.43.2)

Greetings-

With the security/maintenance release of MediaWiki 1.39.13/1.42.7/1.43.2, we would also like to provide this supplementary announcement of MediaWiki extensions and skins with now-public Phabricator tasks, security patches and backports [1]:

ManageWiki
+ (https://github.com/miraheze/ManageWiki/security/advisories/GHSA-gg42-cv66-f5x7, CVE-2025-32956) - SQL injection vulnerability in NamespaceMigrationJob
https://github.com/miraheze/ManageWiki/commit/f504ed8eeb59b57ebb90f93cd44f23da4c5bc4c9

The Wikimedia Security Team recommends updating these extensions and/or skins to the current master branch or relevant, supported release branch [2] as soon as possible. Some of the referenced Phabricator tasks above _may_ still be private. Unfortunately, when security issues are reported, sometimes sensitive information is exposed and since Phabricator is historical, we cannot make these tasks public without exposing this sensitive information. If you have any additional questions or concerns regarding this update, please feel free to contact security@wikimedia.org or file a security task within Phabricator [3].

[1] https://phabricator.wikimedia.org/T389312
[2] https://www.mediawiki.org/wiki/Version_lifecycle
[3] https://www.mediawiki.org/wiki/Reporting_security_bugs

@rook used to be, I created https://github.com/toolforge/paws/pull/488

In T385811#10941537, @Aklapper wrote:

It's saddening to see this antipattern again after years of MediaViewer third-party misconfiguration issues (mis)filed in Wikimedia Phabricator due to hardcoding a Wikimedia URI in an extension that can also be used outside of Wikimedia.

There is already a task for this. I don't think it's a security issue or there's need to suppress IPs.

In T396413#10902085, @sbassett wrote:

In T396413#10902065, @Jdlrobson-WMF wrote:

...I would recommend quickly assessing whether there is any impact outside RelatedArticles before applying the fix and making this public.

We'd plan to deploy this as a security patch to Wikimedia production. We'd want to hold off on making it public in gerrit until the next supplemental security release.

Thanks all!

Slightly note of an interest, I saw a very similar pattern recently for Miraheze in our Cloudflare data so possible this affects for than the WMF. I can pull actual data later.

@KFrancis: can you start that?

In T394938#10860464, @sbassett wrote:

In T394938#10860312, @RhinosF1 wrote:

I removed it because it needed to be brought to security team's attention again because somehow the report in _security & via email was completely missed.

It's not for you to remove. Please do not do it again. There are other ways of contacting the Security-Team, as you've mentioned above. Both of which did receive replies as you have incorrectly noted here. Two on-call WMF staff members both correctly described this issue as low risk and not an immediate worry in #mediawiki_security, responding to @Urbanecm's message. That answer should absolutely have sufficed. I also replied to your email this morning and noted that the security team would be getting to these issues today during our clinic, which was delayed due to a Monday US holiday and an ongoing Wikimedia production incident. The Security-Team does not have unlimited resources nor do we guarantee 24/7 on-call services for every possible security-related issue.

There is still a process to follow though that security team are supposed to manage for WMF Deployed code. If this was a third party extension, we'd normally wait on task for your triage and for you to determine whether it's safe to be made public via a gerrit patch (and normally ensure that patch gets a speedy review). For a WMF Deployed Security issue, you guys are supposed to help us manage the private patch and deployment process to ensure WMF wikis are patched before the issue is exposed and normally would then release yourselves at security release time. This task has gone against the norm for reasons I'm not certain of but the lack of engagement is again embarrassing.

Processes are great when they are followed. That wasn't the case here and not due to the actions of anyone on the Security-Team. When incidents like this happen, people have to take out-of-process actions to correct the matter, which doesn't always happen perfectly and instantly.

As far as I can tell, _security was ignored. My email wasn't read. The patch was +2'd despite already being merged. This isn't an effective security release and someone needs to explain why again we're chasing the basics.

Most of this is incorrect as I mentioned above. I gave a quick +2 because from the comments on this task, it seemed like the patch hadn't been merged yet, nor cut for 1.45.0-wmf.3, both of which were incorrect. You're free to form your own opinions but I would advise not doing so on false assumptions and misinformation.

In T394938#10860243, @sbassett wrote:

Please don't remove SecTeam-Processed. That's an internal tag for the Security-Team's tracking.

I removed it because it needed to be brought to security team's attention again because somehow the report in _security & via email was completely missed.

This is already on 1.45.0-wmf.3, so at this point it just needs to ride the train the rest of the week to land in Wikimedia production. For most of these message XSS issues, we've traditionally considered them low risk since you'd need to compromise the MediaWiki message as well, which is non-trivial for unprivileged users.

Once a patch is up in gerrit, it can be backported by pretty much anyone. I can get those started now for supported release versions.

There is still a process to follow though that security team are supposed to manage for WMF Deployed code. If this was a third party extension, we'd normally wait on task for your triage and for you to determine whether it's safe to be made public via a gerrit patch (and normally ensure that patch gets a speedy review). For a WMF Deployed Security issue, you guys are supposed to help us manage the private patch and deployment process to ensure WMF wikis are patched before the issue is exposed and normally would then release yourselves at security release time. This task has gone against the norm for reasons I'm not certain of but the lack of engagement is again embarrassing.

In T394938#10860051, @sbassett wrote:

Untagging Security-Team as it looks like WMDE plans to review this? Since this extension is Wikimedia-production-deployed, please code-review on this task and do not push the patch to gerrit. Once reviewed, the Security-Team can assist with a Wikimedia production deployment.

A bit late for that one. As per my email to security-help and flag by @Urbanecm in _security on IRC, this has been public for 48 hours on gerrit and afaik not deployed to production.

04:32:28 <wmcs-alerts> FIRING: [2x] TargetDown: Job app is unreachable in project quarry instance quarry.wmcloud.org:443  - https://prometheus-alerts.wmcloud.org/?q=alertname%3DTargetDown
04:32:39 <wmcs-alerts> FIRING: QuarryDown: Quarry application is unreachable  - https://prometheus-alerts.wmcloud.org/?q=alertname%3DQuarryDown

In T394721#10850435, @cicalese wrote:

Please also do a version bump to 6.2.1 in extension.json in all patched branches that did not get a MW version bump and a version bump to 6.3.0 in all branches that got a MW version bump from 1.39.0 to 1.40.0. Thank you!

Hi Cindy, I don't think that's a normal part of the security patching process. If you want to follow up with a version bump, you're more than welcome to.

In T394708#10836144, @Aklapper wrote:

Wrong form/tags, see https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Policy/Access_To_Security_Issues :)

I followed https://wikitech.wikimedia.org/wiki/Volunteer_NDA because you need an NDA as part of getting security issue access

In T394383#10835762, @sbassett wrote:

Similar to my comment in T394612#10835735, the above patch should likely be pushed through gerrit since it isn't Wikimedia-deployed. Unless Miraheze would like to hold the patch until they've patched their production environments.

We're looking at this now, I also PM'd you on IRC a question.

In T392746#10770173, @sbassett wrote:

In T392746#10770064, @RhinosF1 wrote:

Does anyone have a problem if I deploy this patch to Miraheze too?

No problems with you all deploying, but please be extremely careful to avoid public disclosure of the issue and the patch at this time.

In T392746#10769959, @Dylsss wrote:

T392746.patch2 KBDownload

In T389312#10756586, @RhinosF1 wrote:

https://github.com/miraheze/ManageWiki/security/advisories/GHSA-gg42-cv66-f5x7 should probably be included

@sbassett: Thanks for adding the template. CVE is pending review and we'll issue through GitHub's CNA.

https://github.com/miraheze/ManageWiki/security/advisories/GHSA-gg42-cv66-f5x7 should probably be included

Feel free to email or ping me on IRC

In T54465#10739756, @sbassett wrote:

@cscott @ssastry - Per Roan's explanation in T54465#545525, I'm assuming this wasn't a very concerning issue to begin with, and is very likely irrelevant now? Unless an external operator does something extremely dangerous with their own config? If so, I'd love to decline this 11-year-old task.

@cscott: ping again as you had no view permissions before.

In T391750#10736770, @Chlod wrote:

Given that this affects Miraheze and that Miraheze runs 1.43, I assume this should also be backported to the REL1_43 branch for it to take effect there? I'm not 100% sure about how Miraheze deploys extension updates and backports, so some clarity would be appreciated here.

This wasn't needed for us anyway and we're probably not deploying the extension anyway. Closing.

Report originated from one of our wikis

In T382326#10735023, @sbassett wrote:

In T382326#10735013, @RhinosF1 wrote:

Given the entire email was the wrong version, I'd say it's probably a good idea to send out the correct supplement, yes.

Ugh, well, I just sent out a correction because I assumed the email content was at least correct :/

Nope, you'll notice in the email all the CVEs are CVE-2024-XXXX

Given the entire email was the wrong version, I'd say it's probably a good idea to send out the correct supplement, yes.

Email linked and sent is

MediaWiki Extensions and Skins Security Release Supplement (1.39.9/1.41.3/1.42.2)

NOT

Subject: MediaWiki Extensions and Skins Security Release Supplement (1.39.12/1.42.6/1.43.1)

In T390593#10695656, @Dzahn wrote:

Thank you! The service runs again.

regarding the API change: Maybe it could be reconsidered if renaming siteprop to prop (not sure it says why) is worth breaking it for all users of the API.

The third isn't of interested to me, we can change all wikis at once. I'd just like us to be able to plan it properly. The second kind of is because I'd love to use the SUL3 opportunity to get rid of the historical abomination that is using loginwiki for GlobalUserPage

Maybe we want to keep isSul3Enabled() and simplify it to a simple per-wiki yes/no flag, for third-party wikis, but I'm not sure we want to do even that much, rather than just assuming SUL3 is always enabled. Although we have to keep in it at least a few places in the code for at least a year because of API backwards compatibility (e.g. T364829: Update Wikimedia apps to use central login domain).

This is a content error and poses no security risk.

I think @Maintenance_bot will automatically remove the Patch for Review tag in this case.

15:31:32 <wmf-insecte> Yippee, build fixed!
15:31:33 <wmf-insecte> Project beta-update-databases-eqiad build #82385: FIXED in 11 min: https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/82385/

15:14:33 <@andrewbogott> RhinosF1: ok, I can't arm keyholder on that host with the scap password or the deploy-service password or the mwdeploy password