Page MenuHomePhabricator
Create Task
Maniphest T419192

CVE-2026-34095: action=raw with Special:Mypage subpage title responds with "Content-Type: text/html" on ctype=text/javascript request
Closed, ResolvedPublicSecurity
Actions

Assigned To
taavi
Authored By
Krinkle
Mar 6 2026, 1:41 AM
Tags
Referenced Files
F74853117: 0001-Actions-Fix-incorrect-variable-shadowing.patch
Thu, Apr 2, 10:03 PM
F72634387: 0001-SECURITY-Actions-Make-headers-set-after-redirect-act.patch
Mar 6 2026, 10:47 AM
F72628636: capture.png
Mar 6 2026, 1:50 AM
Subscribers
A_smart_kitten
Aklapper
Bawolff
gerritbot
Krinkle
matmarex
Mstyles
View All 14 Subscribers

Description

Steps to replicate the issue

https://commons.wikimedia.org/w/index.php?title=Special:MyPage/common.js&action=raw&ctype=text/javascript

What happens?:

The source code is rendered by the browser as arbitrary HTML.

What should have happened instead?:

Served as plain text like this URL does, for the same content:

https://commons.wikimedia.org/w/index.php?title=User:Krinkle/common.js&action=raw&ctype=text/javascript

We go through great lengths in MediaWiki to make sure our endpoints do not allow serving of arbitrary HTML. For example we set X-Content-Type-Options: nosniff, and we carefully escape any free-form text in api.php and rest.php responses that use JSON format to ensure no HTML-like tags are served as-is but rather use redundant slash escaping to prevent looking like HTML.

Other information

During today's worm accident (T419137), there was briefly talk in the #technical channel unofficial Discord about how to workaround the temporary user script disablement by using a Tampermonkey (GreaseMonkey) script. User:Sportzpikachu shared an approach that involved fetching https://en.wikipedia.org/w/index.php?title=Special:MyPage/common.js&action=raw&ctype=text/javascript and eval'ing its contents.

I would have thought such title is invalid for this entrypoint, but to my surprise it worked. And moreover, I noticed we respond with a text/html content type instead of the requested text/javascript. The workaround wasn't affected by that bug, because it didn't rely on the content type header and treated the response as plain text.

See also:

Details

Risk Rating
High
Author Affiliation
WMF Technology
Related Changes in Gerrit:
SubjectRepoBranchLines +/-
Actions: Fix incorrect variable shadowingmediawiki/coreREL1_43+3 -3
Actions: Fix incorrect variable shadowingmediawiki/coreREL1_45+3 -3
Actions: Fix incorrect variable shadowingmediawiki/coreREL1_44+3 -3
Actions: Fix incorrect variable shadowingmediawiki/coremaster+3 -3
SECURITY: Actions: Make headers set after redirect actually applymediawiki/coremaster+19 -0
SECURITY: Actions: Make headers set after redirect actually applymediawiki/coreREL1_43+19 -0
SECURITY: Actions: Make headers set after redirect actually applymediawiki/coreREL1_44+19 -0
SECURITY: Actions: Make headers set after redirect actually applymediawiki/coreREL1_45+19 -0
Customize query in gerrit

Related Objects
Search...

Event Timeline

Krinkle created this task.Mar 6 2026, 1:41 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 6 2026, 1:41 AM
Krinkle set Security to Software security bug.Mar 6 2026, 1:42 AM
Krinkle added projects: Security, Security-Team.
Krinkle changed the visibility from "Public (No Login Required)" to "Custom Policy".
Krinkle changed the subtype of this task from "Feature Request" to "Security Issue".
Zabe subscribed.Mar 6 2026, 1:44 AM
Krinkle added a comment.EditedMar 6 2026, 1:50 AM

Isolated example:

capture.png (676×980 px, 29 KB)

On the one hand, exploit seems trivial because you only need to send someone a link to a seemingly-trustworthy domain where they are logged-in and you can do anything with their session and with arbitrary JavaScript.

On the other hand, it requires the payload to exist under their User-page (receiver, not attacker). This makes it non-trivial to mount. But, someone may have all sorts of junk stored under their User-page, and given that those revisions were never intended to be interpreted as raw HTML, one could find or match potential victims. And, it could be combined with social engineering where you indirectly convince or cause someone to store something that will seem innocent on its own.

Krinkle updated the task description. (Show Details)Mar 6 2026, 1:59 AM
Bawolff subscribed.Mar 6 2026, 2:38 AM

Seems like this works on non-js pages as well, so anyone can just edit the target's user space to add something evil and then trick them into clicking the link.

For example: https://test.wikipedia.org/w/index.php?title=Special:Mypage/test&action=raw returns a text/html mime type for the raw text of that page

Bawolff awarded a token.Mar 6 2026, 2:38 AM
Krinkle triaged this task as High priority.EditedMar 6 2026, 2:43 AM

Aye, that makes it urgent, because while JS subpages are protected (owner and admins), regular subpages are freely editable.

Novem_Linguae subscribed.Mar 6 2026, 4:55 AM
taavi added a project: 2026-user-javascript-incident.Mar 6 2026, 9:35 AM
taavi subscribed.
taavi added a comment.Mar 6 2026, 10:47 AM

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

• Tgr subscribed.Mar 9 2026, 12:17 PM

See also T419273: Limit the forwarding actions for Special:Random although you'd need a wiki to be extremely tiny for that to be a useful attack vector.

sbassett moved this task from Incoming to In Progress on the Security-Team board.Mar 9 2026, 5:52 PM
sbassett added projects: SecTeam-Processed, Vuln-Misconfiguration.
Catrope moved this task from Backlog to Q3 on the 2026-user-javascript-incident board.Wed, Mar 18, 4:53 PM
MLechvien-WMF added a project: Sustainability (Incident Followup).Thu, Mar 19, 11:42 AM
Catrope assigned this task to sbassett.Thu, Mar 19, 4:42 PM
sbassett moved this task from In Progress to Security Patch To Deploy on the Security-Team board.EditedFri, Mar 20, 9:59 PM
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.
...

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

This works for me testing locally within a basic mw-docker setup. I think this should be ready for deployment during next Monday's (2026-03-23) security deployment window.

Mstyles moved this task from Security Patch To Deploy to Watching on the Security-Team board.Mon, Mar 23, 9:58 PM
Mstyles subscribed.
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

Deployed

Mstyles added a parent task: Restricted Task.Mon, Mar 23, 9:58 PM
sbassett added a subscriber: matmarex.Tue, Mar 24, 9:01 PM
Reedy renamed this task from action=raw with Special:Mypage subpage title responds with "Content-Type: text/html" on ctype=text/javascript request to CVE-2026-34095: action=raw with Special:Mypage subpage title responds with "Content-Type: text/html" on ctype=text/javascript request.Wed, Mar 25, 6:20 PM
Reedy added a subscriber: gerritbot.
Reedy closed this task as Resolved.Wed, Mar 25, 7:19 PM
Reedy reassigned this task from sbassett to taavi.
Reedy added projects: MW-1.43-release, MW-1.44-release, MW-1.45-release.
Reedy added a subscriber: sbassett.
matmarex added a comment.Thu, Mar 26, 9:25 PM

sbassett added a subscriber: matmarex.

+1 to the patch :)

gerritbot added a comment.Wed, Apr 1, 12:17 AM

Change #1265642 had a related patch set uploaded (by Reedy; author: Majavah):

[mediawiki/core@master] SECURITY: Actions: Make headers set after redirect actually apply

https://gerrit.wikimedia.org/r/1265642

gerritbot added a project: Patch-For-Review.Wed, Apr 1, 12:17 AM
gerritbot added a comment.Wed, Apr 1, 1:16 AM

Change #1265657 had a related patch set uploaded (by Reedy; author: Majavah):

[mediawiki/core@REL1_45] SECURITY: Actions: Make headers set after redirect actually apply

https://gerrit.wikimedia.org/r/1265657

gerritbot added a comment.Wed, Apr 1, 1:21 AM

Change #1265663 had a related patch set uploaded (by Reedy; author: Majavah):

[mediawiki/core@REL1_44] SECURITY: Actions: Make headers set after redirect actually apply

https://gerrit.wikimedia.org/r/1265663

gerritbot added a comment.Wed, Apr 1, 1:23 AM

Change #1265669 had a related patch set uploaded (by Reedy; author: Majavah):

[mediawiki/core@REL1_43] SECURITY: Actions: Make headers set after redirect actually apply

https://gerrit.wikimedia.org/r/1265669

gerritbot added a comment.Wed, Apr 1, 2:03 AM

Change #1265642 merged by jenkins-bot:

[mediawiki/core@master] SECURITY: Actions: Make headers set after redirect actually apply

https://gerrit.wikimedia.org/r/1265642

gerritbot added a comment.Wed, Apr 1, 2:17 AM

Change #1265657 merged by jenkins-bot:

[mediawiki/core@REL1_45] SECURITY: Actions: Make headers set after redirect actually apply

https://gerrit.wikimedia.org/r/1265657

gerritbot added a comment.Wed, Apr 1, 2:27 AM

Change #1265663 merged by jenkins-bot:

[mediawiki/core@REL1_44] SECURITY: Actions: Make headers set after redirect actually apply

https://gerrit.wikimedia.org/r/1265663

gerritbot added a comment.Wed, Apr 1, 2:43 AM

Change #1265669 merged by jenkins-bot:

[mediawiki/core@REL1_43] SECURITY: Actions: Make headers set after redirect actually apply

https://gerrit.wikimedia.org/r/1265669

taavi reopened this task as Open.Thu, Apr 2, 9:42 PM

Where did the $request = $context->getRequest(); line appear to the patches in Gerrit? That is unfortunately shadowing the $request variable from earlier in the function, turning the entire mitigation into a no-op.

taavi added a comment.Thu, Apr 2, 10:03 PM

Here is a fix for that variable shadowing issue:

0001-Actions-Fix-incorrect-variable-shadowing.patch1 KBDownload

Reedy added a subscriber: SomeRandomDeveloper.Thu, Apr 2, 10:46 PM
SomeRandomDeveloper added a comment.Thu, Apr 2, 10:49 PM
In T419192#11784456, @taavi wrote:

Where did the $request = $context->getRequest(); line appear to the patches in Gerrit? That is unfortunately shadowing the $request variable from earlier in the function, turning the entire mitigation into a no-op.

Sorry about that, I missed that when I was fixing phan (via the gerrit web editor, which was probably not the best idea)

SomeRandomDeveloper added a comment.Thu, Apr 2, 10:56 PM
In T419192#11784491, @taavi wrote:

Here is a fix for that variable shadowing issue:

0001-Actions-Fix-incorrect-variable-shadowing.patch1 KBDownload

+1, works fine for me

sbassett added a subscriber: Reedy.Fri, Apr 3, 3:13 PM
In T419192#11784456, @taavi wrote:

Where did the $request = $context->getRequest(); line appear to the patches in Gerrit? That is unfortunately shadowing the $request variable from earlier in the function, turning the entire mitigation into a no-op.

Looks like this issue made it into master and all of the release branch backports. So we probably just need to push your follow-up patch to gerrit, merge it and backport it to same release branches. Not sure if this merits a follow-up email or not; would leave that up to @Reedy's discretion.

gerritbot added a comment.Fri, Apr 3, 10:13 PM

Change #1267979 had a related patch set uploaded (by SBassett; author: Majavah):

[mediawiki/core@master] Actions: Fix incorrect variable shadowing

https://gerrit.wikimedia.org/r/1267979

gerritbot added a comment.Fri, Apr 3, 10:16 PM

Change #1267983 had a related patch set uploaded (by SBassett; author: Majavah):

[mediawiki/core@REL1_45] Actions: Fix incorrect variable shadowing

https://gerrit.wikimedia.org/r/1267983

gerritbot added a comment.Fri, Apr 3, 10:16 PM

Change #1267984 had a related patch set uploaded (by SBassett; author: Majavah):

[mediawiki/core@REL1_43] Actions: Fix incorrect variable shadowing

https://gerrit.wikimedia.org/r/1267984

gerritbot added a comment.Fri, Apr 3, 10:17 PM

Change #1267985 had a related patch set uploaded (by SBassett; author: Majavah):

[mediawiki/core@REL1_44] Actions: Fix incorrect variable shadowing

https://gerrit.wikimedia.org/r/1267985

gerritbot added a comment.Fri, Apr 3, 10:43 PM

Change #1267979 merged by jenkins-bot:

[mediawiki/core@master] Actions: Fix incorrect variable shadowing

https://gerrit.wikimedia.org/r/1267979

gerritbot added a comment.Sat, Apr 4, 9:40 AM

Change #1267985 merged by jenkins-bot:

[mediawiki/core@REL1_44] Actions: Fix incorrect variable shadowing

https://gerrit.wikimedia.org/r/1267985

gerritbot added a comment.Sat, Apr 4, 9:43 AM

Change #1267983 merged by jenkins-bot:

[mediawiki/core@REL1_45] Actions: Fix incorrect variable shadowing

https://gerrit.wikimedia.org/r/1267983

gerritbot added a comment.Sat, Apr 4, 9:44 AM

Change #1267984 merged by jenkins-bot:

[mediawiki/core@REL1_43] Actions: Fix incorrect variable shadowing

https://gerrit.wikimedia.org/r/1267984

sbassett closed this task as Resolved.Mon, Apr 6, 2:13 PM
sbassett changed Author Affiliation from N/A to Wikimedia Communities.
sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed Risk Rating from N/A to High.
sbassett moved this task from Watching to Our Part Is Done on the Security-Team board.
sbassett changed Author Affiliation from Wikimedia Communities to WMF Technology.
Maintenance_bot removed a project: Patch-For-Review.Mon, Apr 6, 2:31 PM
A_smart_kitten subscribed.Mon, Apr 6, 8:06 PM
In T419192#11785749, @sbassett wrote:

Looks like this issue made it into master and all of the release branch backports. So we probably just need to push your follow-up patch to gerrit, merge it and backport it to same release branches. Not sure if this merits a follow-up email or not; would leave that up to @Reedy's discretion.

IMO it would merit a follow-up email/release, given that the vulnerability being patched here is now public knowledge, but (IIUC) the released fix doesn't actually fix it. (But I suppose YMMV)

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits