CVE/Backport Assignments

Note: post your email-formatted updates as comments below (see previous email: T397776#11291485)

I think we can remove T414227 as it doesn't seem like it's going to be fixed in time.

@SomeRandomDeveloper yes agreed, T414227 has been removed

In T411394#11795826, @Mstyles wrote:

@SomeRandomDeveloper yes agreed, T414227 has been removed

Thanks!

ReportIncident
+ (T414582, CVE-2026-5762) - ReportIncident DiscussionTools integration causes slow requests with occasional timeouts on large talk pages
https://gerrit.wikimedia.org/r/q/I05d7f65c57d9aa1b70cdb159c4291ac28c60b4dd

ProofreadPage
+ (T406088, CVE-2026-39838) - ProofreadPage improperly sanitizes multiline styles using Sanitizer::checkCSS
https://gerrit.wikimedia.org/r/q/Idd51e18479b32b7176b43ff74ca1c49d6bdd0628

Cargo
+ (T416271, CVE-2026-39839) - Stored XSS through URLs in Cargo's map format
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cargo/+/1237957
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cargo/+/1237977

Cargo
+ (T416368, CVE-2026-39840) - CSS injection in multiple Cargo display formats
https://gerrit.wikimedia.org/r/c/1237966

Cargo
+ (T416389, CVE-2026-39841) - Stored XSS through list fields on Cargo's page values and Special:CargoTables
https://gerrit.wikimedia.org/r/c/1237973

Cargo
+ (T416402, CVE-2026-39837) - Stored XSS through the dynamic table format in Cargo
https://gerrit.wikimedia.org/r/c/1237979

WikiLove
+(T416502, CVE-2026-22711) - Stored XSS through system messages in WikiLove
https://gerrit.wikimedia.org/r/q/Iab86209478a044504f5a6aea0d8c3d14f21c48b3

CentralAuth
+(T418122, CVE-2026-39937) - Global vanishing does not completely remove user email
https://gerrit.wikimedia.org/r/q/I0b72427fa329aee85841a2cb23dec3058edce85e

GlobalWatchlist
+(T418179, CVE-2026-39933) - Multiple XSS vulnerabilities
https://gerrit.wikimedia.org/r/q/I1fc7b7e1d234b0aaf9f7d782a65da1451577587e

GrowthExperiments
+(T418222, CVE-2026-39934) - ReassignMenteesJob runs as an infinite loop
https://gerrit.wikimedia.org/r/c/1243874

CampaignEvents
+(T418254, CVE-2026-39935) - XSS-via-i18n in localised wiki names
https://gerrit.wikimedia.org/r/c/1249320

Score
+(T419186, CVE-2026-39936) - Stored XSS due to usage of non-reserved data attributes
https://gerrit.wikimedia.org/r/q/I1fb2913bc32328cbc4ecd4b4ad4a4788fb98c56c

RenderBlocking
+(GHSA-4h5r-8rjm-496r, CVE-2026-30977) - Stored XSS in renderblocking-css with Inline Assets mode
https://github.com/lihaohong6/RenderBlocking/commit/096fc47dad9dca153b02cba3db81f412c87fb2be

Notes regarding the above draft (does not necessarily mean that something is wrong, but that I thought it was worth noting/asking about):

• [...]we would also like to provide this supplementary announcement of MediaWiki extensions and skins with now-public Phabricator tasks, security patches and backports [1]: The link at [1] is to T368628: Write and send supplementary release announcement for extensions and skins with security patches (1.39.9/1.41.3/1.42.2), which seems like a task corresponding with a previous release/announcement from 2024 (unless there's something I'm missing).
• All of the referenced Phabricator tasks appear to now be public, except for T416502.
• +(T418179, CVE-2026-39933) - Multiple XSS vulnerabilities: for consistency with previous entries on this list, should this be suffixed with "in GlobalWatchlist" (ie., Multiple XSS vulnerabilities in GlobalWatchlist)?
• +(T418254, CVE-2026-39935) - XSS-via-i18n in localised wiki names: for consistency with a previous entry on this list, should this be described as "Stored XSS through system messages" or similar? (Just as otherwise this email may be using two terms for what (IIUC) is the same category of vulnerability.)

Non-exhaustive notes on the referenced CVEs:

• CVE-2026-39838 does not appear to list any affected versions of ProofreadPage -- its description just (in relevant part) says "This issue affects .", and the 'Product Status' information just appears to list 3 apparently-unaffected versions.
• Similarly, CVE-2026-39937 appears to only list 3 apparently-unaffected versions under 'Product Status', and its description says that "This issue affects non release branches" (which seems at first glance like it can't be true, given that the patch to MediaWiki-extensions-CentralAuth was backported to several release-branches).
• Same for CVE-2026-39933: The description says "This issue affects non release branches", and 'Product Status' appears to list 3 apparently-unaffected versions, but the patch to MediaWiki-extensions-GlobalWatchlist was backported to several release-branches.
• For CVE-2026-22711, under 'Product Status', there appear to be no affected versions listed: the default status is listed as 'unaffected', and the three version-numbers specified are also listed as 'unaffected'.
• Under 'Product Status' and/or in their CVE descriptions, CVE-2026-22711, CVE-2026-5762, CVE-2026-39934 & CVE-2026-39935 appear to list the affected versions as being 1.43.7, 1.44.4 & 1.45.2 (with the default status for other versions being 'unaffected'). Ignoring that these are arguably version-numbers for MW Core rather than for any extensions themselves, these version-numbers seem at a first-glance to be e.g. off-by-one/inversed: wouldn't the statuses as-of these releases be unaffected, now that the security patches have (I assume) been merged/backported in Gerrit?
• For CVE-2026-5762, the Phabricator link included under 'References' is to this tracking-task, rather than to T414582: CVE-2026-5762: ReportIncident DiscussionTools integration causes slow requests with occasional timeouts on large talk pages.

Other notes:

• According to the task description of T418222: CVE-2026-39934: With hidden mentees, ReassignMenteesJob runs as an infinite loop (if I'm reading/understanding it correctly), the issue described in that task may have been occurring since 2024. However, FWICS, that task's patch was only backported to wmf/ branches, and I can't see any discussion on that task regarding backporting to release-branches as well. So I guess I'm wondering whether a fix for that task should have been backported to release-branches (and I'm also wondering whether this might affect the accuracy of its current CVE).

Yeah, @Mstyles and @ASanford-WMF should be able to address these before we send out the emails.

In T411394#11798349, @A_smart_kitten wrote:

• [...]we would also like to provide this supplementary announcement of MediaWiki extensions and skins with now-public Phabricator tasks, security patches and backports [1]: The link at [1] is to T368628: Write and send supplementary release announcement for extensions and skins with security patches (1.39.9/1.41.3/1.42.2), which seems like a task corresponding with a previous release/announcement from 2024 (unless there's something I'm missing).

Yes, we just need to update the Phab bug to this task.

• All of the referenced Phabricator tasks appear to now be public, except for T416502.
• +(T418179, CVE-2026-39933) - Multiple XSS vulnerabilities: for consistency with previous entries on this list, should this be suffixed with "in GlobalWatchlist" (ie., Multiple XSS vulnerabilities in GlobalWatchlist)?

Now public.

• +(T418254, CVE-2026-39935) - XSS-via-i18n in localised wiki names: for consistency with a previous entry on this list, should this be described as "Stored XSS through system messages" or similar? (Just as otherwise this email may be using two terms for what (IIUC) is the same category of vulnerability.)

I updated the title a bit.

• CVE-2026-39838 does not appear to list any affected versions of ProofreadPage -- its description just (in relevant part) says "This issue affects .", and the 'Product Status' information just appears to list 3 apparently-unaffected versions.

@ASanford-WMF will address this via an update to the CVE. That can some time to process IME.

• Similarly, CVE-2026-39937 appears to only list 3 apparently-unaffected versions under 'Product Status', and its description says that "This issue affects non release branches" (which seems at first glance like it can't be true, given that the patch to MediaWiki-extensions-CentralAuth was backported to several release-branches).
• Same for CVE-2026-39933: The description says "This issue affects non release branches", and 'Product Status' appears to list 3 apparently-unaffected versions, but the patch to MediaWiki-extensions-GlobalWatchlist was backported to several release-branches.
• For CVE-2026-22711, under 'Product Status', there appear to be no affected versions listed: the default status is listed as 'unaffected', and the three version-numbers specified are also listed as 'unaffected'.

Yes, we'll likely want to update these CVEs as well.

• Under 'Product Status' and/or in their CVE descriptions, CVE-2026-22711, CVE-2026-5762, CVE-2026-39934 & CVE-2026-39935 appear to list the affected versions as being 1.43.7, 1.44.4 & 1.45.2 (with the default status for other versions being 'unaffected'). Ignoring that these are arguably version-numbers for MW Core rather than for any extensions themselves, these version-numbers seem at a first-glance to be e.g. off-by-one/inversed: wouldn't the statuses as-of these releases be unaffected, now that the security patches have (I assume) been merged/backported in Gerrit?

These might need the patch version reduced by one if we're implying that the issues exists in < the current patch versions for this release. Generally we assume/associate the same patch releases for core for any extensions, skins, etc. if they support MediaWiki's release branch structure.

• For CVE-2026-5762, the Phabricator link included under 'References' is to this tracking-task, rather than to T414582: CVE-2026-5762: ReportIncident DiscussionTools integration causes slow requests with occasional timeouts on large talk pages.

Yes, that will need to be updated.

• According to the task description of T418222: CVE-2026-39934: With hidden mentees, ReassignMenteesJob runs as an infinite loop (if I'm reading/understanding it correctly), the issue described in that task may have been occurring since 2024. However, FWICS, that task's patch was only backported to wmf/ branches, and I can't see any discussion on that task regarding backporting to release-branches as well. So I guess I'm wondering whether a fix for that task should have been backported to release-branches (and I'm also wondering whether this might affect the accuracy of its current CVE).

It's generally up to the maintainers of a given extension to fully support their backports. When the Security-Team does these releases, we make a best effort to get various security patches merged to master/main and supported release branches. But in cases like this, especially when it involves an extremely Wikimedia-specific extension, we often just ensure that the patch was merged to master/main and then defer to the component maintainers. If you have specific questions about why the patch didn't land on other release branches, I would advise you to direct them to the component maintainers, on that specific task.

In T411394#11800202, @sbassett wrote:

• According to the task description of T418222: CVE-2026-39934: With hidden mentees, ReassignMenteesJob runs as an infinite loop (if I'm reading/understanding it correctly), the issue described in that task may have been occurring since 2024. However, FWICS, that task's patch was only backported to wmf/ branches, and I can't see any discussion on that task regarding backporting to release-branches as well. So I guess I'm wondering whether a fix for that task should have been backported to release-branches (and I'm also wondering whether this might affect the accuracy of its current CVE).

It's generally up to the maintainers of a given extension to fully support their backports. When the Security-Team does these releases, we make a best effort to get various security patches merged to master/main and supported release branches. But in cases like this, especially when it involves an extremely Wikimedia-specific extension, we often just ensure that the patch was merged to master/main and then defer to the component maintainers.

Acknowledged :) But in that case, I guess that CVE-2026-39934 may want to be updated to be clearer that the issue has only been fixed in master, and not in any release-branches. (Unless there's something I'm missing or misunderstanding here.)

CVE-2026-39838 does not appear to list any affected versions of ProofreadPage -- its description just (in relevant part) says "This issue affects .", and the 'Product Status' information just appears to list 3 apparently-unaffected versions.

Fixed.

Under 'Product Status' and/or in their CVE descriptions, CVE-2026-22711, CVE-2026-5762, CVE-2026-39934 & CVE-2026-39935 appear to list the affected versions as being 1.43.7, 1.44.4 & 1.45.2 (with the default status for other versions being 'unaffected'). Ignoring that these are arguably version-numbers for MW Core rather than for any extensions themselves, these version-numbers seem at a first-glance to be e.g. off-by-one/inversed: wouldn't the statuses as-of these releases be unaffected, now that the security patches have (I assume) been merged/backported in Gerrit?

For CVE-2026-5762, it was not backported because of merge conflicts. I've clarified in the CVE description that it is only fixed on master.

For CVE-2026-5762, the Phabricator link included under 'References' is to this tracking-task

Fixed. Good catch!

mstyles opened https://gitlab.wikimedia.org/repos/security/wikimedia-cve-assignments/-/merge_requests/16

CVE JSON updates

mstyles merged https://gitlab.wikimedia.org/repos/security/wikimedia-cve-assignments/-/merge_requests/16

CVE JSON updates

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

• wikitech-l
• mediawiki-l

Having an issue with the mediawiki-announce email list, but as soon as I get that fixed, I will send it out there as well

In T411394#11802705, @Mstyles wrote:

Having an issue with the mediawiki-announce email list, but as soon as I get that fixed, I will send it out there as well

Yeah, something strange must have happened. I don't see the supp release email in any of mediawiki-announce's archives or held queue. Let me try to send it and see what happens.

Ok, that seems to have worked. My email made it into the held queue and I approved it (as an admin of mediawiki-announce-l). Here it is in the archives:

https://lists.wikimedia.org/hyperkitty/list/mediawiki-announce@lists.wikimedia.org/thread/VXEYKT6FNA5NYFPAYU67SNTNBXLTQ4FN/