CVE-2026-22869: Critical CI/CD RCE via GitHub Actions Workflow Misconfiguration

Aegiron 9 mins0

Overview (at a glance)

  • CVE ID: CVE-2026-22869
  • Vulnerability Type: Remote Code Execution (RCE) via CI/CD misconfiguration
  • Affected Component: GitHub Actions workflow configuration
  • Attack Vector: Malicious pull request (PR), typically from a fork
  • CVSS Score: 9.3 – 10.0 (Critical)
  • Severity: Critical
  • Exploitability: High
  • User Interaction Required: Yes (maintainer allows workflow execution on PRs)
  • Privileges Required: Low (attacker only needs ability to open a PR)
  • Exploit Availability: Conceptual and reproducible; no public weaponized exploit released, but exploitation is trivial and well understood
  • Patch Status: Vulnerable by default configuration
  • Patch Urgency: Immediate
  • Root Cause: Unsafe use of pull_request_target combined with execution of untrusted PR code

Executive Summary

CVE-2026-22869 describes a critical CI/CD security flaw caused by an unsafe GitHub Actions workflow configuration. The issue occurs when a workflow is triggered using the pull_request_target event and then checks out or executes code from the pull request itself.

This design mistake allows attacker-controlled code (from a forked repository) to execute with the permissions of the base repository, including access to secrets, write-enabled GITHUB_TOKEN, and repository administration capabilities.

In simple terms:

A contributor can submit a pull request and trick the CI pipeline into running their code as if they were a trusted maintainer.

This leads to full repository compromise, secret theft, supply-chain poisoning, and lateral movement into connected systems.

Why This Vulnerability Is Dangerous

GitHub provides pull_request_target to allow workflows to run in the context of the base repository, not the fork. This is intended for safe actions like labeling, commenting, or policy checks.

However, when developers:

  • check out PR code
  • run build scripts, tests, linters, or shell commands
  • use secrets or elevated tokens

they unintentionally grant attackers a remote execution environment with privileged access.

This vulnerability is not theoretical. The attack pattern is well known, easy to reproduce, and has been abused in the wild in similar incidents.

How Exploitation Works

  1. An attacker forks the target repository.
  2. They submit a pull request containing modified scripts, Makefiles, or workflow-referenced code.
  3. The repository has a GitHub Actions workflow configured with:
    • on: pull_request_target
    • actions/checkout referencing the PR head
    • one or more shell execution steps
  4. When the workflow runs:
    • The attacker’s code executes.
    • It runs with base repository permissions, not fork permissions.
  5. The attacker can now:
    • Read or exfiltrate secrets
    • Use GITHUB_TOKEN to push commits or releases
    • Modify workflows for persistence
    • Upload artifacts containing stolen data
    • Call external servers from the runner

Realistic Impact Scenarios

  • Secret theft: API keys, cloud credentials, signing keys, tokens
  • Repository takeover: Push malicious commits, tags, or releases
  • Supply-chain compromise: Inject backdoors into distributed artifacts
  • Credential pivoting: Use stolen secrets to access cloud, CI, or production
  • Persistence: Modify workflows to maintain future execution

If the repository is widely used, this becomes a downstream supply-chain risk.

MITRE Mapping

CWE

  • CWE-94: Improper Control of Code Generation (Code Injection)
  • CWE-284: Improper Access Control

MITRE ATT&CK Techniques

  • T1059: Command and Scripting Interpreter
  • T1552: Unsecured Credentials
  • T1567: Exfiltration Over Web Services
  • T1195: Supply Chain Compromise
  • T1078: Valid Accounts (abuse of CI tokens)

Proof of Concept

  • No publicly weaponized exploit is released.
  • Exploitation requires no memory corruption, no bypasses, no race conditions.
  • The PoC consists of modifying PR-controlled files that are executed by the workflow.
  • Because this is a configuration flaw, exploitation is deterministic and repeatable.

Any repository with this pattern is exploitable without special tooling.

How to Detect Exploitation or Abuse

Log Sources to Monitor

  1. GitHub Organization Audit Logs
    • Workflow executions
    • Token usage
    • Repository write actions
  2. GitHub Actions Job Logs
    • Shell execution steps
    • Unexpected commands
  3. Self-Hosted Runner Logs (if applicable)
    • Process execution
    • Network connections
  4. Network / Proxy / Firewall Logs
    • Outbound traffic from CI runners
  5. Cloud Provider Audit Logs
    • Access using CI-issued credentials

Suspicious Indicators

  • pull_request_target workflows accessing secrets
  • PR-triggered workflows performing:
    • git push
    • gh api
    • curl / wget to unknown domains
  • Commits or releases created by github-actions unexpectedly
  • Artifact uploads with unusual size or content
  • Workflow files modified shortly after PR activity

Detection Logic

  • Alert when:
    • A pull_request_target workflow checks out PR head code
    • Secrets are accessed during PR-based workflows
    • Write actions occur after PR-triggered jobs
  • Correlate:
    • PR author ≠ repository member
    • Workflow run → secret access → outbound network activity

Immediate Remediation Steps

1. Apply the Official Patch (Required)

Upgrade or patch using the official fix provided by the project maintainers:

🔗 Official Patch / Advisory:
https://github.com/eigenteam/eigent/security/advisories

Always use the vendor-provided patch or commit. Do not attempt partial fixes.

2. Fix Workflow Design

  • Do NOT execute untrusted code under pull_request_target
  • Use pull_request for running tests on PR code
  • Restrict pull_request_target to metadata-only actions (labels, comments)

3. Lock Down Permissions

  • Explicitly define minimal permissions: in workflows
  • Remove write access unless absolutely required
  • Avoid exposing secrets to PR workflows
  • Use environment protection rules

4. Rotate Secrets if Exposure Is Possible

If this workflow existed in production:

  • Assume secrets may be compromised
  • Rotate:
    • API keys
    • Cloud credentials
    • Tokens
  • Invalidate old artifacts

Why This Keeps Happening

This vulnerability is not due to a bug in GitHub itself, but rather:

  • Misunderstanding of GitHub Actions event security
  • Copy-paste CI configurations
  • Lack of CI threat modeling
  • Overprivileged automation

CI/CD systems are production systems and must be treated as such.

Final Takeaway

CVE-2026-22869 is a textbook CI/CD RCE caused by a dangerous but common workflow pattern.
It is:

  • Easy to exploit
  • Hard to notice
  • Extremely impactful

If you maintain GitHub Actions workflows, review every use of pull_request_target immediately.

Aegiron

Backed by 11+ years in cybersecurity and incident response, we decode the latest threats shaping today’s digital battlefield. This blog cuts through the noise with clear insights on vulnerabilities, emerging exploits, and the cyber news defenders can’t afford to miss.