Technology

hideshow 14 child comments

[–] Takapapatapaka@tarte.nuage-libre.fr 142 points 8 months ago (13 children)

Shameless copy/paste of the main info if anyone wants to catch a glimpse without going to reddit :

Summary of events:

On 5 March 2026, a Wikimedia Foundation employee accidentally imported a malicious script to his account on Meta-Wiki while testing global API limits for user scripts (see his global.js page history). The malicious script was created in 2023 to attack two Russian-language alternative wiki projects, Wikireality and Cyclopedia. In 2024, user Ololoshka562 created a page on the Russian Wikipedia containing the script used in these attacks. The script, which had been sitting dormant on ruwiki for 1.5 years, then spread to several accounts on Meta, including WMFOffice, and mass-deleted pages in namespaces 0–3, leaving behind an edit summary of "Закрываем проект", Russian for "Closing the project". The staff member, as a global interface administrator, has permission to edit meta:MediaWiki:Common.js, which allowed the script to infect any user who visited Meta-Wiki while it was active. To prevent the script from spreading further, all Wikimedia projects were set to read-only for about 2 hours, and all user JavaScript was temporarily disabled.

Post from WMF staff member on Discord:

Hey all - as some of you have seen, we (WMF) were doing a security review of the behavior of user scripts, and unintentionally activated one that turned out to be malicious. That is what caused the page deletions you saw on the Meta log, which are getting cleaned up. We have no reason to believe any third-party entity was actively attacking us today, or that any permanent damage occurred or any breach of personal information.

We were doing this security review as part of an effort to limit the risks of exactly this kind of attack. The irony of us triggering this script while doing so is not lost on us, and we are sorry about the disruption. But the risks in this system are real. We are going to continue working on security protections for user scripts – in close consultation with the community, of course – to make this sort of thing much harder to happen in the future.

hideshow 13 child comments

parent

[–] thebestaquaman@lemmy.world 72 points 8 months ago (1 child)

To be fair I would assume that it's better to trigger something like this during a security review when people are actively "online" and focused on security risks than at some other time.

parent

hideshow 1 child comment

[–] SnotFlickerman@lemmy.blahaj.zone 33 points 8 months ago

Absolutely and it helped prove why they needed to do this security review to begin with as well as will teach them the nature of how this user script worked so they can put up guardrails for this specific type of attack. An unfortunate event but as long as they are using it to learn from and strengthen their security, overall it's a good thing.

parent

[–] Gullible@sh.itjust.works 38 points 8 months ago (5 children)

That’s hilarious, and I cannot imagine how stressed out that employee is.

hideshow 5 child comments

parent

[–] db2@lemmy.world 23 points 8 months ago* (4 children)

After that kind of learning experience that employee needs a reprimand and a raise in that order. You can bet that shit won't happen twice! 😆

hideshow 4 child comments

parent

[–] mic_check_one_two@lemmy.dbzer0.com 4 points 8 months ago*

We had an employee break procedure, make a dumb mistake, and cause ~$160k worth of damage to a mission-critical piece of infrastructure. It happened due to her own inattention and disregarding her “here’s how to shut down at the end of the night” checklist, at like 8PM. Basically, instead of doing steps A, B, C, and D, she went “eh I know what I’m doing,” jumped straight to step D, and suddenly heard very expensive noises. It required me and her supervisor to pull an overnight shift to get a bodged workaround in place, just to be ready for the next morning at 8AM. And even then, the gear was out of commission for about a month until we could get it fixed.

All in all, it was about $80k worth of equipment repairs, $40k in equipment rentals (to keep things running in the meantime), and about $40k in additional labor (we had to hire specialized contractors to fix the gear).

The employee 100% thought she was going to get fired when it happened. We were obviously angry and disappointed that she made such a dumb mistake, but we didn’t yell or chastise her. We simply told her to go ahead and clock out for the evening, and we’d deal with fixing things overnight. She tried to say she could stick around to help… But this was already at the end of her shift, she was obviously not in the right headspace to pull an overnight shift, and we were both too frustrated to have her around at the time. She was crying on her way out the door.

The supervisor decided to keep her on instead of firing her, for this exact reason. She didn’t get a raise, but she didn’t get fired either. She got reprimanded, but her supervisor was confident that she would never make the same dumb mistake again. And now her story is used as a cautionary tale to drive home the importance of following procedure when we’re training new hires.

parent

[–] nik9000@programming.dev 2 points 8 months ago

Back when I worked at the foundation there was a special permission that you couldn't have unless you'd broke stuff super badly. To push new code you have to have one of those folks present. They were responsible for making sure there was a back out plan and ran the actual deploy script. Their ssh keys did the deploy.

I got this bit set after I took out search for Italian Wikipedia. And all none Wikipedias.

parent

[–] crandlecan@mander.xyz 2 points 8 months ago (1 child)

You want even more Management?? 😨

parent

hideshow 1 child comment

[–] db2@lemmy.world 12 points 8 months ago

Raise and promotion are not synonyms.

parent

[–] deacon@lemmy.world 22 points 8 months ago

Ironically it is comments like these that led to Reddit gold. But thank you kind stranger for saving me having to descend into The Depths for this.

parent

[–] TheTechnician27@lemmy.world 19 points 8 months ago*

Danke. This should easily be fine for anyone who's slightly-to-moderately interested; some of the nitty-gritty details like hyperlinks to the edit diffs are excluded from this copy–paste for those who really know their stuff and want to learn more.

parent

[–] Jack@lemmy.ca 7 points 8 months ago (1 child)

To prevent the script from spreading further, all Wikimedia projects were set to read-only for about 2 hours, and all user JavaScript was temporarily disabled.

The NoScript extension in Firefox makes the web so much nicer. It turns out sites that don't require JavaScript tend to made by vastly better humans than sites that do. More so for sites that require cross-site scripting and cookies to just show text.

Can't search on google.com without allowing JavaScript, but it turns out Lite.DuckDuckGo does, and for me at least gives vastly better search results.

Wikipedia can be read and edited without allowing JavaScript, and I personally don't like the crap that the scripts provide. It's also usable without cookies, tho the idiotic UI options column on the right is a hassle without cookies.

parent

hideshow 1 child comment

[–] mic_check_one_two@lemmy.dbzer0.com 4 points 8 months ago

Can't search on google.com without allowing JavaScript, but it turns out Lite.DuckDuckGo does, and for me at least gives vastly better search results.

That just means you prefer Bing search results. DDG simply proxies Bing Search and removes the tracking elements. So you’d get the same search results with Bing… Though Bing may sort those results differently, since they’d use tracking to push certain sponsored results to the top if they think you’d be more interested in them.

parent

[–] Sims@lemmy.ml -5 points 8 months ago

"The malicious script was created in 2023 to attack two Russian-language alternative wiki projects, Wikireality and Cyclopedia."

So this was a US/Ukrainian attack on Russia that backfired ?? Weird 'friendly fire' situation..