If CrowdStrike and Google cut off Glassworm’s command channels, how much poisoned open source code is already sitting inside developer workflows?
CrowdStrike, working with Google and Shadowserver, disrupted the Glassworm botnet, a malware operation used to steal passwords and push malicious code at open source software developers, according to TechCrunch. CrowdStrike said the campaign has targeted the broader open source software supply chain for two years and poisoned more than 300 GitHub code repositories.
“Adversaries are no longer just targeting products, they’re targeting the developers who build them,” CrowdStrike wrote. “Developers represent uniquely high-value targets: compromising a single developer’s workstation can cascade into a supply-chain compromise that impacts thousands of downstream organizations and users.”
How did Glassworm turn developer trust into attack infrastructure?
Glassworm did not rely on one path into developer systems. CrowdStrike said the operators used malicious developer extensions, malvertising, and credentials stolen in earlier hacks to hijack developer accounts and plant malware in code.
That mix matters because it targets the places developers already trust. A sponsored search result can point to malware. A developer marketplace can host a malicious extension. A previously stolen password can reopen a legitimate account and make poisoned code look routine.
CrowdStrike said it took down four command-and-control channels used by Glassworm. That move cut the operators’ access to infected machines and stopped them from delivering more malware, according to the company.
The botnet’s command setup was unusually spread out. CrowdStrike said the channels relied on:
- Solana blockchain: used as part of the botnet’s command-and-control architecture.
- BitTorrent peer-to-peer network: another route for command distribution.
- Google Calendar: a legitimate Google service abused by the operators.
- Virtual private servers: conventional infrastructure supporting the operation.
That combination suggests Glassworm was built to survive simple takedown efforts. If one channel went down, others could keep infected systems reachable. CrowdStrike, Google, and Shadowserver moved against all four at once.
Cybersecurity Dive reported that CrowdStrike led the coordinated disruption on May 26, 2026, and said Glassworm’s operators were likely based in Russia. TechCrunch’s report, however, frames the attribution more cautiously around the cybercriminals behind the botnet. The legal or technical authority behind the takedown remains unclear; CrowdStrike spokesperson Kirsten Speas declined to comment to TechCrunch beyond the company’s blog.
Why are open source developers now the shortest path into companies?
The Glassworm campaign shows the logic behind modern software supply chain attacks: compromise the developer, then let trusted code distribution do the rest.
A developer workstation can hold credentials, access to source repositories, package publishing rights, build systems, and cloud tooling. CrowdStrike’s warning is direct: one compromised workstation can become a route into many downstream organizations and users.
That is why the 300-plus poisoned GitHub repositories are the core number in this case. Glassworm was not just trying to infect isolated endpoints. It was trying to move through the trust companies place in open source code, maintainers, and developer platforms.
The attackers also used stolen credentials from prior hacks. That detail raises the risk for organizations that treat credential rotation as a post-incident cleanup task rather than a standing control. If old credentials still work, attackers do not need an exploit. They can log in.
The use of malvertising adds another pressure point. Developers searching for tools, extensions, packages, or fixes may land on sponsored results that look credible enough to click. MLXIO has tracked that same ad-driven attack surface in other contexts, including Fake Uniswap Google Ads Drain $400K in Wallet Trap, though the Glassworm reporting concerns open source developers rather than crypto wallets.
For Google, the case is also awkward in a narrower way. One Glassworm command channel used Google Calendar, according to CrowdStrike. That does not mean Google Calendar was compromised. It means attackers abused a legitimate service as infrastructure. MLXIO has covered separate Google security scrutiny in Shadow AI Puts Google Cloud AI Security on Trial, but the common thread here is not one product flaw. It is the difficulty of spotting hostile behavior when attackers hide inside normal developer and cloud workflows.
Which systems should security teams inspect before the next Glassworm wave?
The immediate response is not just “remove the malware.” Organizations that rely on open source packages should assume the blast radius may include developer endpoints, package dependencies, commit history, and credentials tied to build or publishing systems.
CrowdStrike said the takedown stopped Glassworm from delivering more malware through the disrupted channels. That is not the same as proving every infected machine is clean or every poisoned repository has been fixed.
Security teams should prioritize checks that match the campaign’s tactics:
- Developer endpoints: Scan machines used for coding, package publishing, and repository administration.
- Credentials: Rotate developer passwords and review credentials reused across repositories, package registries, and internal systems.
- Account activity: Look for suspicious logins tied to developer accounts, especially where credentials may have been stolen in earlier incidents.
- Repository history: Review recent commits, releases, and dependency changes in projects tied to affected developers.
- Package pipelines: Inspect build, publish, and CI/CD activity for unexpected changes or payloads.
- Marketplace exposure: Audit installed developer extensions, especially those sourced from marketplaces where malicious extensions may have appeared.
Those steps are analysis based on the tactics CrowdStrike described. The public reporting does not include a full list of affected projects, a confirmed number of infected developers, or evidence that specific companies were breached through downstream use of poisoned code.
Recent incidents show the pattern is not isolated. TechCrunch reported that last week hackers compromised several open source projects in a separate campaign called “Mini Shai-Hulud,” and that at least two OpenAI developers were compromised. In March, a suspected North Korean hacker hijacked Axios, a popular open source software development tool used by millions of developers.
Which Glassworm answers will take months to surface?
The takedown answers the infrastructure question. It does not settle the exposure question.
The biggest unknown is whether poisoned repositories led to successful intrusions at companies that pulled or ran the affected code. Public reports also do not yet say how many developer machines were infected, how long individual accounts were controlled, or whether stolen credentials were used beyond the open source projects already identified.
Glassworm’s operators may also try to rebuild. CrowdStrike said the disruption cut access to infected computers and stopped more malware delivery through the targeted channels. A botnet operator with stolen credentials, infected hosts, or working social-engineering paths may still have material to work with.
The next useful signals will be concrete: affected package lists, indicators of compromise, repository names, remediation guidance, and any confirmation of downstream corporate breaches. Until then, the practical stance is narrow but urgent: treat developer identity, endpoints, and publishing rights as production infrastructure, not as background IT.
Impact Analysis
- Glassworm shows how compromising developers can spread malware through trusted open source workflows.
- More than 300 GitHub repositories were reportedly poisoned, creating downstream risk for organizations that reuse code.
- Disrupting four command-and-control channels limits the botnet, but already-compromised code and credentials may remain a threat.
