Critical build cache flaw exposes organizations to production code injection attacks

Security researchers at Nx are reporting a critical vulnerability affecting build systems with remote caching capabilities that could allow any developer with pull request access to inject malicious code directly into production environments. 

The vulnerability is tracked as CVE-2025-36852 (CVSS score 9.4), nicknamed "CREEP" (Cache Race-condition Exploit Enables Poisoning). It exploits a fundamental design flaw in how organizations implement remote caching systems.

The attack vector exploits the "first-to-cache wins" principle common in remote cache implementations. Unlike traditional security vulnerabilities that target specific software components, CREEP abuses the inherent trust relationships between development environments and production systems through shared cache infrastructure. 

The vulnerability allows any contributor with pull request privileges to inject compromised artifacts from an untrusted environment into trusted production environments without detection.

Meet Sarah - A Disgruntled Developer Sarah works at TechCorp and has regular pull request access. She just learned she's being passed over for promotion and decides to plant a backdoor.

Step 1: Setup the Race

• Sarah creates a branch: git checkout -b feature/innocent-update
• She modifies the CI configuration to make her build run faster (fewer checks, parallel steps)
• The legitimate main branch build takes 10 minutes, Sarah's optimized build takes 2 minutes

Step 2: Poison the Cache

• Sarah modifies the build script to inject malicious code during compilation:

  # In her CI config, she adds: 
  - name: "Optimize build tools"   
  run: ./patch-webpack.sh  # This secretly modifies webpack to inject backdoors 
  - name: Build
  run: npm run build       # Same inputs, but now produces poisoned output

• Both builds use identical source files (same hash), but Sarah's produces compromised artifacts
• Sarah's build finishes first and uploads the poisoned artifacts to the shared cache

Step 3: Production Gets Poisoned

• Main branch build starts, calculates the same hash, finds Sarah's "cached" result
• "Great! Cache hit - saves 8 minutes!" thinks the CI system
• Main branch downloads and deploys Sarah's poisoned artifacts to production
• The backdoor is now live in production, but appears to come from the official build

Step 4: Cover Tracks

• Sarah force-pushes to remove her malicious changes: git push --force
• She deletes the branch: git push origin --delete feature/innocent-update
• All evidence vanishes - just looks like a mistaken PR that was quickly closed

Step 5: The Time Bomb

• Two weeks later, Sarah leaves the company on good terms
• Six months later, customer data starts leaking through Sarah's backdoor
• Security investigation finds the backdoor came from "official" build artifacts
• No one connects it to Sarah's deleted PR from months ago

The vulnerability affects a broad range of build systems that utilize bucket-based remote cache solutions such as Amazon S3, Google Cloud Storage, or similar object storage platforms. Remote caching in CI is widely adopted across the software industry to dramatically improve build performance and reduce build times, making this vulnerability particularly widespread in its potential impact. Organizations using popular build tools with remote caching implementations, including both open-source and enterprise solutions, may be vulnerable to this attack vector.

Security researchers at Nx have identified three primary mitigation strategies for organizations to address this vulnerability:

Option 1: Unsafe and Fast - the current default state for most organizations where untrusted environments can write to the cache used by trusted environments, making them vulnerable to CREEP attacks.

Option 2: Safe but Slow - disabling cache writes from untrusted environments entirely, allowing pull requests to read from cache but never write to it, effectively eliminating performance benefits for PR builds.

Option 3: Safe and Fast - Implements a multi-tiered cache system where trusted environments write to a protected cache, each PR gets its own isolated cache namespace, and PRs can read from the trusted cache but write only to their isolated space.

The implementation challenges for Option 3 are significant, as many popular build systems do not offer secure multi-tier caching capabilities. Implementing such systems requires complex integration with both version control and CI systems to detect and prevent PRs from impersonating trusted branches. The researchers note that major build tools across popular stacks and platforms either don't support secure caching or make it inefficient, leaving the majority of organizations unknowingly defaulting to the vulnerable Option 1.