The pin you stopped reading

crimsondhaks — Wed, 02 Sep 2026 11:57:10 +0000

In March 2025 an attacker compromised tj-actions/changed-files and rewrote its
release tags to point at malicious code. The injected code dumped runner memory
into workflow logs, which on a public repository means printing your secrets
where anyone can read them. Around 23,000 repositories depended on that action,
most of them through a mutable tag like @v45.

Repositories that had pinned the action to a commit SHA were unaffected. That is
worth sitting with for a moment, because it is rare for a security practice to
draw such a clean line through a real incident. The advice worked exactly as
advertised.

So we all pinned. And then we quietly undid it.

What pinning actually buys you

uses: actions/checkout@v5 means "run whatever v5 points at when this
workflow starts". The tag is a pointer the upstream author can move at any time,
and nothing about your repository changes when they do. You are trusting the tag
to keep meaning what it meant when you wrote the line.

uses: actions/checkout@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09 means "run
this exact commit". Nobody can repoint it. If the upstream repository is
compromised tomorrow, your workflow keeps running the code you reviewed.

That is the entire mechanism. It is not clever, and that is its strength.

The part nobody mentions

A pin is a snapshot, and snapshots go stale. The action you froze in March has
since fixed bugs, gained features, and patched its own vulnerabilities, and you
are running none of it. So you enable Dependabot, which is exactly the right
call — an un-updated pin is its own risk.

Now look at what arrives in your pull request queue:

- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8
+ uses: actions/checkout@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09

What changed? You cannot tell. Not because you are careless — because the diff
contains no information. Two hex strings differ. That is the whole change.

GitHub's own engineering blog describes a repository where
roughly one in six commits were Dependabot version bumps,
61 of them in twelve months, sometimes several in a single day. Nobody
meaningfully reviews an opaque hash 61 times a year. You approve it, because the
alternative is manually diffing a third-party repository before every merge, and
nobody has budgeted for that.

One maintainer put it plainly on her own blog, admitting she
blindly accepts Dependabot pull requests and noting this negates the benefit of pinning.
That is not a confession of bad practice. It is an accurate description of what
the workflow makes people do.

So the pin is still in the file. The review it depends on is gone. You are
running unreviewed third-party code with your credentials, with a line in your
YAML that looks like diligence.

It gets slightly worse

Two details make this sharper than it first appears.

Dependabot Alerts do not cover SHA-pinned actions. Users have been
asking GitHub to fix this asymmetry
for a while. You are told to pin, then told to enable version updates to combat
staleness, and the alerting that would tell you a pinned action has a known
vulnerability does not apply to the form you were told to use.

The version comment is not verified by anything. Tooling writes bumps like
this:

uses: actions/checkout@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09 # v5.1.0

That line makes two claims. First, run this commit — GitHub enforces it. Second,
this commit is v5.1.0 — nothing enforces it at all. It is a comment. Your eyes
read v5.1.0 and move on, and the only thing GitHub cares about is the hash.

Those two claims agreeing is precisely what a retagged release breaks. In the
tj-actions incident the tags were moved; the SHAs were not. If a pin's comment
says v5.1.0 and the v5.1.0 tag now resolves to a different commit, something
worth knowing has happened — either your pin is stale, or the tag moved under
you. That check takes one API call, and almost nobody performs it.

This is not a niche concern

GitHub reported
11.5 billion Actions minutes used in 2025, up 35% year over year.
Datadog's security research found that
two out of three organizations have at least one vulnerability in an Actions workflow.

And the incidents kept coming after tj-actions. In May 2026 a threat group
compromised 5,561 public repositories in about six hours
by pushing workflows carrying dormant workflow_dispatch backdoors. TanStack's
router was breached through
cache poisoning that led to OIDC token theft and 84 malicious npm packages.

Attackers moved to CI because CI holds credentials, runs on every push, and is
reviewed less carefully than application code. Workflow files are code with
production access that we treat as configuration.

Sources above were paraphrased; content was rephrased for compliance with
licensing restrictions.

What would actually help

Not "review your Dependabot PRs more carefully." That advice has been available
the whole time and it loses to arithmetic: 61 bumps a year against a finite
attention budget.

What helps is making the diff contain information again. When a pin moves, the
questions worth answering are mechanical, and mechanical questions can be
answered mechanically:

Does the new commit exist in any tag or branch upstream, or is it floating outside published history?
If the pin claims a version, does that tag still resolve to this commit?
Did the action's declared interface change — inputs, outputs, required flags?
Did its execution model change, for instance a JavaScript action becoming a Docker action that can pull an arbitrary image?
Did it gain network calls, secret references, or dynamic code execution that it did not have before?

None of that requires judgment. It requires fetching two revisions and
comparing them, which is a thing a computer should do for you before you click
approve.

Two honest caveats

No static check can be certain. An action that builds a resource name at
runtime could reach anything, and a tool claiming certainty there is lying. The
right behaviour is to say what could not be determined rather than stay quiet.

A clean report is not a safety guarantee. It means the reviewable surface
did not change in a way worth flagging. A sufficiently careful attacker can stay
below that line. This raises the cost of an attack; it does not eliminate it.

The point

Pinning to a SHA is still correct. Keep doing it.

But recognise what it is: a mechanism that converts a trust problem into a
review problem. It only pays out if the review happens, and we built a workflow
that guarantees it does not. The pin in your YAML is not protection. It is a
place where protection could go, if something were reading it.

I wrote action-diff to do the
comparison above — it reads both revisions of a bumped action and reports what
changed, including whether the pin's claimed version still resolves to the
commit it names. It is MIT licensed and runs as a GitHub Action or a CLI.

Use it, use something else, or write your own. The tooling matters much less
than noticing that a practice we all adopted has quietly stopped working.

DEV Community: crimsondhaks