84 Malicious Packages With Valid Provenance

On May 11, 2026, 84 malicious npm package artifacts appeared in the @tanstack namespace, each with valid SLSA provenance signatures. These packages were released through TanStack's own pipeline. For several hours, developers who checked provenance before installing dependencies saw no red flags.

This wasn't a case of compromised credentials. Instead, TeamPCP, the threat group behind this attack, exploited a GitHub Actions misconfiguration to hijack a legitimate build process and publish malware with cryptographic proof of origin.

Attack Timeline

May 11, 2026:

• An attacker opened a pull request against the TanStack repository.
• The GitHub Actions workflow triggered via the pull_request_target event.
• Attacker-controlled code executed in the base repository's security context.
• The workflow published 84 malicious artifacts across 42 packages in the @tanstack namespace.
• Each package received valid Sigstore certificates and SLSA provenance attestations.
• Packages remained available on the npm registry until detection and removal.

Failed Controls

Pipeline Isolation: The TanStack repository used pull_request_target as a workflow trigger. This feature runs workflow code in the context of the base branch, allowing untrusted code from a fork to execute with trusted permissions. The workflow should have isolated untrusted inputs but instead allowed attacker-controlled code to reach the npm publishing step with full repository credentials.

Provenance Validation Scope: SLSA provenance verified that packages came from TanStack's GitHub repository using TanStack's workflow. However, it couldn't verify whether the code in those packages matched what TanStack maintainers intended to ship. Provenance proves "this artifact came from this build," not "this artifact contains safe code."

Pre-publish Review: No manual review gate existed between workflow execution and package publication. Once the malicious workflow ran, it had direct publishing access. Organizations often skip review for "trusted" automated pipelines, assuming the pipeline itself provides sufficient control.

Dependency Pinning Downstream: Organizations consuming @tanstack packages likely pulled the latest versions automatically. Without version pinning or additional verification steps, they ingested the malicious artifacts as soon as they appeared.

Standards and Requirements

NIST 800-53 Rev 5 addresses supply chain risk in multiple controls:

• SR-3 (Supply Chain Controls and Processes): Establish processes to ensure the integrity of system components throughout the supply chain, including verification mechanisms beyond single-factor attestations.
• SR-4 (Provenance): While this control requires tracking component provenance, it notes that provenance alone doesn't guarantee integrity. Additional assurance mechanisms are needed.
• SA-10 (Developer Configuration Management): Implement configuration management that includes protection from unauthorized modification during the build process. The GitHub Actions misconfiguration violated this requirement.

The SLSA Framework acknowledges limitations. SLSA Level 3 requires source provenance tracking, build process isolation, and non-falsifiable provenance. However, it states that provenance "does not guarantee the artifact is free from vulnerabilities."

ISO/IEC 27001:2022 requires secure development lifecycle controls:

• Annex A 8.25 (Secure development lifecycle): Integrate security throughout development, including validation of inputs and protection of system engineering processes.
• Annex A 8.31 (Separation of development, test, and production environments): The attack succeeded partly because the boundary between untrusted input and trusted execution collapsed.

Lessons and Action Items

1. Audit pull_request_target Workflows

Search your .github/workflows directory for pull_request_target triggers. For each one:

• Document why it needs base branch context.
• Verify it never executes untrusted code from the PR.
• If it must run PR code, use a separate workflow with pull_request trigger and no publishing permissions.

Replace this pattern:

on: pull_request_target

With explicit isolation:

on:
  pull_request:
    types: [labeled]
  # Only run when maintainer adds 'safe-to-test' label

2. Add a Verification Layer Beyond Provenance

Provenance tells you where a package came from. You need additional checks for what it contains:

• Compare published artifact hashes against your own build from source.
• Run static analysis on packages before deployment.
• Maintain an allowlist of known-good versions, not just known-good publishers.

For critical dependencies, build from source in your own pipeline rather than pulling pre-built artifacts.

3. Implement Manual Gates for Publishing Workflows

Add a human checkpoint before publication:

• Require explicit approval from two maintainers for any npm publish action.
• Use GitHub Environments with required reviewers for publishing steps.
• Separate "build and test" workflows (automated) from "publish" workflows (manual trigger).

4. Pin Dependency Versions and Audit Changes

In your package.json and lock files:

• Pin exact versions, not ranges (use 1.2.3 not ^1.2.3).
• Review lock file changes in every PR, especially unexpected updates.
• Run npm audit signatures to verify package signatures.
• Subscribe to security advisories for your direct dependencies.

5. Map Your SLSA Assumptions

Document what SLSA provenance actually proves in your environment and what it doesn't:

• Provenance verifies: Build source, build platform, build parameters.
• Provenance doesn't verify: Code safety, maintainer intent, absence of vulnerabilities.

Add controls that cover the gaps. Treat provenance as one input to your trust decision, not the entire decision.

6. Test Your Incident Response for Supply Chain Compromises

Run a tabletop exercise: "We discover that a dependency we've been using for six weeks contained malicious code. What do we do?"

• How quickly can you identify affected systems?
• Can you roll back to a known-good version?
• Do you have logs showing what the malicious code accessed?
• Who needs to be notified (customers, auditors, regulators)?

This attack succeeded because it exploited the gap between "cryptographically verified" and "actually safe." Your supply chain security can't rely on any single verification mechanism. Build defense in depth, starting with the action items above.