Introduced in https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1247186/

In T430563#12067454, @Dzahn wrote:

In T430563#12067105, @RhinosF1 wrote:

In T430563#12066949, @Dzahn wrote:

Does it cause a problem?

It indexing the wrong site is a problem, yes. It means those visting from search engines will get the replica domain.

But what's the actual problem with that?

I mean, as long as it works, they can use it, they can clone from it. And it tells them clearly what it is and where the main instance is. We are not trying to hide that it exists, generally.

If there is a specific tag though that marks it as canonical, yea, totally, that should be the main one.

I see a canonical tag on gitlab-replica-b, it should probably include gitlab.wikimedia.org instead of the replica domain

In T430563#12066949, @Dzahn wrote:

Does it cause a problem?

In T427398#11959982, @HakanIST wrote:

In T427398#11959873, @sbassett wrote:

Just to confirm: this does not appear to be affecting all wikis. When I try similar actions on enwiki, the reauth prompts work as expected for me.

That's because enwiki is still on 1.47.0-wmf.3. Once enwiki rolls to wmf.4, I believe it will break there too.

This feels like it should block the train from proceeding then

In T426631#11933491, @sbassett wrote:

In T426631#11932853, @Gaperlinski wrote:

Thanks for sharing the files here. Fandom engineering will apply this patch tomorrow.. Can you please hold off with applying the fix to the extension before that happens? Thanks1

@Gaperlinski @RhinosF1 et al - can you please confirm that when your teams deploy the ext:Timeline patches on this bug to your environments, that this will not be done publicly? We need to protect this security issue from disclosure until we are ready to make an official security release, which will not be in the near future.

I can confirm that the patches have been deployed through our private patches system and are not publicly accessible.

In T426631#11932830, @kostajh wrote:

In T426631#11932757, @taavi wrote:

How confident are we that this is the only issue of this type in the codebase?

02-T426631.patch4 KBDownload

follow up patch for additional hardening.

In T426631#11932702, @kostajh wrote:

01-T426631.patch4 KBDownload

cosmetic changes (filename, commit message) from previous version

@sbassett, (or anyone else) this is also deployed on Miraheze. If you plan to deploy any mitigations to Wikimedia, can you give me a ping on IRC or on task as this sounds potentially serious and I'd like to replicate whatever is done and minimise the chance of this being exploited after WMF deploy any fix. I also don't want to deploy anything like disabling the extension first and expose the fact there's an issue.

In T426511#11928162, @Rubenavbredroscaaevbre wrote:

De ce nu pot genera cont pagina de Wikipedia

Are you receiving a specific error?

In T425850#11905943, @Aklapper wrote:

Have you tried to contact Bing why Bing behaves this way?

I don't think that should be the responsibility of random Wikimedia's when this is a wider issue. Traffic should be capable of checking their own logs and seeing if there are Microsoft IPs with a bing UA being blocked.

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.