Reused workspaces and shared caches preserve filesystem state between jobs, which means a symlink planted earlier can redirect later extraction into another trusted area. That turns a containment bug into a write primitive across build stages. The risk is higher when lower-trust steps, vendoring jobs, or inspection pipelines can shape the destination tree before archive extraction runs.
Why This Matters for Security Teams
Extraction path flaws are rarely isolated bugs when build infrastructure keeps state between runs. Reused CI workspaces and shared caches let one job influence the next, so a path traversal issue can become a cross-stage write primitive rather than a one-off archive mishandling problem. That matters because build outputs often feed signing, packaging, deployment, and artifact promotion. Once a trusted pipeline writes to the wrong location, the blast radius extends beyond the immediate job.
Security teams should treat workspace reuse as a trust boundary decision, not just an efficiency choice. The key question is whether an earlier, lower-trust step can place files, symlinks, or directory entries that later extraction logic will follow. This is why controls around file integrity, separation of duties, and controlled execution paths matter just as much as the extraction library itself. NIST guidance on system and information integrity and least privilege is useful here, especially when mapped to build runners and ephemeral storage practices in NIST SP 800-53 Rev 5 Security and Privacy Controls.
In practice, many security teams encounter this only after a compromised or noisy build job has already shaped the workspace for the next trusted extraction step.
How It Works in Practice
The risk emerges when archive extraction is not happening into a clean, isolated directory. Shared caches, persistent workspaces, and reused runners can preserve symlinks, hard links, directory placeholders, and partially extracted paths between jobs. If the extractor resolves those paths without strict checks, an archive entry that looks harmless in isolation can write outside the intended tree or overwrite files in a trusted location.
This becomes more dangerous in pipelines that mix trust levels. A dependency-mirroring job, linting step, or inspection stage may have enough write access to prepare the workspace, even if it cannot directly modify release artifacts. Later, a packaging or test step extracts a tar, zip, or vendor bundle and inherits that state. The result is not just file corruption. It can affect generated manifests, scripts, configuration, or cached dependencies that downstream jobs trust.
- Use per-job ephemeral workspaces whenever possible.
- Block symlink and hard-link traversal during extraction.
- Reset or isolate caches that can influence archive destinations.
- Run lower-trust jobs in separate runners, users, or namespaces.
- Verify extraction targets against an allowlist of expected paths.
For control mapping, NIST CSF helps teams tie the issue to asset protection, access control, and recovery, while attacker technique references such as MITRE ATT&CK are useful when the flaw is being used to reach higher privilege or broader system impact. Container and build hardening guidance from the CISA Secure Software Development guidance is also relevant when the same workspace is reused across CI, packaging, and image build stages. These controls tend to break down when runners are long-lived and multiple projects share the same filesystem cache because one project can plant state that another project later trusts.
Common Variations and Edge Cases
Tighter workspace isolation often increases build time and cache overhead, requiring organisations to balance pipeline speed against containment. That tradeoff becomes sharper in monorepos, high-frequency release pipelines, and self-hosted CI environments where cache reuse is a major performance lever.
Best practice is evolving, and there is no universal standard for how much cache reuse is acceptable. Some teams can safely keep immutable dependency caches while still forcing per-job scratch directories. Others need to disable shared caches entirely for jobs that unpack untrusted archives or process third-party artifacts. The key distinction is whether the cached data is read-only and provenance-controlled, or whether later jobs can write into the same path and then extract into it.
Edge cases also appear when build systems run inside containers but mount the host workspace or cache volume back into the job. Containerisation alone does not prevent path-flaw abuse if the mounted directory is shared across trust levels. Similarly, code review or inspection jobs may seem safe, yet they can still leave behind filesystem objects that a later trusted step will follow. The practical rule is simple: if a job can shape the extraction destination, it should be treated as part of the attack surface rather than as a harmless preparatory step.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Least privilege limits which jobs can shape shared workspace state. |
| MITRE ATT&CK | T1574 | Hijacked execution flow can occur when extraction follows attacker-shaped filesystem paths. |
| NIST SP 800-53 Rev 5 | SI-7 | Integrity validation helps detect tampered build inputs and workspace state. |
Restrict write access to build paths so one job cannot influence another job's extraction target.
Related resources from NHI Mgmt Group
- Why do shared developer and CI hosts increase the impact of kernel privilege escalation?
- Why do CI test runners increase the impact of command-injection flaws?
- Why do shared API credentials increase the impact of OIDC secret exposure?
- Why do shared privileged credentials increase cloud breach impact?
