How Insecure GitHub Actions Workflows Are Leaking Your Cloud Secrets

TLDR: Many developers inadvertently introduce command injection vulnerabilities into their CI/CD pipelines by passing untrusted user input directly into shell commands. This research demonstrates how these flaws allow attackers to exfiltrate sensitive environment secrets, including cloud provider credentials and API tokens. The newly released tool Raven allows researchers to index and query GitHub Actions workflows at scale to identify these high-impact misconfigurations.

Modern CI/CD pipelines are the crown jewels of the software development lifecycle. They hold the keys to production environments, cloud infrastructure, and container registries. Yet, security teams often treat these pipelines as black boxes, assuming that because they are automated, they are inherently secure. This assumption is dangerous. The reality is that CI/CD platforms like GitHub Actions are highly complex, event-driven environments where a single misconfigured workflow can grant an attacker full control over your entire infrastructure.

The core issue stems from how developers handle user-controlled input within workflow files. When a workflow is triggered by an event like a new issue or a pull request, it often processes data from that event. If a developer takes the title or body of an issue and passes it directly into a shell command without proper sanitization, they create a classic command injection vulnerability. This is not a new concept, but its application within the context of CI/CD is often overlooked because the "application" being attacked is the pipeline itself.

The Mechanics of Pipeline Injection

Consider a workflow designed to automate issue tracking. It might be configured to run whenever a new issue is opened. If the workflow includes a step that prints the issue title using a shell command, it becomes a potential target. The syntax echo ${{ github.event.issue.title }} might look harmless, but if an attacker can control that title, they can inject arbitrary commands.

- name: Print Issue Title
  run: echo ${{ github.event.issue.title }}

An attacker does not need to be a contributor to the repository to exploit this. They simply need to open an issue with a malicious title. By crafting a payload that closes the echo command and executes their own, they can gain execution context within the runner. The real danger arises when you consider the environment variables available to that runner. GitHub Actions runners are often pre-loaded with secrets like AWS_ACCESS_KEY_ID, GCP_SERVICE_ACCOUNT_KEY, or DOCKER_HUB_TOKEN. Once an attacker achieves code execution, they can simply dump these environment variables to an external server.

Scaling the Attack with Raven

Manually auditing thousands of repositories for these patterns is impossible. This is where the research presented at DEF CON 2024 shines. The researchers developed Raven, a tool that automates the discovery of these vulnerabilities. Raven works by downloading workflows from the GitHub ecosystem, indexing them into a Neo4j graph database, and allowing researchers to run complex queries to find dangerous patterns.

By mapping the relationships between workflows, steps, and custom actions, Raven can identify not just direct command injections, but also "dependency chains" where a seemingly secure workflow imports a vulnerable custom action from another repository. This is a critical distinction. You might have a perfectly written workflow, but if it uses a third-party action that contains a vulnerability, your pipeline is still compromised. This falls squarely into the OWASP A03:2021-Injection category, but the impact is amplified by the high-privilege nature of CI/CD environments.

Real-World Impact and Engagement

For a pentester or bug bounty hunter, this is a goldmine. During an engagement, you should focus on repositories that use complex, multi-step workflows. Look for workflows that interact with external inputs or use custom actions from less-reputable sources. If you find a workflow that processes issue titles, pull request comments, or commit messages, test it with simple payloads to see if the input is being sanitized.

The impact of a successful exploit is rarely limited to the repository itself. Because these runners often have broad permissions, a compromise here is frequently a stepping stone to a full cloud account takeover. If you can exfiltrate a service account key, you have effectively bypassed the perimeter. This is why applying the Principle of Least Privilege to your CI/CD configuration is non-negotiable.

Defensive Hardening

Defenders must stop treating pipeline configuration as an afterthought. The most effective mitigation is to avoid passing untrusted input directly into shell commands. Instead, use environment variables to store the input and reference those variables within your scripts. This prevents the shell from interpreting the input as executable code. Furthermore, audit your use of custom actions. If you must use third-party actions, pin them to specific commit SHAs rather than tags or branches to prevent supply chain attacks where a maintainer updates an action with malicious code.

Security researchers have spent years focusing on application-level vulnerabilities, but the infrastructure that builds and deploys those applications is often left wide open. The research on pipeline injection proves that we need to shift our focus toward the CI/CD layer. If you are a researcher, start by using tools like Raven to map the attack surface of your target's public repositories. If you are a developer, audit your workflows today. The next time you see a run: command in a YAML file, ask yourself if that input is truly trusted. If it comes from an external source, assume it is malicious and treat it accordingly. The security of your entire production environment depends on it.