CVE-2026-65820: aeon: pull_request_target CI flaw enables token theft

HIGH
Published November 11, 2026
CISO Take

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.

Sources:NVDGitHub AdvisoryATLAS

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?

Initial Access
Attacker submits a malicious fork pull request that triggers the pull_request_target pre-commit workflow.
AML.T0010.001
Execution
The workflow checks out and runs fork-controlled code in a privileged context.
AML.T0050
Credential Access
Malicious code reads and exfiltrates the elevated GitHub token available to the workflow.
AML.T0055
Impact
The attacker uses the repository write path to push changes to branches, creating a risk of tampered code reaching releases.

What systems are affected?

PackageEcosystemVulnerable RangePatched
aeon——No patch

Do you use aeon? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.5%
chance of exploitation in 30 days
Higher than 44% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

1 step
  1. 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.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15-Accuracy, robustness and cybersecurity
ISO 42001
A.10.3-Suppliers
NIST AI RMF
GOVERN 6.1-Third-party AI risk policies

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

training pipelinestime series ML pipelinesCI/CD pipelines for ML librariesopen-source ML dependency supply chain

MITRE ATLAS Techniques

AML.T0010.001AI Software
AML.T0050Command and Scripting Interpreter
AML.T0055Unsecured Credentials

Compliance Controls Affected

EU AI Act: Art. 15
ISO 42001: A.10.3
NIST AI RMF: GOVERN 6.1

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.

Timeline

Published
November 11, 2026
Last Modified
November 12, 2026
First Seen
November 11, 2026

Related Vulnerabilities