CVE-2025-36852: Build System Cache Auth Bypass Flaw

CVE-2025-36852 Overview

A critical security vulnerability exists in remote cache extensions for common build systems utilizing bucket-based remote cache (such as those using Amazon S3, Google Cloud Storage, or similar object storage) that allows any contributor with pull request privileges to inject compromised artifacts from an untrusted environment into trusted production environments without detection.

The vulnerability exploits a fundamental design flaw in the "first-to-cache wins" principle, where artifacts built in untrusted environments (feature branches, pull requests) can poison the cache used by trusted environments (protected branches, production deployments). This attack bypasses all traditional security measures including encryption, access controls, and checksum validation because the poisoning occurs during the artifact construction phase, before any security measures are applied.

Critical Impact

Attackers with pull request privileges can inject malicious artifacts into production build caches, enabling supply chain attacks that bypass encryption, access controls, and checksum validation.

Affected Products

• Build systems using Amazon S3 for remote caching
• Build systems using Google Cloud Storage for remote caching
• Build systems using similar bucket-based object storage for remote caching

Discovery Timeline

• 2025-06-10 - CVE CVE-2025-36852 published to NVD
• 2025-06-12 - Last updated in NVD database

Technical Details for CVE-2025-36852

Vulnerability Analysis

This vulnerability represents a fundamental architectural flaw in how build systems handle remote cache artifacts across different trust boundaries. The weakness is classified as CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), which accurately describes how untrusted code execution environments can inject artifacts that are later consumed by trusted environments.

The attack exploits the inherent assumption that all artifacts in a shared cache bucket are equally trustworthy. When a build system retrieves a cached artifact, it validates the artifact's hash matches expectations but cannot determine the trust level of the environment that originally produced the artifact. This allows an attacker with minimal privileges (the ability to open pull requests) to pre-compute and cache malicious artifacts that will be consumed by production builds.

The network-accessible nature of cloud object storage combined with the low complexity of exploitation makes this vulnerability particularly dangerous for organizations using continuous integration and deployment pipelines with shared remote caches.

Root Cause

The root cause is the "first-to-cache wins" design principle combined with the absence of trust boundary separation in remote cache implementations. Build systems assume that if an artifact's hash matches the expected value, the artifact is safe to use. However, this ignores the context in which the artifact was built.

An attacker can craft a pull request that:

1. Modifies source code to produce malicious output
2. Builds and caches the malicious artifact with a hash matching the expected cache key
3. Reverts the malicious changes in subsequent commits

When a trusted build later requests the same cache key, it receives the poisoned artifact without any indication of its malicious origin.

Attack Vector

The attack is conducted over the network through the shared remote cache infrastructure. An attacker with pull request privileges executes the following attack chain:

1. Identify a target artifact in the build system's dependency graph
2. Create a feature branch with malicious modifications to the source code
3. Trigger a build that generates the malicious artifact and caches it to the shared bucket
4. Optionally revert the malicious changes to avoid code review detection
5. Wait for a trusted build (protected branch, release pipeline) to consume the cached artifact

The poisoned artifact is then incorporated into production builds, potentially enabling arbitrary code execution, data exfiltration, or further supply chain compromise. Traditional security controls such as encryption at rest, bucket access policies, and artifact checksum validation provide no protection because the attack occurs during the legitimate build and cache process.

Detection Methods for CVE-2025-36852

Indicators of Compromise

• Unexpected cache hits from artifacts originally built by pull request or feature branch pipelines
• Build artifacts with creation timestamps or metadata indicating origin from untrusted build environments
• Discrepancies between cached artifact contents and expected outputs when rebuilt from source

Detection Strategies

• Implement cache provenance tracking to record the trust level of the environment that produced each cached artifact
• Enable detailed audit logging for all cache read and write operations including source branch and pipeline context
• Deploy integrity verification that compares cached artifacts against freshly-built reference artifacts for critical dependencies
• Monitor for patterns of cache writes followed by immediate reverts in source control

Monitoring Recommendations

• Alert on cache consumption events where the producing environment trust level differs from the consuming environment
• Track pull request build activity that results in cache population for high-value artifacts
• Implement anomaly detection for unusual cache hit patterns across trust boundaries

How to Mitigate CVE-2025-36852

Immediate Actions Required

• Isolate remote caches by trust boundary, ensuring untrusted builds cannot write to caches consumed by trusted environments
• Disable remote caching for production and release pipelines until proper isolation is implemented
• Audit existing cached artifacts to identify any potentially poisoned entries from untrusted sources
• Review recent builds for signs of cache poisoning attacks

Patch Information

Organizations should consult the NX Security Advisory for detailed remediation guidance specific to their build system configuration. The fundamental mitigation requires architectural changes to implement trust-aware caching rather than a simple software patch.

Key remediation approaches include:

• Implementing separate cache buckets for each trust level
• Adding cryptographic attestation of build environment trust to cached artifacts
• Configuring build systems to only consume cache entries from environments at the same or higher trust level

Workarounds

• Configure separate remote cache buckets for pull request builds versus protected branch builds
• Disable remote cache read access for production pipelines, allowing only local or freshly-built artifacts
• Implement manual artifact verification for critical build outputs before production deployment
• Use read-only cache access for untrusted environments, preventing cache poisoning while still benefiting from cache reads

# Example: Configure separate cache buckets by trust level
# Untrusted builds (PRs, feature branches)
export REMOTE_CACHE_BUCKET="s3://my-org-cache-untrusted"
export CACHE_READ_ONLY="false"

# Trusted builds (protected branches, releases)
export REMOTE_CACHE_BUCKET="s3://my-org-cache-trusted"
export CACHE_READ_ONLY="true"  # Only read from trusted cache, do not consume untrusted artifacts