What Happened
Novee Security discovered a vulnerability class named "Cordyceps" that exploits how CI/CD workflows handle external input. This flaw allows attackers to inject malicious code through contributions like pull requests, issues, or commit messages, which CI/CD systems execute with elevated privileges.
The scope was significant: Novee flagged 654 repositories as potentially exploitable and confirmed 300 as fully exploitable. Affected organizations included Microsoft, Google, Apache, Python, and Cloudflare. The attack vector wasn't a zero-day in GitHub Actions or Jenkins—it was a fundamental misunderstanding of where your trust boundary actually sits.
Timeline
Discovery Phase: Novee Security identified the pattern while analyzing how CI/CD platforms parse and execute workflow files referencing external input.
Validation Phase: The research team tested 654 repositories across major open-source projects and confirmed 300 allowed arbitrary code execution through workflow manipulation.
Disclosure: Findings were shared with affected organizations. The vulnerability class affects multiple CI/CD platforms, not a single vendor product.
Current State: Many repositories remain vulnerable because the flaw exists in how developers structure workflows, not in a patchable software component.
Which Controls Failed or Were Missing
Input Validation at the Workflow Level
Your CI/CD workflows treated external input—pull request titles, issue bodies, commit messages—as trusted data. When a workflow references ${{ github.event.issue.title }} directly in a shell command, you've created an injection point. The missing control: treating all external input as potentially hostile, even when it comes through your version control system.
Least Privilege for Workflow Execution
Workflows ran with permissions sufficient to publish packages, modify repositories, and access secrets. The principle of least privilege wasn't applied at the workflow level. A workflow that runs on issue creation shouldn't have the same token scope as one that publishes releases.
Code Review Scope
Your security reviews focused on application code but treated CI/CD configuration as infrastructure. Workflow files received less scrutiny than a ten-line API endpoint. The missing control: treating .github/workflows/, Jenkinsfile, and .gitlab-ci.yml as code that requires security review.
Supply Chain Verification
You verified dependencies in your package.json and requirements.txt but not the actions your workflows execute. Third-party actions run in your CI environment with access to your secrets. The missing control: verifying the integrity and provenance of workflow dependencies.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.2.4 mandates addressing common coding vulnerabilities during software development, including injection flaws. Your CI/CD workflows execute code—they fall under this requirement. If you're building payment applications, your deployment pipeline is in scope.
OWASP Top 10 2021: A03 Injection covers command injection through untrusted data. The fact that the injection point is in your CI configuration rather than your application code doesn't exempt you. The OWASP ASVS v4.0.3 Requirement 5.3.3 states: "Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection." Apply the same logic to shell commands in your workflows.
NIST 800-53 Rev 5 Control SA-15 requires applying security principles to the tools and processes you use to develop software. Your CI/CD platform is a development tool. Control SI-10 (Information Input Validation) applies to all system inputs, including those that trigger automated workflows.
ISO/IEC 27001:2022 Annex A.8.31 addresses environment isolation. If your CI environment can modify production artifacts without additional controls, you've violated the separation principle.
Lessons and Action Items for Your Team
Audit Your Workflow Files Now
Search your repositories for patterns like ${{ github.event.issue.title }}, ${{ github.event.pull_request.body }}, or similar constructs that embed external input into shell commands. These are injection points. You can grep for this:
grep -r "\${{ github.event" .github/workflows/
Do the same for GitLab CI variables and Jenkins parameters that come from external sources.
Implement Input Sanitization at the Workflow Level
When you must use external input in a workflow, sanitize it first. For GitHub Actions, set the value as an environment variable rather than interpolating it directly:
- name: Process issue
env:
ISSUE_TITLE: ${{ github.event.issue.title }}
run: |
echo "Processing: ${ISSUE_TITLE}"
This prevents direct injection but isn't sufficient alone—validate the content matches expected patterns.
Apply Least Privilege to Workflow Tokens
Review the permissions: block in every workflow file. Most workflows don't need write access to contents, packages, or id-token. Start with:
permissions:
contents: read
Grant additional permissions only when you can document why that specific workflow needs them.
Treat Workflow Files as High-Risk Code
Add CI/CD configuration files to your mandatory security review list. A workflow file that runs on external triggers should receive the same scrutiny as authentication code. Include workflow changes in your threat modeling sessions.
Pin Action Versions to Commit SHA
Stop referencing actions by tag:
# Vulnerable to tag manipulation
uses: actions/checkout@v3
# Pinned to specific commit
uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab
Tags can be moved. Commit SHAs cannot. Yes, this makes updates harder—that's the point. You want deliberate, reviewed changes to workflow dependencies.
Implement Workflow Approval Gates
For workflows that publish artifacts, deploy to production, or access sensitive secrets, require manual approval. GitHub Enterprise and GitLab Ultimate support environment protection rules. Use them.
Monitor Workflow Execution Logs
Your SIEM ingests application logs. Does it ingest CI/CD execution logs? Workflow runs that fail input validation, execute unexpected commands, or access secrets outside normal patterns should trigger alerts.
The Cordyceps vulnerability class exists because we treated CI/CD as configuration rather than attack surface. Your deployment pipeline has the same access as your most privileged service account—sometimes more. Secure it accordingly.
