MediumII Cyber Warfare & Critical Infrastructure26 October 2026, Monday
A worm weaponised 42 GitHub repositories by hiding behind oversized files
JFrog reported on 26 October that a worm spreading through npm had planted itself in 42 live GitHub repositories belonging to 11 separate owners. The malicious wrappers were kept at 12.9–13.7 MB to slip past GitHub's code search.
In a report published on 26 October, JFrog researchers wrote that a worm spreading through the npm package registry had embedded itself in 42 live GitHub repositories held by 11 separate owners. The operator's own account hosted a further 17 campaign repositories. The takeover of the repositories appears to have begun in September.
Size is what sets the campaign apart. The malicious wrappers run between 12.9 and 13.7 MB, and each one unpacks the same obfuscated publisher payload. JFrog says that bulk took GitHub's code search and API paths out of play, the very routes that had exposed comparable infections.
The repositories were seeded with execution hooks for AI coding assistants and development environments, configuration files that run code on their own every time the tool opens. Before the installer runs it looks for a virtual machine, a container or a debugger, and exits quietly if it finds one. The worm harvests credentials and carries a component that wipes the victim's home directory if the stolen GitHub token is revoked.
Talay assessment
Bottom line
The campaign exploits no new vulnerability; it exploits a size limit in the scanning infrastructure. Inflating the payload to 13 MB defeats the defence through a constraint of scale rather than signature quality, and that is a structural gap no patch closes. Because the targets are developer machines and continuous integration pipelines, a single infection can travel downstream into published packages. The component that punishes token revocation with deletion is designed to deter victims from cleaning up.
Likely effects
- Package registry oversightNegative1–6 months
Code search and API paths skip large files, which leaves scan-based detection tied to a size threshold that is trivially cleared.
- Developer toolchainNegativeWeeks
Planting hooks in the configuration files of AI coding assistants turns every developer who clones a repository into a direct execution target.
- Incident responseNegativeWeeks
Revoking the stolen token triggers the component that wipes the home directory, so organisations lose data if they sequence the clean-up wrongly.
Possibilities, ranked
- 1Registries impose a size rule40%
GitHub and npm widen scanning coverage to large files or add a size check before publication.
Watch: An announcement from GitHub or npm on code search coverage
- 2The campaign keeps spreading40%
The same operator continues under new package names and the count of compromised repositories rises in November.
Watch: An updated repository count from JFrog or SafeDep
- 3A downstream victim emerges20%
One of the compromised repositories feeds a widely used package and a secondary supply-chain incident is disclosed.
Watch: A poisoned-version advisory on a popular npm package
Probabilities are calibrated judgement based on the sources, not measurement, and are revised as new information arrives. Not investment advice.
Market reaction
Indicators affected
- Weaponised repositories▼ 42 repositories
- Affected repository owners▼ 11 owners
- Wrapper size▼ 12.9–13.7 MB
- Operator's own repositories▼ 17 repositories