Posted on gerrit - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EmailAuth/+/1286455

Any objections to posting this on Gerrit?

In T419152#11683994, @Krinkle wrote:

In T423537#11882752, @Tgr wrote:

This was fixed by explicitly checking for CentralAuthTokenSessionProvider, right?

Security issue access has been granted

Hooks have been removed from PrivateSettings.php - https://sal.toolforge.org/log/VHnwl50B1kByGTxA1dA8

Deployment plan (from @sbassett)

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

• wikitech-l
• mediawiki-l

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

@SomeRandomDeveloper yes agreed, T414227 has been removed

Security issue access granted

Security issue access granted

Security issue access granted

CVE/Backport Assignments

In T413229#11507530, @gmodena wrote:

In T413229#11497256, @sbassett wrote:

@gmodena - Sounds good. I still think we can push this review on our end to next quarter. I'm not concerned about the two options being run on test hosts, assuming those will be fairly locked down in Wikimedia production.

Terrific! Do you have specific requirements for what lock down measures are needed, or can we move forward and implement auth/blocklisting with SRE?

@abi_ thank you!

In T419192#11680990, @taavi wrote:

This is effectively the same bug as T235047: [Spike: 4 hours] RedirectSpecialPage not setting block cookies after redirect / {T320363}. ActionEntryPoint resolves the special page redirect, and creates a DerivativeRequest which is used in the Context passed to the action class. DerivativeRequest inherits FauxRequest and does not override response(), so the content-type headers and others set in RawAction have no effect.

Fixing this gets a bit complicated:

• My first thought was to override DerivativeRequest::response() to either return $this->base->response() (so the original object) or to add a method to allow a caller to explicitely override the response object. However, DerivativeRequest extends FauxRequest, and FauxRequest::response() is type-hinted as FauxResponse. Subclasses are not allowed to widen the return type, so DerivativeRequest::response() cannot return anything but a FauxResponse.
• So, at least for the initial security patch, we need to copy the headers from the faux response to the real one. Here's one that does it for the actions entry point only, although as the other tasks linked above indicate this is surely not the only place where it'll be required.

0001-SECURITY-Actions-Make-headers-set-after-redirect-act.patch2 KBDownload

In T419168#11729759, @SomeRandomDeveloper wrote:

Since nobody has come up with a better fix yet, and the next security release will likely happen soon, I think we should just fix this for now by calling destroy() on the engine object in destroyEngineForParser():

T419168.patch885 BDownload

@Pppery sorry for the markup issue, fixed now

Security access granted

I'll leave this open for a week for feedback/questions, but it's okay to just note the results since this is marked as low risk.

Security Review Summary - T411267 - 2026-Mar-06
Last commit reviewed: aa1f8b6

In T418254#11645995, @Daimona wrote:

Proposed patch:

T418254.patch1 KBDownload

This code was introduced in r1206829 (for T410374), on 2025-11-27. This is not part of any MW release, so it only needs to be fixed in master (no backports needed).

@Nikerabbit sorry I've been out sick but will post by tomorrow

In T418179#11642784, @SomeRandomDeveloper wrote:

T418179.patch4 KBDownload

Security access granted

In T416502#11585143, @sbassett wrote:

In T416502#11584441, @SomeRandomDeveloper wrote:

T416502.patch4 KBDownload

Patch looks fine to me. I think we can get this deployed to Wikimedia production during the ad-hoc security deployment window we have scheduled tomorrow (2026-02-04), after the late backport window.

@abi_ Great, I'll post the review by the end of February so you have plenty of time.

@abi_ Is this project still scheduled for deployment on Jan 31? I wanted to follow up on the timeline.

@Soda releases are at the end of every quarter. I don't think we have a formal calendar. But there are the tracking tickets (T411394 and T411384), and those should help.

@Samwilson we will wait until this is publicly announced in the supplemental release before pushing to Gerrit.

In T406088#11506153, @Samwilson wrote:

Here's a patch for removing the custom CSS output:

0003-T406088.patch3 KBDownload

In T410560#11497430, @Daimona wrote:

Yep, sorry everyone for the confusion. The current status here is that the patch needs code review, and I am re-linking it below for convenience:

T410560.patch5 KBDownload

However, I should also note that, holidays aside, the team is currently a bit understaffed and we aren't treating this as the #1 priority.

In T406088#11506153, @Samwilson wrote:

Here's a patch for removing the custom CSS output:

0003-T406088.patch3 KBDownload

In T410560#11497841, @Daimona wrote:

In T410560#11497707, @sbassett wrote:

In T410560#11497430, @Daimona wrote:

Yep, sorry everyone for the confusion. The current status here is that the patch needs code review, and I am re-linking it below for convenience:

However, I should also note that, holidays aside, the team is currently a bit understaffed and we aren't treating this as the #1 priority.

Ok. We'd really like to get something into the supplemental security release we're trying to get out by the end of this week. Should we use the current production patch instead? Or the updated patch with maybe a note that it isn't completely tested and isn't fully-supported at this time, or something like that?

Gotcha, I'll see what we can do then. If anything, I think including the production patch is fine.

Wikibase Extension
+ (T409737, CVE-2026-22710) - Stored XSS through autocomment system messages
https://gerrit.wikimedia.org/r/q/I8505700afda8096ef4e183280494232152767004

In T406088#11498249, @Samwilson wrote:

I think there are still a few to be migrated to /styles.css, and a few that are invalid and for which nothing need be done.

Then, the adding of the wayward <style> element on Page pages can be removed. We could probably leave the CSS field in place in the Index page form for a while after that, because once we remove it it isn't very easy for editors to view its contents.

@Urbanecm_WMF I'm not sure what's causing the failures. I'll take a look.

@SomeRandomDeveloper thank you and I see I used the wrong tag for gerrit, apologies!

In T409737#11444393, @Lucas_Werkmeister_WMDE wrote:

In T409737#11444135, @SomeRandomDeveloper wrote:

T409737-REL1_44.patch920 BDownload

Haven’t confirmed that it applies to the different branches but CR+1 for the patch contents – should be okay to try applying to the branches when the time comes.

@Samwilson @Soda I wanted to revisit this conversation so that we can decide next steps. From the comments it does look like the CSS migration is still possible. If it's not possible, what are our other options to address this vulnerability?

In T410560#11456249, @Daimona wrote:

Bah, I ended up doing this as a non-public fix. Don't ask me why :D I simply avoided injecting stuff to keep the diff minimal, and disabled a unit test that would otherwise fail. So, this is now ready for review:

T410560.patch5 KBDownload

(Note that this supersedes the currently-deployed patch from T410560#11400896)

CVE/Backport Assignments

@Urbanecm following up on this task in the new year