CrowdStrike and Google Took Down Glassworm. What Should Developers Check Now?

ByWorkTechJournal Editorial Team

On May 26, 2026 at 14:00 UTC, CrowdStrike’s Counter Adversary Operations team, working with Google and the Shadowserver Foundation, executed a coordinated takedown of the Glassworm botnet — simultaneously striking all four of its command-and-control channels. Glassworm had been operating since at least early 2025, specifically targeting software developers through the open-source supply chain. The takedown is a disruption, not an eradication. Here’s what developers and small teams with developers should understand and check.

What Glassworm was doing

Glassworm targeted software developers because developers are high-value targets. A compromised developer workstation can provide access to source code repositories, cloud platforms, CI/CD pipelines, package registries, and build infrastructure. Compromising one developer can cascade into a supply-chain incident affecting thousands of downstream users.

The campaign used multiple attack vectors. According to CrowdStrike, more than 300 GitHub repositories were poisoned using stolen developer credentials harvested from earlier Glassworm infections — malicious code was force-pushed into default branches. The operation affected Windows, macOS, and Linux systems and deployed a full-featured Node.js remote access tool called GlasswormRAT, along with information theft and credential harvesting capabilities.

Glassworm’s C2 infrastructure was designed for resilience: four distinct channels including a BitTorrent DHT-based configuration system (which has no single point of failure) and Google Calendar event titles used as dead-drop locations for encoded C2 paths. Striking all four channels simultaneously was what made the takedown effective.

What “takedown” means in practice

CrowdStrike describes this as severing the operators from their infected machines and their ability to deliver new malicious payloads. It does not mean every infected machine has been cleaned. It does not mean the threat actors are stopped permanently. It means the operational infrastructure that coordinated the botnet was disrupted as of May 26, 2026.

Machines that were infected before the takedown may still be compromised. Credentials, tokens, and keys captured by the RAT before disruption are still potentially exposed. The actors behind Glassworm can rebuild infrastructure over time.

What to check now

The practical response for developers and small teams with developer access isn’t panic — it’s using this as a forcing function to review hygiene that should already be in place:

Account access:

  • Audit who has admin access to GitHub, GitLab, Bitbucket, or other code hosting accounts
  • Enable MFA or passkeys on all code hosting accounts, cloud consoles, package registries, and CI tools — if it isn’t already on, it should be
  • Remove access for former employees, inactive contractors, or accounts that are no longer needed

Credentials and tokens:

  • Rotate API tokens, deploy keys, and service account credentials that are old, overbroad, or shared
  • Review CI/CD secrets — verify they’re stored in a secrets manager, not hardcoded in configuration files or visible in build logs
  • Audit browser extensions and local development tools for anything you don’t recognize or haven’t updated recently

Package and repository hygiene:

  • If you maintain public packages or open-source repositories, review recent commits for unexpected changes — particularly in default branches
  • Check package publishing permissions: who can publish a new version to npm, PyPI, or other registries you use?
  • Review GitHub Actions or CI permissions for any workflows that have write access to repositories or registries

Endpoint and device coverage:

  • Confirm endpoint protection is running on developer machines — including macOS and Linux, not just Windows
  • If your team uses device management (MDM or similar), verify coverage is current

Who should care most

Highest priority: developers with commit access to public or widely-used packages or libraries; engineers with admin access to cloud infrastructure, package registries, or CI systems; founders or contractors who hold admin credentials across client repositories; and DevOps teams managing shared deployment pipelines.

Lower priority: non-technical team members without code, cloud, or admin access. The supply-chain attack vector Glassworm used doesn’t apply to people who don’t interact with developer tools.

What this doesn’t require

You don’t need to scan for Glassworm-specific indicators unless you have security tooling in place that can do it properly. CrowdStrike has detailed technical information in its Counter Adversary Operations blog post if you have a security team reviewing exposure. For most small teams without dedicated security staff, the checklist above covers the practical response.

This incident is a reminder that open-source supply chain hygiene — careful access management, credential rotation, and monitoring of repository changes — is ongoing work, not a one-time setup task.

Similar Posts