Issue

The nf-core pipeline template shipped a GitHub Actions workflows (branch.yml, linting.yml,template-version-comment.yml) that post a comment on pull requests. Because of how it was configured, it ran with access to the repository’s secrets — even for pull requests opened by outside contributors from their own forks. That combination is what made it dangerous.

The same workflow then used an organization-wide bot token to post its comment. An attacker who was already running their own code on the CI machine could capture that token the moment it became available, and then impersonate the nf-core bot anywhere the token reached: pushing commits, posting comments, and more.

In short: anyone on GitHub, with no prior access to nf-core, could open a pull request against an affected pipeline and both run their own code on nf-core’s systems and steal the shared bot token.

This affects pipelines whose default branch contains the vulnerable workflow generated by nf-core/tools 3.0.2 through 4.0.2. Pipelines created with an earlier version may also be affected if they later synchronized the vulnerable workflow from one of those releases. The fix touches the following workflow files:

.github/workflows
! ├── branch.yml (modified)
! ├── linting.yml (modified)
! ├── template-version-comment.yml (modified)
  ├── nf-test.yml (removed)
  └── pr-comment.yml (added)

Resolution

nf-core/tools 4.0.3 fixes this by changing how the comment workflow runs. The step that reads a contributor’s pull request no longer has access to any secrets, and it no longer runs any value taken from their files as a command. Comment posting was also reorganized: the workflows that inspect a pull request now simply save the finished comment text as a file, and a separate, more privileged workflow picks that file up and posts it — without ever checking out or running the contributor’s code. This closes the path to running arbitrary code and stealing the bot token.

The old workflow and its replacement both run using the workflow definition from the repository’s default branch, not from the incoming pull request. Until the fix is merged into the default branch, GitHub keeps running the old, vulnerable workflow for every incoming pull request. Pipeline maintainers should therefore merge the automated patch pull request opened against their default branch as soon as possible (the nf-core infrastructure team will also go through PRs and merge them). No new pipeline release is required after the fix is merged, because it only affects CI workflows and not the actual pipeline code.

Pipelines whose CI workflows have diverged significantly from the template will receive a manual pull request.

Pipelines outside nf-core will not be affected by this vulnerability, except for those that have set their own NF_CORE_BOT_AUTH_TOKEN environment variable on GitHub. In that case, you should apply the changes in the 4.0.3 release.