Skip to content

@nx/s3-cache, @nx/gcs-cache, @nx/azure-cache, and @nx/shared-fs-cache are deprecated as of 2026-05-21. The CREEP vulnerability (CVE-2025-36852) affects all four packages. The flaw is in their design and cannot be patched.

These packages use a single credential that grants read and write access across the entire cache. Nothing in the bucket tracks which branch produced which artifact.

An attacker can open a PR off main with no source changes but a modified CI workflow that builds a malicious artifact. The CI workflow isn't part of the cache key, so the PR hashes to the same key that main will hash to. If the PR uploads its artifact first, every later main build with that key gets a cache hit on the poisoned artifact and ships it without rebuilding.

Supply chain attacks against open-source ecosystems are now a near-weekly occurrence, and cache poisoning is a known vector. We have no evidence that these packages have been exploited in the wild, but the design above guarantees that any attempt will succeed. Treat these packages as a live risk and migrate.

The packages stay on npm so existing builds don't break for now. They will not receive updates or security patches, and may be removed in the future.

For information on the vulnerability, see The CREEP vulnerability and build cache security.

  • @nx/s3-cache
  • @nx/gcs-cache
  • @nx/azure-cache
  • @nx/shared-fs-cache
Section titled “Recommended: Migrate to Nx Cloud OR disable remote cache”

Nx Cloud is the best solution for remote cache. It includes a free tier for small teams and requires no infrastructure on your side.

To connect your workspace, see Connect to Nx Cloud. If you need on-premises storage, see Self-hosted caching.

If you cannot use Nx Cloud right now, we recommend disabling remote cache to avoid exploitation of the CREEP vulnerability.

If you have the resources to harden and operate a cache server, you can implement the Nx remote cache OpenAPI specification. The four deprecated packages will not be updated to match that specification.

No. These remote cache packages have not been compromised. The security issue is that bucket-based cache solutions are open to cache poisoning attacks by design.

What should I do if I'm using one of these packages today?

Section titled “What should I do if I'm using one of these packages today?”

Migrate to Nx Cloud, or implement the OpenAPI specification yourself if you have the resources to harden it. The packages stay on npm but will not be patched.

Will these packages receive security patches?

Section titled “Will these packages receive security patches?”

No. The vulnerability is in the design of the packages, not in a fixable bug.

Will the packages be unpublished from npm?

Section titled “Will the packages be unpublished from npm?”

No. They remain on npm for now so existing builds do not break immediately. They will not receive updates.