What breaks when a GitHub Action extracts artifacts into the current working directory by default?

If extracted files land in the current working directory, they can overwrite files that the workflow expects to execute. In a privileged CI/CD job, that can let an attacker replace a legitimate script with a malicious one and take over execution. The failure is not the download itself, but the unsafe assumption that extracted content is isolated from executable workflow files.

Why extraction into the working directory is dangerous

When an action expands artifacts into the current working directory, it is not just placing data somewhere nearby. It is writing into the same path space the workflow may use for scripts, helpers, config files, and generated commands. That makes file overwrite the key failure mode, because the extracted content can collide with files the job later trusts and executes.

The real problem is path trust, not decompression. If the workflow assumes that “downloaded” means “separate from code,” an attacker who can influence the artifact can replace a legitimate file with one that the runner will execute with the job’s privileges. In CI/CD, that can turn a routine artifact step into code execution in the pipeline context.

Any writable directory that also contains executable workflow assets creates a collision risk.
Relative paths make the issue worse, because later steps may invoke the overwritten file without noticing the change.
The danger increases when the job has credentials, deployment access, or other privileged runtime context.

Where the control boundary actually belongs

The safe boundary is between untrusted extracted content and executable workflow assets. Good practice is to extract artifacts into a dedicated, non-executable staging directory and then copy only the specific validated files you need into the next step. That keeps the workflow’s scripts and the artifact payload from sharing the same trust boundary.

It also helps to treat the artifact as input that must be inspected before use. If the pipeline expects one file, do not let an extraction step dump a whole tree beside the job scripts. The more files the action creates in the working directory, the more likely it is to overwrite something important or shadow a command name the workflow later calls.

Use an isolated extraction path rather than the workspace root.
Reference workflow scripts by immutable location and name.
Validate extracted paths before moving or invoking them.

Risk and Threat Considerations

This pattern is risky because it gives attacker-controlled content an opportunity to interfere with trusted execution paths. In a privileged CI/CD job, that can become pipeline compromise, secret exposure, or unauthorized deployment if the replaced file is part of the job’s control flow.

Failure mechanism: An extracted file lands in a location where the workflow later looks for code or helpers, so the attacker’s file shadows or overwrites a legitimate one.

Impact: The runner executes attacker-controlled logic with the job’s permissions, which can extend to repository access, deployment credentials, and downstream environment changes.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 8 — Audit Log Management	Workspace overwrites in CI/CD are detectable only with strong job and file-change logging.
	CIS 4 — Secure Configuration of Enterprise Assets and Software	Safe extraction into isolated paths is a secure configuration issue for build and workflow runners.
	CIS 16 — Application Software Security	CI/CD artifact handling is part of application delivery security and integrity protection.
Recommendation — Log artifact extraction and subsequent file execution events for CI/CD jobs. Harden CI/CD runners so untrusted content cannot write into executable workspace paths. Treat build and deployment artifacts as untrusted until validated in a separate location.
OWASP Non-Human Identity Top 10	NHI-03 — Secrets and Credential Hygiene	A compromised workflow can expose CI/CD secrets if overwritten code runs with privileged context.
	NHI-06 — Authorization and Least Privilege	Pipeline compromise becomes worse when the job can act beyond the minimum required privilege.
Recommendation — Keep CI/CD secrets out of steps that process untrusted artifacts. Limit workflow permissions so a malicious step cannot escalate beyond its intended scope.
NIST CSF 2.0	PR.AC — Identity Management, Authentication, and Access Control	The issue is a trust-boundary failure that lets untrusted content influence privileged execution.
	PR.PT — Protective Technology	Isolation of extracted artifacts is a protective design measure for pipeline execution paths.
Recommendation — Separate untrusted artifact handling from privileged workflow execution. Use isolated staging paths and execution boundaries in CI/CD runners.
OWASP Agentic AI Top 10	A4 — Tool Misuse and Unauthorized Action	A workflow step can be coerced into executing attacker-controlled logic through overwritten files.
Recommendation — Prevent untrusted artifacts from altering the tools or scripts a workflow invokes.

Practitioner Guidance

What to verify: Confirm that artifact extraction never targets the workspace root or any directory that contains executable workflow files. The practical test is simple: if the extracted files can change what the next step runs, the extraction location is unsafe.

Decision rule: If a step must handle untrusted or externally influenced content, extract it into a quarantined directory, then promote only the specific validated outputs you intend to use. If you cannot separate content from executable assets, treat the workflow as exposed to code-substitution risk.

Practitioner takeaway: In GitHub Actions, the important control is not “can we unpack the artifact,” but “can unpacked content ever alter what the job executes?” If the answer is yes, the pipeline design is unsafe.