CVE-2026-65820: aeon: pull_request_target CI flaw enables token theft
HIGHaeon, a scikit-learn-compatible time series library, had a GitHub Actions workflow that used pull_request_target and ran fork-controlled code with elevated credentials, which could let an attacker steal the repository token or push to branches. The flaw sits in the project's CI pipeline, not in the library code that runs in your environments, so the immediate risk is to the maintainers and to anyone who consumes aeon builds. There is no CISA KEV listing, no public exploit and no scanner template, and EPSS and CVSS data are not yet available, so the likelihood of mass exploitation is low. The real concern is supply chain: a compromised repository write path could in theory be used to tamper with future releases. Upgrade to aeon 1.5.0, pin dependencies by hash, and verify that your own repositories do not run untrusted fork code under pull_request_target.
What is the risk?
Severity is rated high, but no CVSS vector or EPSS score has been published, and there is no known exploitation or public exploit. Exploitation needs only a malicious fork pull request, which is trivial to submit on a public repository. The impact is confined to the project's CI and repository (token exposure and write access), so downstream organizations are exposed only indirectly through supply chain risk. Risk for typical aeon consumers is low to moderate; for the maintainers, and for any organization copying the same workflow pattern, it is high.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| aeon | — | — | No patch |
Do you use aeon? You're affected.
How severe is it?
What should I do?
1 step1) Upgrade to aeon 1.5.0 or later. 2) Pin aeon and its dependencies to verified versions and hashes, and review changelogs for unexpected changes. 3) Audit your own GitHub workflows for pull_request_target combined with checkout of fork code (head.sha or head.ref), and replace it with pull_request or a split unprivileged/privileged workflow design. 4) Restrict GITHUB_TOKEN to the minimum permissions and avoid auto-commit or push steps on fork branches. 5) Rotate any tokens that may have been exposed to such workflows and review workflow run logs and repository audit logs for unusual pushes. 6) Use SCA tooling to flag aeon versions below 1.5.0.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-65820?
aeon, a scikit-learn-compatible time series library, had a GitHub Actions workflow that used pull_request_target and ran fork-controlled code with elevated credentials, which could let an attacker steal the repository token or push to branches. The flaw sits in the project's CI pipeline, not in the library code that runs in your environments, so the immediate risk is to the maintainers and to anyone who consumes aeon builds. There is no CISA KEV listing, no public exploit and no scanner template, and EPSS and CVSS data are not yet available, so the likelihood of mass exploitation is low. The real concern is supply chain: a compromised repository write path could in theory be used to tamper with future releases. Upgrade to aeon 1.5.0, pin dependencies by hash, and verify that your own repositories do not run untrusted fork code under pull_request_target.
Is CVE-2026-65820 actively exploited?
No confirmed active exploitation of CVE-2026-65820 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-65820?
1) Upgrade to aeon 1.5.0 or later. 2) Pin aeon and its dependencies to verified versions and hashes, and review changelogs for unexpected changes. 3) Audit your own GitHub workflows for pull_request_target combined with checkout of fork code (head.sha or head.ref), and replace it with pull_request or a split unprivileged/privileged workflow design. 4) Restrict GITHUB_TOKEN to the minimum permissions and avoid auto-commit or push steps on fork branches. 5) Rotate any tokens that may have been exposed to such workflows and review workflow run logs and repository audit logs for unusual pushes. 6) Use SCA tooling to flag aeon versions below 1.5.0.
What systems are affected by CVE-2026-65820?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, time series ML pipelines, CI/CD pipelines for ML libraries, open-source ML dependency supply chain.
What is the CVSS score for CVE-2026-65820?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001AI SoftwareAML.T0050Command and Scripting InterpreterAML.T0055Unsecured CredentialsCompliance Controls Affected
What are the technical details?
Original Advisory
aeon is a scikit-learn compatible Python library for learning from time series. Prior to version 1.5.0, a GitHub Actions workflow used pull_request_target for pre-commit checks on pull requests from forks. In this configuration, fork-controlled code could be checked out and executed in a privileged context. The vulnerable workflow also generated/used elevated credentials and could automatically commit or push fixes back to pull request branches. This created a potential token exposure and repository write path if an attacker submitted a malicious fork pull request designed to execute during the privileged workflow run. This issue has been patched in version 1.5.0.
Exploitation Scenario
An attacker forks the aeon repository and modifies files the pre-commit workflow executes, such as a hook configuration or a script. They open a pull request, and the pull_request_target workflow checks out the fork code and runs it with the base repository's privileges. The malicious code exfiltrates the elevated token or pushes changes using it. With write access the attacker could alter code or workflows and attempt to influence a later release consumed by ML pipelines.
Weaknesses (CWE)
CWE-94 — Improper Control of Generation of Code: The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
- [Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
- [Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
Source: MITRE CWE corpus.
References
- github.com/aeon-toolkit/aeon/commit/99261e1355c89a316bf0824bb03f855c6aadae8fx_refsource_MISC
- github.com/aeon-toolkit/aeon/pull/3394x_refsource_MISC
- github.com/aeon-toolkit/aeon/security/advisories/GHSA-mhg2-mc45-wrjrx_refsource_CONFIRM
Timeline
Related Vulnerabilities
CVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply ChainCVE-2024-291210.0BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply ChainCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same attack type: Supply ChainCVE-2025-512010.0smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Supply ChainCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same attack type: Code Execution