When the update is the attack: what two swapped downloads teach us

Two incidents this month had the same shape. Nobody broke the source code. Nobody broke the build pipeline. Attackers simply swapped what people downloaded, and the update itself became the attack.

What happened

On 19 October, an attacker used a hijacked contributor account on GitHub to replace the download files on five existing releases of the OVHcloud command-line tool, versions 0.11.0 to 0.15.0. The new files were builds designed to steal secrets from the machine that ran them. The attacker even replaced the checksums file so the hashes matched. The swapped files were live for up to 94 minutes before OVHcloud deleted them.

Ten days later, on 29 October, a malicious version 2.1.313 of the Claude Code extension appeared on the Cursor Marketplace under Anthropic's real extension ID. To anyone with auto-update turned on, it looked like a normal update. It added an attacker's key to the user's SSH authorized_keys file, tried to switch on SSH and open a reverse tunnel, and set up persistence through a scheduled task, cron job or LaunchAgent. Cursor says at most 5,000 users installed it before it was pulled, and that the version was not made by Anthropic. How the attackers got it into the marketplace is still not clear.

Why the usual checks didn't help

We tell people to download from the official source. In both cases, they did. The OVHcloud files were on the project's own GitHub release page. The extension came from the editor's own marketplace, under the right name and publisher ID.

We also tell people to check the hash. That only helps if the hash you compare against comes from somewhere the attacker can't reach. OVHcloud's checksums file sat in the same release the attacker controlled, so it was changed too.

What did work is telling. The OVHcloud swap was spotted because one customer's CI job had the SHA-256 of a Linux archive written into its own config. When the file changed, the job failed, and the customer raised it. Homebrew users were also safe, because the Homebrew package had the original hashes pinned. In other words, the protection was a known-good fingerprint stored somewhere else.

What I'd do in a small IT team

1. Know which tools update themselves

Editor extensions, command-line tools with an upgrade command, browser extensions and remote support agents all update quietly. Make a short list of the ones your engineers and developers use. You can't protect what you haven't written down.

2. Pin versions and hashes in anything automated

If a script or pipeline downloads a tool, pin the exact version and the SHA-256, and store that hash in your own repository, not alongside the download. It is a small change, and in the OVHcloud case it is exactly what raised the alarm.

3. Use release attestations where they exist

OVHcloud's fix was to turn on GitHub release immutability and publish a clean v0.16.0 with a release attestation. Their advice is to check downloads with gh release verify-asset. If a project you depend on offers attestations or signed releases, use them. If it doesn't, ask.

4. Slow down auto-update for high-trust tools

For tools that run with your engineers' credentials, consider a short delay before updates go out, or approve them centrally. Both of these incidents were cleaned up within hours, so even a one-day delay would have avoided them. That's a trade-off against getting security fixes quickly, so pick the tools carefully.

5. Check for the signs, then rotate

If someone may have been hit, look for what these attacks leave behind: unknown keys in ~/.ssh/authorized_keys, new scheduled tasks, cron entries or LaunchAgents, and SSH turned on where it shouldn't be. Then do what OVHcloud recommends: treat every secret the machine could read as exposed, and rotate it from a different, clean machine.

The bigger point

None of this is a reason to avoid open source or AI coding tools. Both incidents were found and fixed quickly, partly because the projects work in the open. But "it came from the official place" is no longer enough on its own. The question to ask is: if this download were swapped tomorrow, would anything in my setup notice?

Sources

← All posts