| Niepodkoloryzowany | |
| Mar 5 2026, 3:57 PM |
| F72628984: Screenshot_20260306_092438_Brave.jpg | |
| Mar 6 2026, 2:27 AM |
| F72591561: image.png | |
| Mar 5 2026, 3:57 PM |
Is everyone experiencing the inability to edit Wikis (Wikipedia, Wiktionary, etc.)? E.g. English Wikipedia, a random article, here's what I've been experiencing since 15:32 UTC:
It would be good if the user script disabling would be limited to Meta, since this issue didn’t affect other wikis. People seem to be angry enough about this, no reason to make them angrier, as many workflows depend on user scripts in most wikis.
I will be writing this up for the Signpost, so if you have the actual code, I would be curious to take a look at it for myself (I don't know if there are private messages on Phab but EmailUser on the English Wikipedia should work for me).
Given the gaping security hole this revealed, I wouldn't be surprised if user scripts are disabled until more safety rails are in place (such as preventing them from non-interactive editing of common.js).
@jpxg yes, I have the codes (Ololoshka's code and the code that was injected to Meta's common.js, it's different codes). Write me to mbhwik@gmail.com.
For future reference, the page User:Ololoshka562/test.js also seems to have been saved on the Internet Archive
I think the known nature of the incident shows that this is not necessarily required to be done ASAP. Never mind that the WMF was not focusing on obvious solutions (such as requiring a 2FA confirmation step for editing site-wide JS) for years already.
Can the codes be shared here? Obscuring and hiding information will not prevent any future attacks, but sharing might help protect against them.
If a steward is compromised they can theorically put malicious JS to common.js in every Wikimedia wikis (which will cause much larger mess than the current one). So I do not believe doing so is good.
I’ve wrote my comment based on available code, not theoretically. It doesn’t do that sort of thing. And unless another person loads some other bullshit script, it won’t.
I believe we need to fix T197137: Editing sitewide JS/CSS pages should require elevated security and T419152: Editing user JS/CSS pages of another user should require elevated security - this will at least largely prevent malicious scripts be spread to other users.
What user codes are disabled for now? I tried on my account and seems like gadgets are not affected?
That might be a good idea, but there are also gadgets. And some gadgets load user code. And some users load code of other users. This is sometimes even required and there is no other installation method (like e.g. User:SuperHamster/view-it-full.js).
Another issue that needs fixing is T40417: MediaWiki's anonymous edit token leaves wiki installations (incl. Wikipedia) open to mass anonymous spam we can't block; though not directly related to this accident, but we need to prevent XSS from 3rd websites to spread into Wikimedia project. Currently a malicious script in any website can make every viewer a vandalbot in Wikimedia.
Here's the user script: https://justpaste.it/kjjkn
And here's what was inserted into hacked users' common.js: https://justpaste.it/iduq4
May I ask, why specific revisions in https://meta.wikimedia.org/w/index.php?title=User:SBassett_(WMF)/global.js&action=history were hidden?
What exactly happened, is that there were about 30 edits, adding 200 different scripts in each.
One of these scripts was obviously ru ... User:Ololoshka562/test.js, and this script is a well known woodpecker script (this name is used at least since 2013, code is not really new and exists in web archives and other MediaWiki websites), which by design very visible, and can't steal credentials. The problem is not in this script. Thousands of other scripts from all subdomains were executed. While it is very likely that these scripts additionally import something else from third-party domains, at least some audit of all executed scripts should be done. Hiding revisions in this case is simply pointless and causes extra suspicion.
One case (not the worst one, but simple to implement) is any of these scripts installed ServiceWorker which still continues to work (even after script removal and hard cache clean) even when user is logged out. Such script can transparently hijack user credentials (including 2fa), creating undetectable sessions from malicious party side. ServiceWorker script could target specific groups (Oversighters/Checkusers/UI administrators/etc.), target specific countries/languages, stay dormant as long as needed, self-unregister on attempt to open devtools, and so on.
Therefore, could you please:
Thanks,
@Lockal there is a security task about the issues you mentioned. Please discuss that there.
Is this also the cause why now the list of available external services is limited? My gadgets/custom JS were able to use openrouteservice.org and overpass-api.de (OSM) previously, but no more...
Connecting to '<URL>' violates the following Content Security Policy directive: "default-src 'unsafe-eval' 'unsafe-inline' 'self' data: blob: *.wikimedia.org *.wikipedia.org *.... *.translate.yandex.net yastatic.net ya.ru radically.github.io cdn.sammdot.ca ...". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback. The action has been blocked.
How was the list chosen and where can I ask to extend it?
I believe that this is because of a change that was made following this incident (xref e.g. T419234#11682841), but I don't believe that it's directly related to T40417.
How was the list chosen and where can I ask to extend it?
I can't personally answer the first question; but as for the second, I believe you can file a task on Phabricator to request additions. (I left a comment on Meta-Wiki with some potential task templates in case they're helpful, but it's not required to use them!)
Is this also the cause why now the list of available external services is limited?
Feel free to file a subtask of T419265.
is any of these scripts installed ServiceWorker which still continues to work (even after script removal and hard cache clean)
You are overstating this a bit. ServiceWorker have to be on same domain so the script would have to be on meta. ServiceWorkers can only persist 24 hours after the service worker's script (its actual script not the script that loaded it) is deleted,not forever. There are no non-obfuscated using service workers on meta right now, althought i of course would not to be able to find obfuscated scripts in a search.
I consider the possibility of a service worker here to be extremely low liklihood. That said it might be prudent for WMF to look at logs/take mitigations just in case. That is currently being discussed in the private task.
Being on meta you can import scripts that are outside of meta e.g.:
https://meta.wikimedia.org/wiki/User:Nux/global.js?diff=cur#L-104
I did some tests recently so if you haven't found this script you were not looking hard enough ;-)
https://pl.wikipedia.org/wiki/Wikipedysta:EcceNux/test.sw.js
BUT... even thought you can register SW and it kind of works it seems to be quite limited. BUT I didn't have time test too much. So there might be something to it, defintly something to consider from a security team. Not sure if SW should be allowed in user scripts. SW would be great to offload some work and make MW core faster, but don't really see it in user scripts and gadgets.
Being on meta you can import scripts that are outside of meta e.g.:
https://meta.wikimedia.org/wiki/User:Nux/global.js?diff=cur#L-104
Normal scripts yes. Service workers no.
I did some tests recently so if you haven't found this script you were not looking hard enough ;-)
https://pl.wikipedia.org/wiki/Wikipedysta:EcceNux/test.sw.js
I only looked on meta, as that is where it would have to be for this specific incident. I am aware there are a small number of SW scripts elsewhere. On the whole i agree its obscure enough it makes sense to ban them in user scripts.
If any SW was installed there would be have been a request with the Service-Worker header set. I take it these weren't being logged?
