CI is the highest-privilege environment nobody hardens
A privilege comparison worth doing once and never forgetting:
| Environment | Typical privileges |
|---|---|
| The production process | Read/write one database, call a few APIs. Least privilege, carefully reviewed |
| A CI runner | A repo token, every environment's secrets, image push, deploy rights |
CI holds higher privileges than production, and it runs code from more sources: yours, every action you uses, every package in the build, and — if misconfigured — code from a stranger's pull request.
Three misconfigurations, by severity:
(1) pull_request_target plus checking out the PR's code. This is the most serious hole in GitHub CI, and it has its own name: the pwn request. pull_request_target runs the workflow in the base repo's context, so it has secrets — unlike pull_request, which runs in the fork's context with none. It exists so a workflow can label or comment on a PR from a fork. But if you checkout the PR's code inside it, you have just run a stranger's code with your secrets.
(2) ${{ github.event.* }} interpolated into a run block. A PR title, a branch name, a comment body — all set by outsiders, and all interpolated into a shell script before the shell runs. This is command injection, exactly module 3, somewhere that holds deploy privileges.
(3) No permissions declared, so GITHUB_TOKEN gets the repository default. On many older repos that default is write-all. A compromised action using that token can push commits, create releases, and edit workflows.
What all three share: they are configuration rather than code, so they do not appear in ordinary code review and no test catches them.
Comments
Commenting needs an account with at least one completed lesson. That condition is what keeps this thread worth reading: every point belongs to someone who can be asked back, and reputation accrues over time.
You can still read every comment below without an account. Signing in brings you back to this exact spot, not to the top of the page.
Loading comments…