GitHub Actions OIDC and TanStack show why 2026 supply chain attacks target release authority

GitHub Actions OIDC token extraction in the TanStack npm incident is a useful marker for where supply chain compromise has moved in 2026: the target is no longer just a credential, a repository or a developer workstation. The target is release authority. If an attacker can make the legitimate pipeline publish a poisoned package, the ecosystem performs distribution on the attacker's behalf.

That shift changes the defensive problem. A stolen API key can be rotated. A malicious release that passed through the legitimate build path carries the project's reputation with it. It may be versioned, mirrored, cached and installed by automated dependency managers before anyone outside the release path has inspected it. The compromise is not hidden beside the supply chain. It is laundered through it.

The pattern is now visible across several cases. The GitHub advisory for CVE-2026-45321 describes 84 malicious npm package versions published under a trusted publisher identity after GitHub Actions OIDC token extraction and cache poisoning. The Record reported OpenAI warning macOS users after malicious packages affected TanStack-related software. Krebs on Security's reporting on 3CX showed a nested compromise where one supply chain attack fed another. Elastic Security Labs' 2026 work on CI/CD pipeline abuse points at the layer that makes this possible: build systems treated as automation plumbing while quietly deciding what the world installs.

This is not a roundup. The incidents matter because they mark a change in attacker economics. The shortest path to scale is no longer exploitation at the edge. It is control over the systems that turn code into trusted artefacts.

Credentials became a means, not the end

Credential theft used to be described as the outcome of a breach. An attacker stole cloud keys, tokens, browser secrets or VPN credentials, then used them to move further into a victim environment. That model still exists, but it understates what those credentials are worth when they belong to a maintainer, release engineer or CI/CD service account.

A maintainer token is not just access to source code. In many projects it is access to the package namespace, the release workflow, the signing path or the automation that builds production artefacts. A CI/CD credential is worse. It often sits at the intersection of source control, package publishing, cloud deployment and secrets management. It can read the repository, produce the artefact, publish the package and sometimes deploy the service.

CVE-2026-45321 shows the difference. The advisory describes a chain involving pull_request_target misconfiguration, GitHub Actions cache poisoning and runtime OIDC token extraction. The practical result was not merely stolen data. The attacker authenticated publish operations as the legitimate trusted publisher identity and pushed 84 malicious package versions in a six-minute window.

That makes the build pipeline an authority boundary. The source repository may show clean code. The release artefact may not match it. The package registry may show a trusted maintainer. The account or workflow may have been abused. The version number may look routine. The build job that produced it may have pulled a malicious dependency, loaded a poisoned cache or run modified automation from a trusted context.

The older defensive habit is to ask whether a secret was exposed. The better question is what the exposed secret was allowed to decide. If it could decide what becomes a release, then the breach is not limited to the organisation that lost the credential. It can propagate to every downstream consumer that trusts the release channel.

CI/CD is production infrastructure

Elastic Security Labs described CI/CD pipeline abuse as a problem few teams are watching, then published work on detecting abuse across GitHub Actions, GitLab CI and Azure DevOps using signal extraction and LLM-augmented analysis. The defensive framing is useful because it treats CI/CD not as a developer convenience but as an execution environment with production impact.

That distinction matters. CI/CD systems routinely run with broad permissions because they need to build, test, package and deploy. They have access to tokens, signing keys, container registries, package registries, cloud credentials and internal endpoints. They execute third-party actions, plugins, scripts and dependencies. They run on every commit or release. They are both highly privileged and highly programmable.

A compromised pipeline can do three things that ordinary endpoint malware cannot do as cleanly. It can alter an artefact before publication. It can publish under the legitimate project's identity. It can do both inside the normal release process, leaving defenders to distinguish malicious behaviour from automation that was intentionally granted authority.

That is why CI/CD compromise is a trust architecture problem rather than a logging problem. Better logs help, but only if the organisation knows which behaviours are dangerous. A package publish from the official workflow may look correct. A new dependency pulled during build may look ordinary. A signed release may pass verification because the compromised environment had access to the signing material.

The defensive centre of gravity has to move from "did someone steal a credential" to "which systems are authorised to convert code into trusted artefacts". That includes release workflows, build images, CI runners, publishing jobs, signing services and the human accounts that can modify them.

Package poisoning scales differently

A direct intrusion has to find a target, exploit it, maintain access and extract value before being detected. A poisoned package can invert that sequence. The attacker compromises one upstream trust point, publishes once and waits for the dependency graph to pull the payload into environments that would never have been reachable directly.

This is why package ecosystems are so attractive. They are automation systems disguised as convenience layers. Developers do not manually review every transitive dependency update. CI jobs do not stop to ask whether a maintainer's account was compromised this morning. Package managers resolve version ranges. Build tools fetch plugins. Containers pull base images. Agents install tools. The default behaviour is to keep moving.

The TanStack advisory is blunt evidence of the scale. Eighty-four malicious package versions under @tanstack/* did not require eighty-four direct intrusions into downstream users. They required abuse of the trusted publishing path. The Record's reporting added the downstream business context: OpenAI asked macOS users to update after malicious npm packages affected the ecosystem around TanStack.

The point is not that npm is uniquely weak. The point is that package ecosystems are designed to make adoption cheap and propagation automatic. Attackers have noticed.

Package poisoning also creates a measurement problem. Download counts are not compromise counts. The useful distinction is whether the ecosystem allowed untrusted code to enter a trusted execution path with insufficient provenance.

The 3CX lesson was nesting

Krebs on Security's reporting on the 3CX incident remains important because it showed supply chain compromise as a chain, not a single hop. North Korean operators used fake LinkedIn executive accounts and malware disguised as job offers to compromise targets. The 3CX case then became a double supply chain attack, where one compromise helped seed another.

Nested compromise is the natural form of this threat. A developer's workstation can compromise a build system. A build system can compromise a package. A package can compromise downstream CI. Downstream CI can compromise cloud credentials. Those credentials can compromise another project's release process. At each step, the attacker moves from a local foothold to a trust relationship with broader distribution.

The industry still talks about supply chain security as if the chain is linear: vendor, product, customer. Modern software does not look like that. It is a graph of maintainers, dependencies, package registries, CI/CD services, signing systems, plugins, actions, container images, model weights, model code, extension marketplaces and runtime tools. A compromise at any highly connected node can produce effects that do not resemble the original intrusion.

AI tooling extends the package ecosystem

The supply chain problem is no longer limited to conventional packages. AI systems are adding new forms of executable trust: model code, fine-tuning scripts, agent skills, local executors, tool plugins and workflow templates. They behave like packages because users acquire them from an ecosystem, grant them local capability and rarely inspect them deeply.

The arXiv paper "Secret Stealing Attacks on Local LLM Fine-Tuning through Supply-Chain Model Code Backdoors" argues that local offline fine-tuning is not a privacy boundary if the model code itself is compromised. Fine-tuning datasets often contain API keys, identifiers and financial records. Passive pretrained-weight poisoning is poorly suited to sparse high-entropy targets such as secrets, but compromised model code can directly steal them. The relevant lesson is simple: running locally does not make the supply chain local.

A second arXiv paper, "Execution Is the New Attack Surface", describes OpenClaw-style agent stacks where language model intent flows through policy gates and into a local executor. It also notes skill marketplaces and CLI installation as a capability supply chain. That framing is exactly right. Once an agent can install or invoke external capabilities, the trust boundary shifts from the model's answer to the execution path around it.

This matters for package poisoning because AI tools collapse the distance between dependency and action. A conventional library may need to be imported by application code before it matters. A malicious agent skill or local executor plugin may be called because a model selected it. A compromised tool description, installer or template can become a route to filesystem access, credential access or transaction execution.

AI has not invented supply chain compromise. It has added more things that behave like packages and more ways to persuade humans and agents to install them.

Provenance has to cover the build, not just the source

Most software trust still starts with source control. That is understandable, but incomplete. A clean repository is not enough if the build process can be modified, the runner image can be poisoned, the workflow can fetch unpinned actions, the package publishing token can be stolen or the signing key can be used by a compromised job.

Provenance needs to answer a harder set of questions. Which source commit produced this artefact. Which workflow built it. Which runner executed the workflow. Which dependencies, actions, images and tools were used during the build. Which identity authorised publication. Which signing key signed the output. Whether any of those inputs were mutable at the time.

Without those answers, verification becomes ceremonial. A signature proves that someone with signing authority signed the artefact. It does not prove that the artefact came from the reviewed source. A package namespace proves that the upload reached the right registry account. It does not prove that the maintainer intended it. A successful CI job proves that automation ran. It does not prove that the automation was safe.

The strongest supply chain controls are therefore boring and architectural. Separate build and publish authority. Require human approval for release workflow changes. Pin third-party CI components to immutable references. Use ephemeral credentials with narrow scopes. Keep signing keys out of general-purpose runners. Generate provenance at build time and verify it at deploy time. Alert on unusual package publication, new maintainers, changed release workflows and unexpected network access from build jobs.

None of this is glamorous. It is also not optional for projects whose packages are automatically consumed by others.

The trust architecture has to change

The central failure is not that developers trust too much. Software development requires trust. The failure is that the trust is concentrated in mutable, weakly verified places: personal accounts, registry tokens, CI workflows, third-party actions, package names and update channels. Attackers do not need to defeat the whole ecosystem. They need to compromise one authority that the ecosystem already accepts.

A better architecture would reduce the blast radius of any single compromised authority. Maintainer credentials should not be sufficient to publish arbitrary artefacts without provenance. CI systems should not be able to sign releases unless the build inputs match expected policy. Package registries should not treat every upload from the right account as equally trustworthy. Downstream consumers should be able to require provenance, not just a version number.

This is a platform problem as much as a project problem. Individual teams can pin dependencies, review workflows and monitor builds. They should. But the large reduction in risk comes when registries, CI providers and source hosting platforms make the safe path the default path. Most users will not build a custom supply chain security programme. They will accept the defaults and inherit whatever those defaults permit.

The attackers have already moved to the layer where one compromise can become many installations. Defenders are still too often organised around the layer where one alert becomes one incident ticket. That mismatch is the gap package poisoning exploits.

The next serious supply chain compromise will probably not look novel in its mechanics. It will look routine: a maintainer login, a workflow change, a package publish, an automatic install. The uncomfortable part is not that any one of those steps is suspicious. It is that all of them are exactly what the software ecosystem was built to do.