@SomeRandomDeveloper do you know if the EmbedVideo extension Github links will be available publicly before we post the public supplemental release around the end of this month? Currently those links are not visible and when we send out the release, there is no way for users to get more information.

In T421273#12026135, @Mstyles wrote:

@SomeRandomDeveloper do you know if the EmbedVideo extension Github links will be available publicly before we post the public supplemental release around the end of this month? Currently those links are not visible and when we send out the release, there is no way for users to get more information.

I think the maintainer is waiting for Github to assign CVEs, which were requested yesterday. This usually only takes a few days, so I would expect the advisories to be published by the end of this week.

@Mstyles Should T418431 be added to the table here? I ask because I there seem to be missing some backports for other affected REL branches and this table might have made that easier to catch. Apologies if the exclusion was intentional (RedirectManager isn't in prod either, so presumably prod is not the criteria; and the other UrlShortener patch is listed in the table).

In T421273#12076087, @Krinkle wrote:

@Mstyles Should T418431 be added to the table here? I ask because I there seem to be missing some backports for other affected REL branches and this table might have made that easier to catch. Apologies if the exclusion was intentional (RedirectManager isn't in prod either, so presumably prod is not the criteria; and the other UrlShortener patch is listed in the table).

T418431 is already in the table, it's the 4th one down. What other backports are missing? The criteria to be included is any Mediawiki extension/skin even if it's not in WMF production. There are of course still exceptions. If there's anything else that should be here that's not, please let me know.

In T421273#12077052, @Mstyles wrote:

T418431 is already in the table, it's the 4th one down.

Apologies. I don't know how I missed it. I checked several times. My bad.

What other backports are missing?

All versions are affected, not just 1.46. The bug was not a recent regression.

What other backports are missing?

All versions are affected, not just 1.46. The bug was not a recent regression.

The backport only worked for 1.46, the other version had merge conflicts. It's our standard to not backport to branches with merge conflicts, however you are welcome to manually fix the merge conflicts and push up to Gerrit.

If it's not too late for that, maybe we could add T422774: CVE-2026-14363: Cargo Extension: SQLi in Special:Drilldown to the supplemental as well? Based on T422774#12019624 that seems to have been the intention originally, but it's not listed in this task yet

In T421273#12077052, @Mstyles wrote:

The criteria to be included is any Mediawiki extension/skin even if it's not in WMF production.

That are, of course, not included within the core/bundled security releases that @Reedy manages. Otherwise, these supplemental releases serve as a catch-all for any active/maintained extensions, skins, libraries, etc. directly related to MediaWiki. And for which various maintainers know to submit them to this task or PSI for inclusion in these releases.

In T421273#12077287, @Mstyles wrote:

It's our standard to not backport to branches with merge conflicts, however you are welcome to manually fix the merge conflicts and push up to Gerrit.

Yes, we make a best effort to at least land patches on master/main. And then any currently supported MediaWiki versions. But if the backports are non-trivial and/or the component uses a different branching structure or exhibits other oddities, we leave those to the actual maintainers of the codebases, which is a slightly different process from the core/bundled releases. I believe the general thinking here has always been that there tends to be a lot more variation and randomness, potentially, within many of the codebases that are included within the supplemental release, and that can end up being quite difficult to support.

In T421273#12078133, @Mstyles wrote:

Draft Email For Release - Please comment with any questions/concerns - otherwise this will be sent to the relevant mailing lists on July 6 2026

Subject: MediaWiki Extensions and Skins Security Release Supplement (1.43.9/1.44.6/1.45.4)
Greetings-

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

UrlShortener
+ (T418533, CVE-2026-13706) - UrlShortener extension url validation can be bypassed due to difference between php url parsing and WHATWG
https://gerrit.wikimedia.org/r/q/1275494

That link leads to the RedirectManager patch

RedirectManager
+ (T423826, CVE-2026-58518) - RedirectManager's API does not require a CSRF token
https://gerrit.wikimedia.org/r/q/Idd51e18479b32b7176b43ff74ca1c49d6bdd0628

That's a ProofreadPage patch (which I think was included in the last release?)

Cargo
+ (T424140, CVE-2026-58519) - Stored XSS through Cargo's map format
https://gerrit.wikimedia.org/r/c/1277612

UrlShortener
+ (T418431, CVE-2026-58520) - UrlShortener defaults to ineffective validation open to third-party redirects
https://gerrit.wikimedia.org/r/1306769

CentralAuth
+ (T422306, CVE-2026-58028) - Pretty-printed API output combined with centralauthtoken allows XSS with certain gadgets
https://gerrit.wikimedia.org/r/Idb42ab1cf685ef145b78701784909c590d758917

When clicking on this link I get a "Not Found" error

StructuredDiscussions
+ (T424285) - Flow ships Handlebars 3.0.0 with known security vulnerabilities. See https://security.snyk.io/package/npm/handlebars/3.0.0 for more details
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/1277782

This patch was not backported to any release branches, so is there even a point in announcing it?

Timeline
+ (T426631, CVE-2026-8857) - Full RCE using EasyTimeline Extension
https://gerrit.wikimedia.org/r/c/Ic2f3aa24922e6d44d063b76630cc888016ba4c74
https://gerrit.wikimedia.org/r/c/Ia19cbe8c80fa5a765abca68305254c15e817bfac

Both links are 404s for me

Timeline
+ (T427611, CVE-2026-58038) - Stored XSS through javascript URLs in SVGs generated by EasyTimeline
https://gerrit.wikimedia.org/r/c/Ia61203fcd4913ce97fd6c05ea908d3910c213ff6

404 as well

Maps
+ (GHSA-4h7g-5542-v3fc, CVE-2026-52854) - # Stored XSS through the overlays parameter in the display_map parser function

There's a "#" in front of the vulnerability description, I assume that's not intended?

https://github.com/ProfessionalWiki/Maps/security/advisories/GHSA-4h7g-5542-v3fc
https://github.com/ProfessionalWiki/Maps/commit/737a993fc2f40499e9bb22198fd1d56c25613806

Cargo
+ (T428274, CVE-2026-58521) - SQLi in Cargo extension via year range filter
https://gerrit.wikimedia.org/r/1298854

OAuth
+(T428324, CVE-2026-13707) - Session fixation attacks on improperly configured OAuth 1.0a tools
https://gerrit.wikimedia.org/r/q/Ife0b4bf16761c01bdb0e91a29f1fb94de380c73e

EmbedVideo (fork)
+(GHSA-c29q-5xm7-5p62, CVE-2026-55690) - Stored XSS via unsanitized service name in exception text
https://github.com/StarCitizenWiki/mediawiki-extensions-EmbedVideo/commit/9215564bf28a0ceb40be550a55ab78efc0accc56

EmbedVideo (fork)
+(GHSA-v65j-hff3-753c, CVE-2026-57440) - Stored XSS via malformed src url with $wgEmbedVideoRequireConsent disabled
https://github.com/StarCitizenWiki/mediawiki-extensions-EmbedVideo/commit/370156335b325bb81d14d89edf0a1f2643d50a84

EmbedVideo (fork)
+(GHSA-5c7p-g73q-rpg5, CVE-2026-55692) - Stored XSS via malformed src url with $wgEmbedVideoRequireConsent enabled
https://github.com/StarCitizenWiki/mediawiki-extensions-EmbedVideo/commit/370156335b325bb81d14d89edf0a1f2643d50a84

EmbedVideo (fork)
+(GHSA-7h5p-637f-jfr7, CVE-2026-55691) - Stored XSS via unsanitized class passed to template
https://github.com/StarCitizenWiki/mediawiki-extensions-EmbedVideo/commit/370156335b325bb81d14d89edf0a1f2643d50a84

There's a link to the advisory for the Maps vulnerability, but not for the EmbedVideo ones

WikiLambda
+(T428833, CVE-2026-58517) - Blocked users can create and edit WikiLambda objects
https://gerrit.wikimedia.org/r/1305376

This was not backported either and the extension is designed for use by Wikimedia only (T400500#11042550), so is there a point in announcing it?

Charts
+(T430548, CVE-2026-14358) - Stored XSS in Wikimedia Chart pie tooltip via Data:*.tab field title
https://gerrit.wikimedia.org/r/c/Ibdaa7c852ae83f562e84dddc9c96ad64e2152210

That's a 404 for me again

Cargo
+(T422774, CVE-2026-14363) - Cargo Extension: SQLi in Special:Drilldown
https://gerrit.wikimedia.org/r/c/1269701
https://gerrit.wikimedia.org/r/c/1279498

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]. CVE JSON references can be found on Gitlab [4].

[1] https://phabricator.wikimedia.org/T421273
[2] https://www.mediawiki.org/wiki/Version_lifecycle
[3] https://www.mediawiki.org/wiki/Reporting_security_bugs
[4] https://gitlab.wikimedia.org/repos/security/wikimedia-cve-assignments

@SomeRandomDeveloper everything should be addressed except for T424285 and T428833. Historically we have included extensions that are only used by WMF and only fixed in master/main.

In T421273#12078200, @Mstyles wrote:

@SomeRandomDeveloper everything should be addressed except for T424285 and T428833. Historically we have included extensions that are only used by WMF and only fixed in master/main.

Thanks, but unfortunately, the first two issues regarding UrlShortener and RedirectManager still seem to be present in the latest version of T421273#12078133

@SomeRandomDeveloper just got those as well

In T421273#12077287, @Mstyles wrote:

What other backports are missing?

All versions are affected, not just 1.46. The bug was not a recent regression.

The backport only worked for 1.46, the other version had merge conflicts. It's our standard to not backport to branches with merge conflicts, however you are welcome to manually fix the merge conflicts and push up to Gerrit.

I don't understand. Are you saying our security standard is defined by whether or not the lines of code nearby the bug happened to have some changed in the last 3 years? That's hard for consumers of software to reason about. Security support is usually measured in wall time or release time, like "3 years" or "2 LTS releases", not by whether the security issue was found in a function that has or hasn't had minor whitespace changes in the master branch at some point during the support window.

If I understand correctly, this means eventhough this current security issue will not be backported to REL1_43 for UrlShortener, the next security issue found in the future, might be backported again if it is found in a different file where the backport applies without needing to resolve minor merge conflicts.

May I have a link to where this is documented, so that I can read it in a bit more detail and potentially follow-up elsewhere?

@Mstyles - Email copy from T421273#12078133 LGTM. One question on the related CVE MR for you though.

In T421273#12080575, @Krinkle wrote:

I don't understand. Are you saying our security standard is defined by whether or not the lines of code nearby the bug happened to have some changed in the last 3 years? That's hard for consumers of software to reason about. Security support is usually measured in wall time or release time, like "3 years" or "2 LTS releases", not by whether the security issue was found in a function that has or hasn't had minor whitespace changes in the master branch at some point during the support window.

Perhaps usually, but not in this case.

If I understand correctly, this means eventhough this current security issue will not be backported to REL1_43 for UrlShortener, the next security issue found in the future, might be backported again if it is found in a different file where the backport applies without needing to resolve minor merge conflicts.

I went ahead and got some backports pushed up for T418431 for the remaining, supported release branches. While the initial conflict in the unit test was minor, there are now several failing tests and enough architectural dissimilarity within the REL1_43 branch that I would hesitate to dismiss all of these issues as "minor merge conflicts".

May I have a link to where this is documented, so that I can read it in a bit more detail and potentially follow-up elsewhere?

It's not documented anywhere; it's an internal process that we've had since we began issuing the supplemental releases. Prior to establishing the supplemental releases, there was little to no support for any issues that did not land within the core/bundled security releases. A best effort approach and "catch-all" release was seen as an improvement over that status quo. The Security-Team is always open to feedback via our usual channels: https://www.mediawiki.org/wiki/Product_Safety_and_Integrity#Connect_with_us and the #talk-to-safety-and-security channel on Wikimedia's Slack instance.

Email from T411394#11796980 has been sent to various mailing lists:

• wikitech-l
• mediawiki-l
• mediawiki-announce