In T422130#11781793, @1F616EMO wrote:

Should I expect the coming backport window be cancelled or delayed due to this incident?

Restoring subscribers

Restoring subscribers

As per the other 3, AI slop that wasn't even reported to the correct place.

In T419928#11705058, @RhinosF1 wrote:

Security issues with ManageWiki are not tracked on Wikimedia Phab. Please report this to https://issue-tracker.miraheze.org/maniphest/task/edit/form/2/

Not only is this reported to the wrong place, this is not a security issue in the slightest.

Security issues with ManageWiki are not tracked on Wikimedia Phab. Please report this to https://issue-tracker.miraheze.org/maniphest/task/edit/form/2/

Thank you :)

Thank you :)

I think this is what the open graph metadata is documented to do but it also seems a bit of a questionable UX and whether someone would expect it

In T363726#11487918, @Talhasajid849 wrote:

Thanks for the note!
I’ve added the Bug: T363726 line to the commit message and uploaded a new patch set.
Please let me know if anything else is needed.

You will need to address the CI failures. See the comment on your patch from Jenkins Bot.

In T363726#11487063, @Talhasajid849 wrote:

Update: I’ve implemented the Table of Contents for action=info pages and uploaded a patch to Gerrit.

The TOC is dynamically generated when multiple sections are present, inserted at the top of the page, and avoids duplication. This improves navigation and accessibility on longer Page information views.

Gerrit change:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1221669/

The patch is now awaiting review. I’m happy to address any feedback or follow-up improvements if needed.

In T413619#11487826, @Talhasajid849 wrote:

I submitted a Gerrit change updating the UploadWizard PD-US license year to 1931.

Patch: https://gerrit.wikimedia.org/r/1222270

In T400449#11457881, @Roger wrote:

GitLab account pending approval

I created a GitLab account using my Wikimedia Developer Account,
but my account is still pending approval and blocked.

Username: Roger

Allowing patch author / owner to update WIP/Active is probably worth upstream task too. Note to future me: https://www.gerritcodereview.com/issues.html

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