> Back to All Posts

Coder Cloudflare Breach Delivered Malware to Developers

Coder Cloudflare breach

A trusted software registry spent roughly 14 hours handing out poisoned code, and the developers pulling from it had no reason to suspect a thing. That is the short version of the Coder Cloudflare breach, an attack against a development platform used by Dropbox, Palantir, Square, Mercedes-Benz, and parts of the U.S. government. Attackers never edited a single line in Coder’s public repositories. They went after the delivery route instead.

One clarification matters before going further. Nobody broke into Cloudflare’s own network. The attacker reached Coder’s configuration inside Cloudflare and quietly changed where traffic landed. That is a smaller door, but it worked.

What Happened in the Coder Cloudflare Breach

Coder runs a platform that gives organizations self-hosted cloud development environments. Developers use it to spin up standardized workspaces for building and deploying software, including AI applications. Each workspace gets built from a template, and those templates pull components from registry.coder.com.

That registry became the target. Coder’s Cloudflare breach started when an unidentified actor gained access to the company’s infrastructure there. The attacker then added unauthorized IP addresses to the pool serving the module registry. Cloudflare simply followed its configuration and routed a share of incoming requests to those new addresses.

So some developers reached Coder’s real servers, while others landed on machines run by the attacker. Both groups saw the same domain name and the same successful response. The malicious window ran from 07:35 UTC to 21:45 UTC on Monday, August 31.

Malicious Terraform Modules Did the Real Damage

Terraform modules are prepackaged bundles of instructions for creating and configuring infrastructure. Teams rely on them to avoid writing the same setup logic over and over. Because building infrastructure requires real permissions, these modules run with real permissions too.

The rogue registry served modified versions of those modules. Once executed, they behaved as information stealers and swept each host for anything valuable, including:

  • Provisioner environment variables and secrets
  • Cloud infrastructure and AI tooling API keys
  • CI/CD credentials
  • Configuration file secrets and terminal history
  • User OIDC tokens
  • Configured SSH keys
  • One-time external authentication tokens
  • Coder database passwords when the provisioner ran inside coderd
  • Everything collected went out to coder-infra[.]com, a lookalike domain designed to survive a quick glance at a log file.

Why the Coder Cloudflare Breach Is Hard to Clean Up

Coder said it never passed refresh tokens to the provisioner. The company also found no evidence that the attacker touched customer data under its own control. So far, so reassuring. But the real problem sits somewhere else entirely.

The attacker’s servers were never Coder’s to monitor, so the company has no access to those logs. As a result, it cannot say with any certainty which deployments actually received malicious files. Every affected organization now has to run that investigation on its own.

What Affected Teams Should Do Now

Coder has published fixed releases: 2.37.0, 2.36.4, 2.35.7, and 2.34.9. But a version bump does not undo credential theft. Because the Coder Cloudflare breach handed over live secrets, the cleanup runs considerably wider than patching.

Rotate credentials first

Anyone who pulled modules during the exposure window should rotate every secret on the list above. Speed matters more than certainty here, because a stolen key keeps working until somebody revokes it. Treat exposure as likely rather than waiting for proof.

Then hunt for evidence

Check firewall, proxy, DNS, and VPC flow logs for any connection to coder-infra[.]com. Search provisioner logs for data.external.telemetry, then identify which modules came down during the window. Purge any cached packages that could still be sitting on disk. Coder also released an SQL query that flags potentially affected cached modules and template versions.

Trusting Infrastructure You Cannot See

Most supply chain attacks involve a poisoned package or a hijacked maintainer account. This one worked differently. The code in the repository stayed clean the whole time, and the domain in the request was correct. Only the destination changed.

That is what makes the Coder Cloudflare breach worth attention beyond the developer world. Users trusted a domain. The domain trusted a routing layer, and someone had quietly rewritten that layer. No warning appeared at any point in the chain.

Where a VPN Fits Into the Picture

A VPN would not have stopped this particular attack, since the redirection happened far upstream on Coder’s side. Still, the underlying lesson applies directly to everyday browsing. Most people assume a correct domain name and a padlock icon mean their traffic reaches the right place.

On public networks, that assumption breaks much closer to home. DNS hijacking, rogue hotspots, and man-in-the-middle interception all work by sending correct-looking requests to the wrong destination. The mechanics differ from the Coder Cloudflare breach, but the outcome looks identical to the person sitting at the keyboard.

A reputable VPN encrypts traffic between the device and the provider’s server, and it carries DNS queries through that same protected channel. Services such as NordVPN, ExpressVPN, and Surfshark also block known malicious domains at the DNS level, which catches lookalike addresses like coder-infra[.]com. That does not replace endpoint security, but it removes one of the easier ways to redirect someone quietly.

Final Thoughts

The Coder Cloudflare breach lasted less than a day, yet the fallout could stretch for months. Stolen cloud keys, SSH credentials, and CI/CD tokens open doors that stay open until somebody deliberately closes them. For organizations running Coder, the priority is short and unglamorous: rotate, patch, audit.

Everyone else can still take something broader from it. Security depends on layers of infrastructure that most users never see. Treating the network path as part of the threat model now counts as basic hygiene. Attackers have clearly noticed that the delivery layer is softer than the code itself, and more attempts along these lines seem likely.

Janet Andersen

Janet is an experienced content creator with a strong focus on cybersecurity and online privacy. With extensive experience in the field, she’s passionate about crafting in-depth reviews and guides that help readers make informed decisions about digital security tools. When she’s not managing the site, she loves staying on top of the latest trends in the digital world.