Scripts from my global.js file no longer work.
I have two scripts in my file. I deleted one script at a time to rule out that this was the cause of the error.
In the wikis where I checked whether they work, no scripts appear to be loaded.
20260305: These are currently temporarily disabled globally due to an issue being worked on
20260305: Site JS was reenabled (log)
20260305: User JS was reenabled (log)
Site JS has been re-enabled: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1248571
User JS is still disabled. We are working to get that back online soon, with a few restrictions.
It's not working for me (yet). Could it work if I clear the cache, or does it still need to be rolled out?
Why restrictions?
To help protect against things like this while we work to better secure user and interface JavaScript on the projects. A public meta-wiki announcement is in this works.
Does that mean I won't be able to use scripts anymore in the future, or will there still be a way to do so?
Is there a way for projects to disable site js completely if unused? To reduce the attack vector.
A wiki could request setting $wgUseSiteJs = false - it'll affect MediaWiki:Common.js as well as gadgets
In theory, if you wanted to do that for a whole project, you could set $wgUseSiteCss, $wgUseSiteJs, $wgAllowUserCss and $wgAllowUserJs to false, and also disable the Gadgets extension.
You can also do it for just yourself – since 2023, there is a user preference Appearance → Advanced options → Always enable safe mode, which can also be set in your global preferences. This may have some negative effects on the appearance or behavior of some Wikimedia wikis, depending on how much they rely on these customizations.
At dewiki we migrated Common.js, Mobile.js and almost everything in <skin>.js to gadgets. Gadgets are still attackable but don't use a common name, are often restricted to page or action context and would need a more specific script. If there is a way to disable the empty sitewide js pages while keeping gadgets alive, it could be an option for dewiki.
Things like loading hundreds of random unused scripts from a privileged account? I think doing some restrictions as a result of this is valuable but scripts should not be disabled for days because of a personal misjudgment.
You can set up an abuse filter to prevent any edits to specified pages in MediaWiki namespace, then
Can somebody explain what this is even about? I don't even know if I should be worried or not.
There's more information at this village pump post. And there should be more official WMF communications soon. The short answer is that the projects are not under attack, site javascript has been re-enabled as of a couple of hours ago and user javascript should be re-enabled soon, with some hopefully-not-too-intrusive, temporary restrictions.
So this is what happened: https://meta.wikimedia.org/w/index.php?title=Special%3AContributions&target=SBassett+%28WMF%29&namespace=all&tagfilter=&start=2026-03-04&end=2026-03-06&limit=1000
SBassett (WMF) added hundreds or mw.loader lines with random userscripts to his global.js with the edit summary "testing userjs loads", including many common.js userscripts from ptwiki, eswiki and jawiki. From jawiki, three common.js files from vanished users were loaded.
This is not a particularly good idea. Especially when your account is a member of the https://meta.wikimedia.org/wiki/Staff_group with extensive global permissions.
(thanks to Nemoralis at https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation/Product_and_Technology/Product_Safety_and_Integrity/March_2026_User_Script_Incident for figuring this out)
userscripts loading third party assets are still not working, this is getting to be a big problem for Project Music where at least two popular scripts have stopped working.
mw.loader.load("//www.wikidata.org/w/index.php?title=User:Lectrician1/discographies3.js&action=raw&ctype=text/javascript");
mw.loader.load("//www.wikidata.org/w/index.php?title=User:Lectrician1/embeds.js&action=raw&ctype=text/javascript");ping @Lectrician1
I believe this is due to a Content-Security-Policy change that was rolled out following this incident (xref e.g. T419234#11682841). As I understand it, folks are being encouraged to file Phab tickets about any (user)scripts that have stopped working as a result of this change.
That is correct. The parent task is here: T419265. Affected users are encouraged to file subtasks there. While we do wish to accommodate as many external domains as possible, we cannot guarantee that we will be able to support every domain.