CVE-2026-22869 is a critical flaw (CVSS 9.8) in the CI workflow of Eigent, a multi agent workforce project. The workflow used the pull_request_target trigger and checked out code from fork pull requests, which let outside code run with repository write access. The advisory lists no patched version, and the fix is a commit.
What's affected
This is a flaw in the project's own repository workflow, in the file .github/workflows/ci.yml, not in a library you import. The GitHub advisory lists the package as a GitHub Actions workflow, with affected versions "before 2026-01-13" and no patched version.
The practical audience is anyone who maintains a repository with a similar workflow. If you only use Eigent, the advisory does not describe a risk to your installation.
How to check if you're exposed
Search your own repositories for the risky combination: a workflow that triggers on pull_request_target and also checks out the pull request head.
grep -rn "pull_request_target" .github/workflows
grep -rn "head.sha\|head.ref" .github/workflows
If one file matches both, read it. Any step after the checkout that runs scripts, installs packages or calls a linter from that code is running attacker controlled content with your token and secrets in reach.
What to do now
- Find every workflow that uses pull_request_target in your organization.
- Stop checking out fork code in those workflows, or move the untrusted steps to the plain pull_request trigger, which runs without secrets.
- Set the default workflow token to read only and grant write permission per job.
- Rotate any token or secret that those workflows could reach if you cannot rule out misuse.
- Review the Eigent fix commit linked in the sources for a worked example.
Why it matters
The advisory classifies this as CWE-94 (Code Injection). The workflow executed code that came from the pull request, so the contributor decided what ran.
pull_request_target exists so that workflows can comment on or label pull requests from forks, and for that reason it runs with write access and secrets. Pairing it with a checkout of untrusted code removes the separation the design depends on. The advisory says a successful attacker can steal credentials, post comments, push code or create releases. Supply chain incidents often start in build pipelines like this, which is why pipeline configuration deserves the same review as application code.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect people who just run Eigent?
The advisory describes a flaw in the project repository CI workflow. It does not describe a risk to installed copies.
What is the safest trigger for fork pull requests?
The plain pull_request trigger, because it does not give fork code write access or secrets.
Sources
Last reviewed: 19 October 2026.
