A Release Action Became an Agent Worm

On June 24, 2026, attackers compromised codfish/semantic-release-action, force-pushed malicious code, and moved multiple version tags so downstream workflows would execute the attacker’s payload the next time CI ran.

That is the boring part.

The important part is what the payload tried to become.

This was not a one-shot secret stealer. It was built like a propagation system. It targeted GitHub tokens, personal access tokens, package registry credentials, SSH trust paths, and developer AI assistant configuration. It tried to move from CI into repositories, from repositories onto developer machines, and from developer machines into the AI tools that now open codebases, read instructions, and execute commands.

That is the new supply chain problem.

What Actually Changed

The legitimate action was Docker-based. The malicious version switched the action into a composite action and added extra steps that installed Bun and ran a large obfuscated JavaScript payload.

The ugly detail is the execution guard: the injected steps used if: always().

So even if the release step failed, the malware still ran.

The payload also chose Bun on purpose. Many Node security tools rely on Node-specific interception patterns. Switching runtime is a quiet way to slip around assumptions baked into developer security tooling.

This is a recurring supply chain lesson: the malicious change often looks like a small build-system detail, not a giant red flag.

The Kill Chain

The line between CI malware and agent malware is now blurry.

CI has credentials. Agents have autonomy. Developer machines have both trust and reach. An attack that can cross those three environments can turn one compromised action into a multi-stage enterprise foothold.

Why AI Coding Assistants Matter Here

The payload targeted configuration paths for tools including Claude, Codex, Gemini, Copilot, Kiro, OpenCode, Cline, Aider, Tabby, Amazon Q, Cody, Bolt, and Continue.

That list matters because AI coding assistants are becoming developer control planes.

They read repo instructions. They invoke shells. They edit files. They touch secrets by accident. They run inside IDEs, terminals, and cloud workspaces. They also normalize a dangerous behavior: executing project-local instructions as part of the workflow.

That creates a persistence opportunity.

If malware can commit a hidden startup hook into a repository, then the next developer or coding agent that opens the repo may rehydrate the attack outside CI. If it can modify rule files or assistant config, it can shape what the agent believes is normal. If it can hide inside “background task” instructions, it can use the assistant’s trust path against the developer.

This is where old supply chain advice starts to feel incomplete.

Pinning dependencies matters. Rotating tokens matters. Locking down CI matters. But if your coding agent reads project-local rules and executes hooks with developer privileges, repository content itself has become a runtime boundary.

The Failure Was Mutable Trust

The compromised action spread through tags.

Tags feel stable. They look like versions. In practice, a tag is just a reference. If a workflow uses codfish/semantic-release-action@v2, GitHub resolves that reference at runtime. If the tag moved, the workflow runs different code without the downstream repository changing a single line.

That is why “we did not change anything” is no longer a useful incident response answer.

Your dependency graph can change under you.

Your CI runner can execute new code under an old label.

Your agent can follow new instructions from files that look like harmless repo metadata.

What To Do Now

If your organization used codfish/semantic-release-action, assume any workflow that ran after the tag movement needs investigation.

Start with the obvious:

• Disable workflows that reference the compromised action.
• Rotate GitHub tokens, PATs, npm tokens, PyPI credentials, RubyGems credentials, and cloud secrets exposed to affected jobs.
• Review workflow run logs after June 24, 2026 15:39 UTC.
• Search repositories for unexpected .claude, .vscode, .github, assistant rule files, and dependency-update commits.
• Audit GitHub Actions references that use moving tags instead of full commit SHAs.
• Review branch protection and repository rulesets for attacker-created immutability or lockout rules.

Then do the less obvious:

• Treat AI assistant configuration as executable code.
• Block project-local startup hooks unless explicitly approved.
• Put coding agents behind policy that can inspect file reads, shell execution, network egress, and credential access.
• Separate release credentials from general CI.
• Use runtime controls that can stop a build step when it starts reading memory, enumerating secrets, or using GitHub as an exfiltration channel.

The Bigger Pattern

This attack sits at the intersection of three trends:

1. Release automation has production authority.
2. Developer agents execute local context.
3. Supply chain malware is moving from theft to persistence.

That combination is nasty.

The old model was “a malicious package runs during install.” The new model is “a malicious package modifies the repo so the agent keeps running it later.”

That changes the defender’s job.

Security teams cannot stop at static dependency scanning. They need to model how code, config, CI, IDEs, agents, credentials, and package registries interact at runtime. They need to know which systems can write to repos, which agents trust repo instructions, and which tokens can turn one compromised workflow into a publishing pipeline.

The codfish compromise is a warning shot.

Not because the technique is exotic. Because it is practical.

Mutable tags. Release tokens. Repo write access. Project-local agent config. Startup hooks. Trusted GitHub traffic. Package registry credentials.

None of those are fringe components. They are normal developer infrastructure.

That is exactly why this class of attack will keep working.