This was fixed today.

dynamic-links appears to be used to create links (similarly to MediaWiki:Sidebar), so renaming that message would break the feature on all wikis using it.

In T409489#11358953, @Nikerabbit wrote:

Will the GitHub repository be marked read-only? In any case, we can start by removing the github config for now.

This needs a backport for 1.44: https://github.com/wikimedia/mediawiki-extensions-CommentStreams/blob/REL1_44/includes/Notifier/EchoNotifier.php#L175

To test whether this change breaks anything, I've run core's en.json through jqueryMsg both with and without my patch, and when comparing the two, there were no changes. Meanwhile, <br> and the other two tags now work fine for me.
Code for testing:

(function() {
  const jQueryParse = function(input, params) {
    mw.messages.set('foo', input);
    return mw.message('foo', params).parse();
  };
  $.getJSON("https://raw.githubusercontent.com/wikimedia/mediawiki/refs/heads/master/languages/i18n/en.json").done((data) => {
    delete data["@metadata"];
    const parsed = {};
    for (const [key, value] of Object.entries(data)) {
      parsed[key] = jQueryParse(value);
    }
    console.log(JSON.stringify(parsed));
  });
})();

"Mark as read" worked for me yesterday for some reason after it didn't work on Friday, but when I just opened phabricator again, I noticed I have a new unread notification I can't mark as read:

I just tried marking the notifications as read again and this time it worked for some reason. Note sure why that is, but at least I don't have any notifications anymore now

In T408337#11354486, @Yaron_Koren wrote:

Sure, that sounds good to me - let me know if you want me to do it.

@Yaron_Koren do you think we could backport this to 1.43-1.45? Since 1.45 has been cut already it would otherwise take a while for users (especially those using LTS versions) to receive this change

In T409554#11353875, @Dzahn wrote:

@SomeRandomDeveloper

When we check in the database (query in linked ticket) we see no unread notifications for you. Can you try clearing cache and deleting cookies or using a different browser and see if that makes it go away? It seems possible the state is ok in the database but not shown correctly to you locally.

In T409487#11351425, @Peachey88 wrote:

Has this been discussed with the current maintainer?

In T402076#11339572, @A_smart_kitten wrote:

In T402076#11308313, @SomeRandomDeveloper wrote:

That is indeed the wrong patch... unfortunately I think it's too late to undo this now from a security perspective, unless the message would be renamed along with its addition to wgRawHtmlMessages

Maybe I'm missing something (in which case I apologise!), but how come it'd be too late to undo? Couldn't e.g. there be a patch pushed to Gerrit which is effectively a combined (a) revert of F65758960 & (b) application of F65774953?

There are two solutions I can think of that do not disable the size formatting by default, but allow developers to increase the page load times by modifying a config option:

• Add a $wgDebugToolbarFormatSizes option which defaults to true but can be disabled in order to keep sizes unformatted.
• Add a $wgDebugToolbarDisabledTabs option which allows disabling the "PHP Includes" tab for developers who don't need it.

In T402076#11287276, @A_smart_kitten wrote:

In T402076#11094611, @Dreamy_Jazz wrote:

In T402076#11091418, @SomeRandomDeveloper wrote:

Patch:

T402076.patch2 KBDownload

+2

Works locally for me (I needed to restart my wiki to get the patch to work in case anyone else is testing this):

Question… which patch was +2ed here? Asking because the context of the comments prior to T402076#11094611 would suggest that it maybe might have been intended to be the second version of the patch (ie., the one uploaded in T402076#11093305); but this comment quotes the one that uploaded the first version of the patch — which is now also the one that's been merged in Gerrit.

In T356599#11228999, @kostajh wrote:

Marking as stalled until T405585: hCaptcha: Fix secure enclave loading in VisualEditor is done.

The CookieConsent security issue does not appear to have made it into an actual release, and therefore has no CVE. But it is still included here for completeness' sake.

In T397776#11296094, @sbassett wrote:

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

I assume this can be closed now since it was part of 1.44.2

In T397776#11290597, @Mstyles wrote:

AdvancedSearch
+ (T402146, CVE-2025-62662) - Stored XSS through a system message
https://gerrit.wikimedia.org/r/q/I91bba2b570643ef74e6c210e7250e05cd2aa388e

A minor issue, but it affected multiple system messages, not just one

The config option will be available in 1.45.

In T401099#11285042, @Lucas_Werkmeister_WMDE wrote:

T407617: The data HTML attribute name can't include the underscore sign anymore might be due to the fixes here? (Commenting here rather than on that task because this one isn’t public yet.)

In T401998#11089373, @ashley wrote:

The proposed solution looks good to me, but I'm no DB guru, so if it passes the usual "does it work?" type tests, it's good enough for me. ;-)

In T407164#11273604, @Yaron_Koren wrote:

@SomeRandomDeveloper - thanks for pointing this out; I believe this is fixed now.

TemplateStyles requires 6.0.0, so I assume you're running an outdated version (maybe the wrong branch?): https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/TemplateStyles/+/refs/heads/master/composer.json#4
It worked fine for me when I updated my local installation yesterday.

(Closing without the 1.43 backport per T392226#11278962)

I assume this can be closed now that the parser function has been available for everyone to use for a while.

In T316158#11275131, @kirb wrote:

Correct, it seemed it should be most likely to produce relevant results, and of course simpler to implement. Do you feel that should maybe use wgContentNamespaces, or something else?

@Yaron_Koren could you please fix CI for the extension or just force merge the patch? I would prefer not having unmerged SQLI patches on gerrit for multiple days, especially since most of your extensions use the master branch instead of release branches, so wiki admins installing this extension might clone the unfixed version

In T406519#11248208, @Bugreporter2 wrote:

Where is the community discussion and consensus about this?

Has the extension passed the security checks?

I fixed SpecialClearPendingReviews with

diff --git a/specials/SpecialClearPendingReviews.php b/specials/SpecialClearPendingReviews.php
index 60ee10f..4ab1ec4 100644
--- a/specials/SpecialClearPendingReviews.php
+++ b/specials/SpecialClearPendingReviews.php
@@ -115,13 +115,13 @@ class SpecialClearPendingReviews extends SpecialPage {

In T406380#11244232, @Yaron_Koren wrote:

@SomeRandomDeveloper - thank you for these patches. The one for master is not going through because of the recent removal of the cl_to field from the categorylinks table - which presumably is also preventing commits in something like 50 other extensions that use cl_to (including some of my own). I need to modify my extensions to not query cl_to - although if you want to try your hand at fixing WatchAnalytics, feel free. (The use of cl_to in WatchAnalytics seems more involved than in most of the others.)

(No backport for REL1_39 as that branch doesn't exist for this extension)

In T328254#11234910, @dancy wrote:

Since the error message mentions contentmodel a few times, and this ticket shows recent activity in this area, I thought I'd ask for help here. Can anyone tell what's going on?

I am going to create a revert patch. My reasoning:

• The parameter is now marked as @param-taint $buttonLabel exec_html since the fix for T402313
• All callers outside of HTMLButtonField escape the label already: https://codesearch.wmcloud.org/search/?q=HTMLButtonField%3A%3AbuildCodexComponent&files=&excludeFiles=&repos= (this was done to fix T402313, which is the same issue as reported here)
• There is another method call in HTMLButtonField, which passes the buttonLabel property to the function. This property is assigned in the following places:
  • L63: Parsed message
  • L67: String literal with a unicode character
  • L69: Escaped string
  • L72: Intentionally raw HTML string
  • L126: $this->getDefault(), which will be escaped again in that line after this patch is reverted

Suggested patch:

This needs to be backported to REL1_43 and REL1_39:

The fix for this has been merged to master, REL1_43 and REL1_44

Stored i18n XSS exposed by security patch for T402077

I keep forgetting that parameters aren't escaped either when using mw.msg... so that vulnerability was actually already present before

@Dreamy_Jazz actually couldn't we just escape the messages in the existing listToText method instead? The PHP version does the same: https://gerrit.wikimedia.org/g/mediawiki/core/+/ffd25a424f9fc8cbb32a403969e473da85c4389f/includes/language/Language.php#3665
And I don't think and, word-separator or comma-separator should contain any characters that would be double escaped

In T406322#11240755, @Dreamy_Jazz wrote:

In T406322#11240715, @SomeRandomDeveloper wrote:

I'm not sure what would be the best way to fix this, apart from copying mw.language.listToText into a new method in CheckUser and then escaping the messages so it can be used to produce HTML.

That seems hacky and would likely cause tech debt if the MediaWiki core version of mw.language.listToText is updated.

Could we not consider adding a XSS safe mw.language.listToText? AFAICS we would want to use it elsewhere that this issue might occur

This affects master and REL1_44.

I think it would be good if there was a template for the description similar to the bug report form. Most of my security reports usually follow this structure (unless there are multiple vulnerabilities in the same task):

1. A short description
2. Reproduction steps
3. Cause
4. Additional information (e.g. versions this was tested on)

As I mentioned on gerrit already, as far as I can see, $this->buttonLabel seems to either be parsed (L63), escaped (L69) or intentionally raw HTML (L72). It shouldn't be escaped in buildCodexComponent. Instead, it should be marked as exec_html and escaped by the caller, which https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1193175 (the fix for T402313) does already.

I think this is a duplicate of T402313 which has a separate fix that does not double escape messages.

(Rubber Duck Debugging)

Nevermind, I just realized that running UserStats:updateUserStats.php fixes it.

Downstream task: https://issue-tracker.miraheze.org/T14268

Special:AllComments was recently removed and entries in Special:Log/commentstreams don't point to comment pages anymore. Since the creation of this task, even less info is provided now.

In T400525#11215014, @sbassett wrote:

In T400525#11212330, @SomeRandomDeveloper wrote:

In T400525#11192254, @SomeRandomDeveloper wrote:

Since callbacks seem to not be supported by ResourceLoader in 1.39 (correct me if I'm wrong), I've made a separate patch that is mostly a band-aid fix and only supports HTTPS and HTTP. However, given that 1.39 will be EOL in December and I assume almost nobody has a reason to edit this message and insert a non-HTTP link, it should be fine to fix it this way:

T400525.patch2 KBDownload

@sbassett could we have somebody review this backport patch and then push it through gerrit?

CR+1, I can push it up to gerrit for REL1_39 in a minute.

In T388462#11221203, @freephile wrote:

In my 1.43 wiki, on a page with CommentStreams enabled, I get no errors, but also no output of the CommentStreams UI (button).

It turns out that this patch works for me - because I have

$wgCommentStreamsAllowedNamespaces = -1;

in my settings/config which is the subject of T404113