Cache reuse lets one trust domain write state that a later, more privileged job reads as if it were self-generated. That creates a hidden privilege transfer across jobs and branches. The risk rises when runners hold registry credentials, signing material, or cloud tokens, because the poisoned cache can reach a high-value execution context.
Why cache reuse turns deserialization flaws into cross-job trust transfers
Cache reuse matters because it lets one execution context leave behind serialized state that a later context consumes without re-establishing trust. In build systems, that means a poisoned object graph, metadata file, or artifact cache can survive beyond the job that created it and influence a later run that assumed the cache was benign. The bug is no longer confined to one job boundary.
That is what makes deserialization issues more damaging in cached pipelines than in one-off executions. The vulnerable parser is still the entry point, but the cache turns a local corruption event into a replayable trust violation. If the later job has broader permissions, the attacker inherits those permissions through the reused state rather than by compromising the runner directly.
Cache reuse also changes the blast radius. A build step may be able to write to its own workspace safely, but once that workspace is reused by a different branch, environment, or privilege tier, the same bytes can be interpreted in a very different security context. The result is hidden state transfer, not just code execution, and that is why the impact can jump sharply when the cache outlives the job that produced it.
Why privileged build environments make the problem worse
The risk becomes more serious when cached state can influence jobs that hold registry credentials, signing keys, deployment tokens, or cloud access material. In that case, the poisoned cache can affect a stage that has the authority to publish artifacts, sign releases, or reach production systems. The bug then sits on the path to high-value actions, not just on the path to parsing data.
Trust boundaries in CI are often weaker than they look. Teams may assume that branch isolation, ephemeral runners, or job segmentation prevents cross-contamination, but shared caches can bypass that separation if they are mounted or restored too broadly. A deserialization flaw only needs one accepted cache payload to bridge from a low-trust job into a more trusted one.
This is why the same defect often looks minor in a single job and severe in a pipeline. The exploit does not need to win every run, it only needs one poisoned cache entry to be restored by a later job with stronger permissions. If the later job also performs automated release or deployment steps, the cache becomes a persistence and escalation mechanism inside the build process.
What build teams should treat as the real security boundary
The meaningful boundary is not the cache directory itself, it is the trust relationship between the writer and the next reader. If those jobs do not share the same authority, the cache should be treated as untrusted input and constrained accordingly. Separate caches by branch, environment, or privilege tier where possible, and avoid restoring state across jobs that differ in trust or privilege.
Deserialization risk also depends on what the cache can influence after it is read. A harmless cache entry is one that only improves performance; a dangerous one is one that can alter build logic, plugin loading, dependency resolution, signing steps, or deployment behaviour. The more the cached data participates in control flow, the more a deserialization bug can become an execution or authorization problem.
Practitioners should assume that any reused build state may carry attacker-controlled structure unless it is explicitly validated or regenerated. That includes not only obvious artifacts but also metadata, lockfiles, intermediate outputs, and tooling state that later stages implicitly trust. If a pipeline cannot explain why a cached object is safe to rehydrate, it should not be rehydrated at higher privilege.
Risk and Threat Considerations
Cache reuse creates a trust transfer path that adversaries can exploit by seeding malicious serialized state in an unprivileged job and waiting for a more trusted job to restore it. The danger is highest when the restored cache can influence artifact signing, registry publication, or cloud-bound deployment steps.
Failure mechanism: A deserialization bug accepts attacker-shaped cached data, then the next job reuses that data as if it were local and trustworthy, allowing control data or executable state to cross a job boundary without fresh validation.
Impact: The attacker can move from a low-value build context into a higher-value one, potentially reaching credentials, signing material, deployment authority, or other privileged execution paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1552 — Unsecured Credentials | Build cache poisoning is more damaging when it exposes or reuses credentials and signing material. |
| Recommendation — Hunt for credential exposure in reused build state and rotate any material that may have been written to cache. | ||
| SLSA | Supply chain provenance and integrity | Cached build state can alter artifact integrity and provenance across pipeline stages. |
| Recommendation — Separate and verify build state so cached inputs cannot change artifact provenance or release integrity. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Cache reuse can let one job introduce state that changes later trusted builds. |
| Recommendation — Restrict who can modify reusable build state and verify only approved changes reach shared caches. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | The impact increases when cached jobs can reach long-lived registry tokens or signing secrets. |
| Recommendation — Shorten secret lifetime in build systems and prevent long-lived secrets from being reachable through shared caches. | ||
Practitioner Guidance
What to verify: Confirm that cache scope matches trust scope. If a cache can be written by one branch, runner pool, or permission level and read by another, treat it as a security boundary violation until proven otherwise.
Decision rule: If cached content can affect deserialization, code loading, dependency selection, or release actions, prioritize cache partitioning and cache invalidation over performance tuning. A faster cache is not a safe cache if it can bridge trust domains.
What good looks like: The safe state is one where cache contents are either fully segregated by trust level or validated so strictly that a later job cannot inherit authority from the job that produced them. The cache should improve speed, not carry privilege.
Practitioner takeaway: Treat reused build state as untrusted input whenever the producing and consuming jobs do not share the same authority, because the security failure is usually the hidden privilege transfer, not the deserialization bug alone.
Related resources from NHI Mgmt Group
- Why do exposed database services increase the impact of memory disclosure bugs?
- Why do developer build hosts increase the impact of package supply-chain attacks?
- How do build credentials increase the impact of a malicious dependency?
- Why do service accounts behind web applications increase the impact of SSRF-style search bugs?