In short, a Wikimedia Foundation account was doing some sort of test which involved loading a large number of user scripts. They decided to just start loading random user scripts, instead of creating some just for this test.

The user who ran this test is a Staff Security Engineer at WMF, and naturally they decided to do this test under their highly-privileged Wikimedia Foundation staff account, which has permissions to edit the global CSS and JS that runs on every page.

One of those random scripts was a 2 year old malicious script from ruwiki. This script injects itself in the global Javascript on every page, and then in the userscripts of any user that runs into it, so it started spreading and doing damage really fast. This triggered tons of alerts, until the decision was made to turn the Wiki read-only.

That makes the fix pretty easy. Write a regex to detect the evil script, and revert every page to a historic version without the script.

This library wasn't a living creature, or even possessed of automation (which here might mean something more, far more, than human)."

It's very short and from one of my favorite books. Increasingly relevant.

I agree, mostly, but I'm also really glad I don't have to put out this fire. Cheering them on from the sidelines, though!

I refuse to believe that someone on the security team intentionally tested random user scripts in production on purpose.

Do I have a bridge to sell you, oh boy

"Claude> Yes, you're absolutely right! I'm sorry!"

On the other hand,

>a Staff Security Engineer at WMF, and naturally they decided to do this test under their highly-privileged Wikimedia Foundation staff account

seriously?

this is both really cool and really really insane

https://www.mediawiki.org/wiki/Manual:Interface/JavaScript

For the global ones that need admin permissions to edit, it's no different from all the other code of mediawiki itself like the php.

For the user scripts, it's no worse than the fact that you can run tampermonkey in your browser and have it modify every page from evry site in whatever way your want.

- Inject itself into the MediaWiki:Common.js page to persist globally, and into the User:Common.js page to do the same as a fallback

- Uses jQuery to hide UI elements that would reveal the infection

- Vandalizes 20 random articles with a 5000px wide image and another XSS script from basemetrika.ru

- If an admin is infected, it will use the Special:Nuke page to delete 3 random articles from the global namespace, AND use the Special:Random with action=delete to delete another 20 random articles

EDIT! The Special:Nuke is really weird. It gets a default list of articles to nuke from the search field, which could be any group of articles, and rubber-stamps nuking them. It does this three times in a row.

Do keep us updated on the whole situation if any relevant situation can happen from your POV perhaps.

I'd suggest to give the domain to wikipedia team as they might know what could be the best use case of it if possible.

If anyone from the Russian government is reading this, get the fuck out of Ukraine. Thank you.

You have helped to bring peace by approximately zero nanoseconds, while doing absolutely nothing about western countries still buying massive amounts of natural resources from Putin. Tax income on their exports make the primary source of income for the federal budget, which directly funds the military.

Good virtue signaling, though. I'm completely disillusioned with the West, this is nothing new.

By doing nothing, you are allowing a malicious actor to buy the domain. In fact I am sure they would love for everyone else to be paralyzed by purity tests for a $1 domain.

All things being equal, yeah don’t buy a .ru domain. But they are not equal.

> On 1 January 2025, Ukraine terminated all Russian gas transit through its territory, after the contract between Gazprom and Naftohaz signed in 2019 expired. [...] It is estimated that Russia will lose around €5bn a year as a result.

https://en.wikipedia.org/wiki/Russia%E2%80%93Ukraine_gas_dis...

> Namecheap is a U.S. based domain name registrar and web hosting service company headquartered in Phoenix, Arizona.

and in 2025 they were purchased by:

> CVC Capital Partners plc is a Jersey-based private equity and investment advisory firm

What should we put there, anyway?

Note while this looks like its trying to trigger an xss, what its doing is ineffective, so basemetrika.ru would never get loaded (even ignoring that the domain doesnt exist)

Of course it's very possible someone wrote it with AI help. But almost no chance it was designed by AI.

Well, worm didn't get root -- so if wikimedia snapshots or made a recent backup, probably not so much of a nightmare? Then the diffs can tell a fairly detailed forensic story, including indicators of motive.

Snapshotting is a very low-overhead operation, so you can make them very frequently and then expire them after some time.

People usually remember what they changed yesterday and have uploaded files and such still around. It's not great, but quite possible. Maybe you need to pull a few content articles out from the broken state if they ask. No huge deal.

If you decide to roll back after a week or so, editors get really annoyed, because now they are usually forced to backtrack and reconcile the state of the knowledge base, maybe you need a current and a rolled-back system, it may have regulatory implications and it's a huge pain in the neck.

As an aside, snapshotting would have prevented a good deal of horror stories shared by people who give AI access to the FS. Well, as long as you don't give it root.......

obviously you can. but, what is the actual snapshot frequency? like, what is the timestamp of the last known good snapshot? that is what matters.

in any case, the comment you are replying to is a hypothetical, which correctly points out that even a day or two of lost edits is fine (not ideal, but fine). your reply doesnt engage with their comment at all.

I did engage, by pointing out that it wasn't relevant nor a realistic scenario for a competent sysadmin. (Did you read the OP?) That's a /you/ problem if you rely on infrequent backups, especially for a service with so much flux.

> what is the actual snapshot frequency? like, what is the timestamp of the last known good snapshot?

? Why would I know what their internal operations are?

>Why would I know what their internal operations are?

i mean... you must, right? you know that once-a-day snapshots is not relevant to this specific incident. you know that their sysadmins are apparently competent. i just assumed you must have some sort of insider information to be so confident.

my decade of dealing with incompetent sysadmins and broken backups (if they even exist) has given me the opposite of confidence.

but im glad you have had a different experience

Oh, I agree that the average bar is low. That's part of the reason I do it all myself.

The heuristic with wikimedia is that they've been running a PHP service that accepts and stores (anonymous) input for 25 years. The longetivity with the risk exposure that they have are indicators that they know what they are doing, and I'm sure they've learned from recovering all sorts of failures over the years.

Look at how quickly it was brought back up in this instance!

So, yeah. I don't think initial hypothetical counterpoint holds water, and that's what I have been pointing out.

i found kibone's reply to a hypothetical musing as if it was some counterpoint in a debate instead of a simple expansion on their comment to be off putting. we had some comments back and forth and we both came out of it just fine. weird of you to add on this little insult to an otherwise pretty normal exchange.

I still don't need to assume what the intent is. Troll or no troll, it works. My comments might inspire someone else to try a CoW fs. I'm also really impressed with wikimedia's technical team.

Feels good to pat oneself in the back. Mine is sore, though. My E&O/cyber insurance likes me.

1. In 2023, vandal attacks was made against two Russian-language alternative wiki projects, Wikireality and Cyclopedia. Here https://wikireality.ru/wiki/РАОрг is an article about organisators of these attacks.

2. In 2024, ruwiki user Ololoshka562 created a page https://ru.wikipedia.org/wiki/user:Ololoshka562/test.js containing script used in these attacks. It was inactive next 1.5 years.

3. Today, sbassett massively loaded other users' scripts into his global.js on meta, maybe for testing global API limits: https://meta.wikimedia.org/wiki/Special:Contributions/SBasse... . In one edit, he loaded Ololoshka's script: https://meta.wikimedia.org/w/index.php?diff=prev&oldid=30167... and run it."

- There are constant deface incidents caused by editing of unprotected / semiprotected templates

- There were incidents of UI mistranslation (because MediaWiki translation is crowdsourced)

- The attack that was applied is well know though in Russian community, it is pretty much standard "admin-woodpecker". The standard woodpecker (some people call it neo-woodpecker) renamed all pages with a high speed (I know this since 2007, the name woodpecker appeared many years later); then MediaWiki added throttling for renames; then neo-woodpecker reappeared in different years (usually associated with throttling bypass CVEs). Early admin-woodpeckers were much more destructive (destroyed a dozens of mediawiki websites due to lack of backups). Nuking admin woodpecker it quite a boring one, but I think (I hope) there are some AbuseFilter guardrails configured to prevent complex woodpeckers.

- The attack initiator is 100% a well known user; there are not too many users who applied woodpecker in the first place; not too many "upyachka" fans (which indicates that user edited before 2010 - back then active editors knew each other much better). But it is quite pointless to discuss who exactly the initiator is.

- Wikireality page is hijacked by a small group and does not represent the reality.

I’ve always thought the fact that MediaWiki sometimes lets editors embed JavaScript could be dangerous.

It seems like the worm code/the replicated code only really attacks stuff on site. But leaking credentials (and obviously people reuse passwords across sites) could be sooo much worse.

[0] https://varun.ch/posts/autofill/

If an attacker wanted passwords en masse they could inject fake login forms and try to simulate focus and typing, but that chain is brittle across browsers, easy to detect and far lower yield than stealing session tokens or planting persistent XSS. Defenders should assume autofill will be targeted and raise the bar with HttpOnly cookies, SameSite=strict where practical, multifactor auth, strict Content Security Policy plus Subresource Integrity, and client side detection that reports unexpected DOM mutations.

  "The incident appears to have been a cross-site scripting hack. The origin of rhe malicious scripts was a userpage on the Russian Wikipedia. The script contained Russian language text.

  During the shutdown, users monitoring [https://meta.wikimedia.org/wiki/special:RecentChanges Recent changes page on Meta] could view WMF operators manually reverting what appeared to be a worm propagated in common.js

  Hopefully this means they won't have to do a database rollback, i.e. no lost edits. "

https://wikipediocracy.com/forum/viewtopic.php?f=8&t=14555

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(techni...

https://old.reddit.com/r/wikipedia/comments/1rllcdg/megathre...

Apparent JS worm payload: https://ru.wikipedia.org/w/index.php?title=%D0%A3%D1%87%D0%B...

The Wikipedia community takes a cavalier attitude towards security. Any user with "interface administrator" status can change global JavaScript or CSS for all users on a given Wiki with no review. They added mandatory 2FA only a few years ago...

Prior to this, any admin had that ability until it was taken away due to English Wikipedia admins reverting Wikimedia changes to site presentation (Mediaviewer).

But that's not all. Most "power users" and admins install "user scripts", which are unsandboxed JavaScript/CSS gadgets that can completely change the operation of the site. Those user scripts are often maintained by long abandoned user accounts with no 2 factor authentication.

Based on the fact user scripts are globally disabled now I'm guessing this was a vector.

The Wikimedia foundation knows this is a security nightmare. I've certainly complained about this when I was an editor.

But most editors that use the website are not professional developers and view attempts to lock down scripting as a power grab by the Wikimedia Foundation.

True, but there aren't very many interface administrators. It looks like there are only 137 right now [0], which I agree is probably more than there should be, but that's still a relatively small number compared to the total number of active users. But there are lots of bots/duplicates in that list too, so the real number is likely quite a bit smaller. Plus, most of the users in that list are employed by Wikimedia, which presumably means that they're fairly well vetted.

[0]: https://en.wikipedia.org/w/api.php?action=query&format=json&...

Unfortunately, Wikipedia is run on insecure user scripts created by volunteers that tend to be under the age of 18.

There might be more editors trying to resume boost if editing Wikipedia under your real name didn't invite endless harassment.

You can also upload scripts to be shared and executed by other users.

As in, user can upload whatever they wish and it will be shown to them and ran, as JS, fully privileged and all.

>There are currently 15 interface administrators (including two bots).

https://en.wikipedia.org/wiki/Wikipedia:Interface_administra...

A certain number of "community" admins maintain that right to this day after it was realized this was a massive security hole.

Just now thought “if Wikipedia vanished what would it mean … and it’s not on the level of safe drinking water, but it is a level.

That someone would need to restore some backups, and in the meantime, use mirrors.

Seriously, not that big of a deal. I don't know how many copies of Wikipedia are lying around but considering that archives are free to download, I guess a lot. And if you count text-only versions of the English Wikipedia without history and talk pages, it is literally everywhere as it is a common dataset for natural language processing tasks. It is likely to be the most resilient piece of data of that scale in existence today.

The only difficulty in the worst case scenario would be rebuilding a new central location and restarting the machinery with trusted admins, editors, etc... Any of the tech giants could probably make a Wikipedia replacement in days, with all data restored, but it won't be Wikipedia.

That's small enough to live on most people's phones. It's small enough to be a single BluRay. Maybe Wikipedia should fund some mass printings.

What you do not get however is any media. No sounds, images, videos, drawings, examples, 3D artifacts, etc etc etc. This is a huge loss on many many many topics.

It's not a high bar.

Haven't we hit that point already with bad faith (and potentially government-run) coordinated editing and voting campaigns, as both Wales and Sanger have been pointing out for a while now?

See, for example,

* Sanger: https://en.wikipedia.org/wiki/User:Larry_Sanger/Nine_Theses

* Wales: https://en.wikipedia.org/wiki/Talk:Gaza_genocide/Archive_22#...

* PirateWires: https://www.piratewires.com/p/how-wikipedia-is-becoming-a-ma...

Yes, this is a real phenomenon. See, for instance, https://en.wikipedia.org/wiki/Timeline_of_Wikipedia%E2%80%93...: the examples from 2006 are funny, and the article's subject matter just gets sadder and sadder as the chronology goes on.

> and voting campaigns

I'm not sure what you mean by this. Wikipedia is not a democracy.

> as both Wales and Sanger have been pointing out

{{fv}}. Neither of those essays make this point. The closest either gets is Sanger's first thesis, which misunderstands the "support / oppose" mechanism. Ironically, his ninth thesis says to introduce voting, which would create the "voting campaign" vulnerability!

These are both really bad takes, which I struggle to believe are made in good faith, and I'm glad Wikipedians are mostly ignoring them. (I have not read the third link you provided, because Substack.)

https://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_no...

Find the first instance and reset to the backup before then. An hour, a day, a week? Doesn't matter that much in this case.

This may be unrelated but I also noticed more attacks on e. g. libgen, Anna's archive and what not. I am not at all saying this is similar to Wikipedia as such, mind you, but it really seems as if there are more actors active now who target people's freedom now (e. g. freedom of choice of access to any kind of information; age restriction aka age "verification" taps into this too).

This exact type of database-stored executable javascript was one of the most annoying types of infections to clean up.

Also, does this worm have a name?

Basically someone who had permissions to alter site js, accidentally added malicious js. The main solution is to be very careful about giving user accounts permission to edit js.

[There are of course other hardening things that maybe should be done based on lessons learned]

The account in question had "staff" rights which gave him basically all rights on all wikis.

It's a common feature of CMS'es and "tag management systems." Its presence is a massive PITA to developers even _besides_ the security, but PMs _love them_, in my experience.

https://en.wikipedia.org/wiki/Wikipedia:Village_stocks#Scott...

/s

It is just another human acting human again.

It's simply a calculated risk.

How much business and application logic you put in your Javascript is critical.

On your second unrelated comment about Wikipedia needing to use 2FA, there's probably a better way to do it and I hope mediawiki can do it.

It doesn't matter how much functionality the JS was originally responsible for, it could've been as little as updating a clock, validating forms, or just some silly animation. Once that JS executes in your browser it has access to your cookies and local storage, which means it can trigger whichever server-side actions it wants.

My second comment is not unrelated. The root cause of this mess is the fact that JS can be edited by privileged users without an approval process. If every change to the JS code required the user to enter their 2FA code (TOTP, let's say) then there would be no way for the worm to spread whenever users visited a page.

...except for us security wonks who have js turned off by default, don't enable it without good reason, disable it ASAP, and take a dim view of websites that require it.

Not too many years ago this behavior was the domain of Luddites and schizophrenics. Today it has become a useful tool in the toolbox of reasonable self-defense for anybody with UID 0.

Perhaps the WMF should re-evaluate just how specialsnowflake they think their UI is and see if, maybe just maybe, they can get by without js. Just a thought.

Also, FWIW: Wikipedia is "specialsnowflake". If it isn't, that's merely because it was so specialsnowflake that there's now a healthy of ecosystem of sites that copied their features! It's far, far more capable than a simple blog, especially when you get into editing it.

No, I'm not suggesting we all go back to purely-static web pages, imagemap gifs and server side navigation. But you're going to have a hard time convincing me that I really truly need to execute code of unknown provenance in my this-app-does-everything-for-me process just to display a few pages of text and 5 jpegs.

And for the record, I've called myself a Technologist for almost 30 years now. If I were a closet Luddite I'd be one of the greatest hypocrites of human history. :-)

And the entire English wikipedia with no images is, interestingly, also 43GiB.

edit: lol downvoted with no counterpoint, is it hitting a nerve?

I have upvoted ya fwiw and I don't understand it either why people would try to downvote ya.

I mean, if websites work for you while disabling js and you are fine with it. Then I mean JS is an threat vector somewhat.

Many of us are unable to live our lives without JS. I used to use librewolf and complete and total privacy started feeling a little too uncomfortable

Now I am on zen-browser fwiw which I do think has some improvements over stock firefox in terms of privacy but I can't say this for sure but I mainly use zen because it looks really good and I just love zen.

It's also been torture, I definitely don't prescribe it. :P Like you say, it's a sanity / utility / security tradeoff. I just happen to be willing to trade off sanity for utility and security.

And yes, unfortunately I have to enable JS for some sites -- the default is to leave it disabled. And of course with cloudflare I have to whitelist it specifically for their domains (well, the non analytics domains). But thankfully wikipedia is light and spiffy without the javascript.

That being said, Once again, Librewolf is amazing software. I can see myself using it again but I just find zen easier in the sense of something which I can recommend plus ubO obv

Personally these are more aesthetic changes more than anything. I just really like how zen looks and feels.

The answer is sort of, Just personal preference that's all.

My LLM sense is tingling.

I still have a basic assumption that if something I'm reading doesn't make much sense to me, I probably just don't understand it. Over the last few years I've had to get used to the new assumption that it's because I'm reading LLM output.

I've been spending less and less time here, the moderation is obviously overwhelmed and is losing the battle.

https://aphyr.com/posts/389-the-future-of-forums-is-lies-i-g...

I wouldn't be surprised if that group were the origin of this attack too.

It only clicked for me a few weeks ago, in one thread or another here when I realized that no one could ever do what Google did once: Cloudflare and other antibot technologies have closed off traditional search-as-the-result-of-web-crawling permanently. It's not that no one will do it because they think there's no money in it, or that no one will do it because the upfront costs are gigantic... literally it can no longer be done.

The internet died.

Mojeek is a good independent search browser, it isn't the best but at that Hackernews comment/analysis I was doing I found it to be the only one which worked for that case.

Brave exists too.

I know the situation is very critical/dire tho but there is still some chance. All be it quite small.

Mojeek IIRC, is operated by one single guy for 15 years.

Most claims of LLM authorship are erroneous.

https://danielc7.medium.com/remote-code-execution-gaining-do...

Also the language that has made me millions over my career with no degree.

Also the language that allows people to be up and running in seconds (with or without AI).

I could go on.

Well done.

> Also the language that allows people to be up and running in seconds (with or without AI).

People getting up and running without any opportunity to be taught about security concerns (even those as simple as the risks of inadequate input verification), especially considering the infamous inconsistency in PHP's APIs which can lead to significant foot-guns, is both a blessing and a curse… Essentially a pre-cursor to some of the crap that is starting to be published now via vibe-coding with little understanding.

PHP makes it easy.

One thing I particularly hate is when functions require calling another function afterwards to get any errors that happened, like `json_decode`. C has that problem too.

Problems don't make it a _bad_ programming language. All languages have problems. PHP just has more than some other languages.

The bottom half.

;)

Works great, but, like any tool, usage matters.

People who use tools badly, get bad results.

I've always found the "Fishtank Graph" to be relevant: https://w3techs.com/technologies/history_overview/programmin...

PHP works fine, if you're a halfway decent programmer. Same with C++.

That isn't the fault of the language of course, but a valid reason for some of the “ick” reaction some get when it is mentioned.

Most modern web languages like nodejs are far worse due to dependency rot, and poor REST design pattern implementations. =3

  PHP Warning:  Uncaught Error: Undefined constant "flase" in php shell code:1

(Unless this was satire and I missed it)

The Wikimedia Foundation (WMF) maintains a significant financial surplus and a growing, healthy balance sheet, with net assets reaching approximately $271.5 million in the 2023–2024 fiscal year. This surplus is largely driven by consistent, high-volume, small-dollar donations, with total annual revenue often exceeding $180 million.

https://en.wikipedia.org/wiki/Wikipedia:Fundraising_statisti...

https://wikimediafoundation.org/who-we-are/financial-reports...

[1]: https://wikimediafoundation.org/wp-content/uploads/2025/04/W...

[2]: https://wikimediafoundation.org/annualreports/2023-2024-annu...

Another key difference over the last 15 years has been the introduction of awards and grants, which didn't exist then but now comprise $26.8M (15%) of their expenditures. This is where most of the ideological/controversial spending actually goes, rather than the salaries per se, but even more to the point, this one line item is more than 3 times their entire inflation-adjusted budget from 15 years ago ($5.6M times 150% CPI = $8.4M) and is still more than if we adjusted their entire budget using the hosting cost as an index ($5.6M times 3.75 = $21M).

[1]: https://upload.wikimedia.org/wikipedia/commons/a/a4/WMF_Annu...

Using hosting costs as an index is nonsensical. I wasn't able to find numbers for 2009, but since 2015 the monthly page views have remained almost exactly constant. So you might as well claim that they're vastly overpaying for hosting since inflation from 2008 is way less than 3.75x.

Ultimately every person has to decide for themselves whether they think WMF is a worthy recipient for their donations, but it is in no way operating on a shoestring budget nor staffed by volunteers anymore.

https://en.wikipedia.org/wiki/User:Guy_Macon/Wikipedia_has_C...

[0] https://en.wikipedia.org/wiki/Wikipedia:No_original_research...

In a discussion forum like HN, pointing to primary sources is the most reliable input to the other readers' research on/synthesis of their own secondary interpretation of what may be going on. Pointing to other secondary interpretations/analyses is also useful, but not without including the primary source so that others can - with apologies to the phrase currently misused by the US right wing - truly do their own research.

My original post was a joke about this.

https://www.theverge.com/2022/8/18/23206110/james-webb-space...

Actually fuck the whole dynamic web. Just give us hypertext again and build native apps.

Edit: perhaps I shouldn't say this on an VC driven SaaS wankfest forum...

But if there's one thing I've learned over the years as a technologist, it's this: the "best technology" is not often the "technology that wins".

Engineering is not done in a vacuum. Indeed, my personal definition of engineering is that it is "constraint-based applied science". Yes, some of those constraints are "VC buxx" wanting to see a return on investment, but even the OSS world has its own set of constraints - often overlapping. Time, labor, existing infrastructure, domain knowledge.

The entire web is built on geopolitical stability and cooperation. That is no longer certain. We already have supply chains failing (RAM/storage) meaning that we will be hardware constrained for the foreseeable future. That puts the onus on efficiency and web apps are NOT efficient however we deliver them.

People are also now very concerned about data sovereignty whereas they previously were not. If it's not in your hands or on your computer than it is at risk.

The VC / SaaS / cloud industry is about to get hit very very hard via this and regulation. At that point, it's back to native as delivery is not about being tied to a network control point.

I've been around long enough to see the centralisation and decentralisation cycles. We're heading the other way now

> "VC / SaaS / cloud industry is about to get hit very very hard via ... regulation"

can you explain?

How? Well the numerous non-US sovereign technology initiatives are going to be incentivised through regulation with local compliance being the only option going forwards.

As a non-US person I am already speaking to people at other orgs in similar space as ours who are looking at options there.

There's also a lot of client-side authentication, even with financial transactions, e.g. with iOS and Android locally verifying a users password, or worse yet a PIN or biographic information, then sending approval to the server. Granted, authentication of any kind is optional for credit card transactions in the US, so all the rest is security theater, but if it did matter, it would be the worst way to do it.