Exploitable CI/CD Vulnerabilities Expose Millions of Repositories to Hijacking

Security researchers have flagged a critical class of CI/CD pipeline vulnerabilities that expose millions of open-source repositories to supply chain hijacking by unauthenticated attackers. The flaws — present in common workflow configurations across GitHub Actions, Jenkins, and similar platforms — allow attackers to inject malicious code into trusted build and deployment pipelines without needing any credentials.

The disclosure, reported by SecurityWeek, highlights how a single exploitable pattern in a CI/CD workflow definition can give threat actors full control over an affected repository's build artifacts, secrets, and downstream deployments.

What Makes CI/CD Pipelines Vulnerable

At the heart of these vulnerabilities is a dangerous combination of privilege escalation through workflow context and insufficient separation between trusted and untrusted code execution.

The core issue appears in pipeline configurations where:

1. Pull request events trigger privileged workflow contexts — particularly pull_request_target in GitHub Actions, which runs with write permissions on the base repository
2. Attacker-controlled code is checked out and executed in that privileged context
3. Secrets and tokens are available to the running workflow and can be exfiltrated

This pattern allows any external contributor — or an anonymous attacker — to open a pull request containing malicious code, which then executes in a privileged environment. The attacker never needs repository write access; the misconfigured pipeline grants it automatically.

Vulnerable Pattern Example

# DANGEROUS: Privileged event + untrusted code execution
on:
  pull_request_target:     # Runs with write permissions to base repo
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # Checks out ATTACKER code
      - run: npm install    # Executes attacker-controlled package scripts
      - run: npm run build

In this configuration, the pull_request_target event inherits the base repository's secrets and token permissions. When the attacker's fork is checked out, any code in the repository — including malicious npm postinstall scripts — executes with those elevated permissions.

Scale of Exposure

The researchers characterized the exposure as affecting millions of repositories, citing the widespread adoption of these workflow patterns across open-source ecosystems. The vulnerability class is not limited to a single platform:

The breadth of affected configurations means that even well-resourced open-source projects may unknowingly be running exploitable pipelines.

Attack Scenarios

Credential Theft

An attacker submits a pull request to a target project containing a malicious postinstall script in package.json. When the CI pipeline runs npm install in a privileged pull_request_target context, the script executes and exfiltrates:

• GITHUB_TOKEN (repository write access)
• NPM_TOKEN (package publishing access)
• AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (cloud infrastructure)
• SIGNING_KEY (code signing certificate)

Artifact Tampering

With write access to the build environment, an attacker can modify compiled artifacts before they are published to package registries. This is the most dangerous form of supply chain attack — the compromised package appears legitimate, passes all integrity checks, and is distributed to all downstream consumers.

Lateral Movement

A compromised CI/CD token can be used to:

• Push malicious commits to the base repository
• Create or modify releases
• Trigger downstream pipeline jobs
• Access other repositories in the same organization

Which Projects Are at Risk

Any open-source project that:

• Uses pull_request_target in GitHub Actions workflows
• Checks out PR HEAD commits in a privileged workflow context
• Runs npm install, pip install, or similar in privileged contexts without sandboxing
• Exposes organization-level secrets to fork PR pipelines

Should be considered potentially vulnerable until audited.

Detection and Remediation

Immediate Audit Steps

# Search your GitHub Actions workflows for dangerous patterns
grep -r "pull_request_target" .github/workflows/
grep -r "github.event.pull_request.head.sha" .github/workflows/
 
# Check for secret exposure in PR workflows
grep -r "secrets\." .github/workflows/ | grep -i "pull_request"

Safe Workflow Patterns

Approach 1: Separate build from privileged operations

on:
  pull_request:     # Unprivileged — no write access
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4   # Safe — uses PR head automatically
      - run: npm ci && npm run build
      # No secrets needed here

Approach 2: If pull_request_target is required, never check out PR code

on:
  pull_request_target:
 
jobs:
  label:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      # Only operate on PR metadata, never execute PR code
      - uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.addLabels(...)

Additional Hardening

1. Use CODEOWNERS to require review before workflows run on external PRs
2. Enable required workflow approval for first-time contributors in GitHub settings
3. Scope secrets minimally — only expose secrets that are actually needed in each job
4. Use ephemeral environments for build jobs, never share persistent credentials
5. Pin all action references to commit SHA (actions/checkout@abc1234) to prevent action hijacking

Broader Supply Chain Context

This disclosure arrives in a period of heightened supply chain attack activity. Over the past 18 months, CI/CD pipeline compromises have been responsible for some of the most impactful supply chain incidents, including:

• Trivy GitHub Actions breach (March 2026) — 75 tags hijacked to steal CI/CD secrets
• Megalodon attack (May 2026) — 5,561 repositories targeted with malicious CI/CD workflows
• Miasma worm (June 2026) — 73 Microsoft GitHub repositories compromised via supply chain

The pattern in all of these cases is consistent: attackers target the build pipeline rather than the code itself, allowing them to compromise software that is already trusted by downstream consumers.

Recommendations

For maintainers and security teams:

1. Audit all pull_request_target workflows immediately — this is the highest-risk pattern
2. Enable GitHub's required workflow approval for external contributor PRs
3. Treat CI/CD tokens as crown jewels — rotate them regularly and monitor usage
4. Subscribe to security advisories for your CI/CD platform of choice
5. Consider adopting a dedicated build security platform for high-value repositories

Sources

• SecurityWeek — Exploitable CI/CD Vulnerabilities Expose Millions of Repositories

Related Coverage

• Megalodon GitHub Attack Targets 5,561 Repos with Malicious CI/CD Workflows
• GitHub to Disable npm Install Scripts by Default to Stop Supply Chain Attacks
• Trivy Supply Chain Attack Targets CI/CD Secrets