When Your CI/CD Pipeline Leaks: The Quiet Crisis of GitHub Token Disclosure

For most Australian developers, GitHub Actions is the kind of tool you set up once and stop thinking about. You wire up a workflow, paste in a few secrets, and let the runners take care of the boring bits — testing, linting, deploying. The whole point is that you don't have to babysit it.

That convenience is exactly the problem. A run of high-profile incidents over the past year — from the tj-actions/changed-files supply chain compromise to fresh vulnerabilities in AI coding assistants like Copilot, Claude Code and Gemini CLI — has made one thing clear: the automation that ships your software is also the automation that can quietly leak your credentials to the entire internet.

The token that opens every door

Every GitHub Actions workflow runs with an automatically-issued GITHUB_TOKEN. It's a short-lived credential, but during its lifetime it can read code, write to repositories, push container images, comment on pull requests and — depending on permissions — touch production infrastructure. Lose control of it and an attacker doesn't need your password, your 2FA codes, or your SSH keys. They already have the keys to your build system.

The Hacker News recently reported on "RoguePilot," a flaw in GitHub Codespaces that allowed Copilot to leak the GITHUB_TOKEN outright. The attack didn't require a sophisticated zero-day in the runtime. It required the AI assistant to do what AI assistants do: read text and act on it. Once the token is exposed in logs or exfiltrated through an outbound request, the blast radius is the whole repo — and often, every repo the workflow has access to.

This is the part developers consistently underestimate. A leaked token isn't a single-repo problem. In organisations with shared workflows, reusable actions and cross-repo permissions, one compromised pipeline can pivot into dozens of others.

Supply chain: when the action you trust turns hostile

The tj-actions/changed-files incident, documented in detail by Palo Alto Networks' Unit 42, is the canonical example of how modern CI/CD attacks unfold. What looked like a targeted attack on Coinbase expanded into a much wider supply chain compromise affecting any project that pinned a popular third-party action by tag rather than by commit SHA.

The mechanics matter. Most workflows reference actions with something like uses: tj-actions/changed-files@v35. When the attacker pushed a malicious version and re-pointed the tag, every workflow on every repo that didn't pin to an immutable SHA pulled in the poisoned code on its next run. The malicious payload then dumped runner memory — including the GITHUB_TOKEN and any secrets passed into the job — straight into the workflow logs, where it became publicly visible on any open-source repository.

Unit 42's reporting traced the operation back through a chain of compromised dependencies, which is the part that should chill anyone running automation: the attacker didn't need to breach GitHub. They needed to breach one maintainer of one popular action used by thousands of downstream projects.

The new frontier: AI agents and prompt injection

Just as teams started getting serious about pinning actions to commit SHAs and scrubbing logs, a new category of risk arrived: AI coding agents with write access to your repository.

Reporting from Let's Data Science and CyberSecurityNews has detailed how Claude Code, Gemini CLI and GitHub Copilot have all been demonstrated vulnerable to prompt injection delivered through GitHub comments. The attack pattern is almost embarrassingly simple. A malicious user posts an issue or pull request comment containing hidden instructions. When a maintainer triggers an AI agent to summarise the thread, refactor based on feedback, or generate a fix, the agent reads the attacker's instructions as legitimate input — and acts on them.

The actions can include staging commits, opening pull requests, calling out to external URLs (which is how secrets get exfiltrated), or printing the GITHUB_TOKEN into output the attacker can then scrape. CyberSecurityNews' coverage emphasised that this isn't a bug in any one product — it's a structural problem with letting an LLM ingest untrusted text while it's holding privileged credentials.

For Australian teams running lean — solo developers, small agencies, startups that ship constantly — this is the uncomfortable bit. The same productivity boost that makes AI agents irresistible is the thing that gives them dangerous reach.

What an actual audit looks like

The lesson across all these incidents isn't "stop using automation." It's that CI/CD pipelines deserve the same security scrutiny as production. A practical audit covers a few areas:

Why this keeps happening

The underlying issue is that GitHub Actions — and the broader CI/CD ecosystem — was designed for a world where the inputs were trusted. Your code, your config, your dependencies. The assumption was that anything reaching the runner had passed through human eyes.

That assumption no longer holds. Workflows now ingest comments from anonymous internet users, pull dependencies from maintainers you've never spoken to, and hand the keyboard to AI agents that can be manipulated by hidden instructions in a markdown file. The threat model has changed; the default configurations mostly haven't.

What the RoguePilot, tj-actions and AI prompt injection stories all share is a common shape: an automated process holding a powerful credential is convinced to do something its operators never intended. The credential leaks, or the action runs, and by the time anyone notices, the logs are public and the damage is done.

The takeaway for developers

If you maintain anything on GitHub — a side project, a client codebase, an internal tool — block out an afternoon and read through your .github/workflows directory like an attacker would. Look at every uses: line. Check every permissions: block. Find every step that runs on untrusted input. Ask whether the GITHUB_TOKEN in this job really needs the access it has.

Automation is supposed to remove drudgery, not invite it back in the form of incident response. But the security posture of your pipeline is now part of the security posture of your product. Treating CI/CD as plumbing — invisible, ignorable, someone else's problem — is the mindset that keeps producing these headlines.

The tools to harden workflows already exist. The harder part is admitting the pipeline is worth hardening at all.

Related on Bleen

Sources