npm and GitHub Actions: a hardening checklist

What changed

Researchers at Bloom Security found that npm trusted publishing identified a repository by its name path, such as owner/repo, until the first successful publish. An attacker could claim an abandoned or renamed repository name, run a publish workflow and receive a publish token for the victim’s package. No stolen credentials were needed. They called the attack SlugFest and counted more than 1,500 vulnerable packages with over 10 million downloads. They reported it on 6 June 2026.

GitHub announced its response on 2 October 2026:

• Trusted publisher settings that have not been validated now expire 48 hours after creation.
• A setting is exempt from expiry after its first successful publish.
• Changing the repository or project identity needs a new trust relationship and a new 48 hour window.
• npm rejects trusted publishing tokens from issue_comment events. The existing restriction on pull_request_target stays.

The checklist

1. Audit your trusted publisher settings. Open every package you publish and check that the repository listed is still one you own. If a repository was renamed, transferred or deleted, remove the binding and create it again.

2. Give the workflow token the least access. Set the default to read only and raise permissions per job.

permissions:
  contents: read

jobs:
  publish:
    permissions:
      contents: read
      id-token: write   # only the publish job needs this

3. Pin third party actions to a full commit SHA. Tags can move. A commit SHA cannot. Take the SHA from the action’s own repository, not from a fork, and let Dependabot update it.

- uses: actions/checkout@<full-length-commit-sha>

4. Never put untrusted text straight into a script. Pull request titles, branch names and issue bodies can contain shell. Pass them through an environment variable and quote it.

- name: Use the title safely
  env:
    TITLE: ${{ github.event.pull_request.title }}
  run: echo "$TITLE"

5. Be careful with pull_request_target and workflow_run. They run with more privilege than a normal pull request. Do not check out code from a fork in a workflow that has secrets.

6. Use OIDC instead of stored cloud keys. Let the workflow get short lived credentials from AWS, Azure or Google Cloud. There is then no long lived key to steal from your repository settings.

7. Rotate secrets when anything looks wrong. If a secret appeared in a log, delete the log and rotate the secret. Treat it as exposed from that moment.

8. Watch publish events. Turn on alerts for unexpected package releases. The earlier you know, the smaller the damage.

How we can help

We review CI/CD pipelines against this list and move them to OIDC, pinned actions and least privilege tokens, usually in one short engagement. Book a call from the button below.