ReleaseLock learn

If GitHub re-enables a compromised Action, is it safe again?

Published November 2, 2026 · Sources checked November 2, 2026 (PT)

In May 2026, two small GitHub Actions that tidy up issues were hijacked, and GitHub disabled them a day later. In September they quietly came back online, still serving the same malware. Nothing about the workflows that used them changed. The lesson: a version tag on an Action is not a lock.

Short answer

No, not by default. Re-enabling a repository restores whatever its tags point to. In September 2026, actions-cool/issues-helper and actions-cool/maintain-one-comment came back with their release tags still pointing to the malicious commits from May 18, so workflows that referenced them by tag ran the payload again (Socket). Pin to a full 40-character commit SHA that you have checked is from before the compromise.

Timeline

How big was the exposure? Socket says GitHub's dependency graph lists about 15,000 dependent repositories for issues-helper alone. That does not mean all of them were compromised, and Socket has not determined how many referenced the Action by a movable tag rather than a pinned commit.

Why disabling didn't clean it

A line like uses: owner/action@v2.2.1 does not mean "version 2.2.1." It means "whatever commit the tag v2.2.1 points to in someone else's repository when this job starts." Disabling that repository hides it, so jobs fail. Re-enabling it brings back exactly what was there, including tags that point to malware.

The tell, as Socket and Software Letters describe it: a workflow that had been failing within seconds suddenly ran for several minutes and succeeded, with no change to its own code. In one example Socket cites, a daily job failed in 8 and 5 seconds on September 14 and 15, then ran for 9 minutes and 34 seconds on September 16.

Why it spread without the attacker

Both Actions handle issue and comment housekeeping, so the workflows that call them usually run daily or whenever someone opens an issue. According to SafeDep, five of the six newly infected repositories were hit through issue bots like these, so the infection could repeat with no further action by the attacker.

SafeDep also found that the payload used the workflow's own token to commit editor hook files for Claude Code and VS Code into the repository. GitHub showed those commits as verified, by github-actions[bot]. A developer who pulled the change and opened the project could run the malware on their own machine. A CI compromise did not stay in CI. For indicators, see SafeDep's post and Socket's post; we do not reproduce them here.

The fix: pin to a full commit SHA, and check when you pinned

A full 40-character commit SHA names one exact commit. The tag can move and the repository can be disabled, re-enabled or hijacked, and your job still runs the same code. Socket and The Hacker News both report that workflows pinned to the full commit SHA of a version from before May 18 were not affected. GitHub's secure use reference recommends full-length SHA pins for third-party Actions.

The pattern, with a version comment so people know what it is:

steps:
  - uses: owner/action@<full-40-character-commit-sha> # v1.2.3

When you pinned matters

A SHA is only as good as the commit it names. If you took the SHA for one of these Actions after May 18, you pinned yourself to the malware. Check that any pinned SHA for either Action comes from before May 18, 2026.

Watch for impostor commits

Software Letters points out that a commit that exists only in a fork can be reachable by its SHA through the original repository, so a pin can look legitimate while pointing at code the maintainer never merged. Tools such as zizmor check for this.

Keep pins fresh

A bare SHA tells nobody which version it is, and a pin nobody updates goes stale. Software Letters suggests a version comment plus Dependabot or Renovate to propose updates as pull requests you review, with a waiting period before brand-new releases.

Do immutable releases solve this?

Partly. If an Action's author turns on immutable releases, a published release's tag is locked to one commit and cannot be moved or deleted while the release exists. That closes the root cause here: tags that could be moved. But only the author can turn it on, and as Software Letters notes, it protects only tags tied to a published release. Tags without a release can still move. As a user, you cannot tell from the uses: line whether the author opted in.

Lock levels for Actions

How you reference itWho controls itWould it have protected you here?
Version tag, like @v2.2.1 or @v3The Action's repositoryNo. The tags were moved in May and still pointed to malware in September.
Full commit SHA you checked is from before the compromiseYouYes, per Socket. A SHA taken after May 18 would not have helped.
Tag on an immutable releaseThe Action's author opts inYes for tags tied to a release, if the author had turned it on before May 18.

Check your repos now

Based on Socket's and Software Letters' advice:

On ReleaseLock today: neither actions-cool Action is in our directory, and /v1/verify returns "not tracked" for both. The ReleaseLock gate can fail any workflow step that is not pinned to a full commit SHA when you turn on its SHA pinning option, which flags tag references like these. It cannot tell you whether a pinned SHA is from before or after a compromise, so that check is still yours.

How this connects to release swaps

The root cause is the same as a GitHub release swap: you depend on a pointer, or a file, in a repository you do not control. See What 2026's GitHub supply-chain incidents show about unlocked releases and Can this GitHub release be swapped?, and look up the tools you install in the ReleaseLock directory.

Quick answers

What happened to actions-cool/issues-helper and maintain-one-comment?

On May 18, 2026, an attacker moved all of their release tags to malicious commits, and GitHub disabled both repositories on May 19. On September 16 they became accessible again with the tags unchanged, so workflows using them by tag ran the payload again until both were disabled again on September 25, according to Socket.

Why did the malware run again in September without the attacker doing anything?

The tags still pointed to the malicious May commits. Once the repositories were reachable, the next scheduled or issue-triggered run of any workflow that referenced them by tag downloaded and ran that code. Socket could not determine why the repositories were re-enabled.

Is a re-enabled GitHub Action safe to use?

Not by default. Re-enabling restores whatever the tags point to. Check what the tags resolve to, or pin to a full commit SHA you have confirmed is from before the compromise.

Does pinning to a commit SHA protect me?

Yes, if the commit you pinned is clean. Socket reports that workflows pinned to the full commit SHA of a version from before May 18, 2026 were not affected. A SHA taken after May 18 pins you to the malware.

Do immutable releases fix moved tags?

For tags tied to a published release, yes: GitHub locks them to one commit. But only the Action's author can turn immutable releases on, and tags without a release can still move.

What should I check in my repos right now?

Search your workflows for both Action names. Rotate every secret any tag-referencing workflow could read, pin or remove the Action, review runs since September 16, and look for unexpected .claude/ or .vscode/tasks.json files committed since then.

Is the tool you install every day still swappable?

Look it up in the directory, or add the free scan step to your workflows.

Search the directory

Sources