aeon: RCE via eval() in Python Dataset Loading, Patch Released

ZDI-26-469 discloses a code injection vulnerability in the Python aeon library. The use of eval() during dataset loading allows arbitrary remote code execution.

The Trend Micro Zero Day Initiative published advisory ZDI-26-469 on July 29, 2026, documenting a remote code execution vulnerability in the Python aeon library. The flaw resides in the load_human_activity_segmentation_datasets function, where the use of the built-in eval() on unvalidated strings allows an attacker to execute arbitrary Python code in the context of the current process. The issue, reported to the vendor on February 19, was fixed with a commit that replaces eval() with ast.literal_eval() and introduces dedicated error handling.

Key Takeaways

The vulnerability CVE-2026-18286 affects the load_human_activity_segmentation_datasets function of the aeon library, used to load human activity segmentation datasets.
The attack mechanism exploits eval() on user-supplied strings: a malicious CSV file or a manipulated web page can inject arbitrary Python code.
Exploitation requires user interaction: the user must open the malicious file or visit the compromised page for the execution chain to trigger.
The fix commit 7519180 removes eval() and introduces the _parse_np_array() function based on literal_eval(), which evaluates only safe literals; the same patch also addresses load_time_series_segmentation_benchmark and load_rehab_pile_dataset by removing allow_pickle=True from np.load().

How the Injection Works: From CSV to Python Shell

The compromised function handles loading CSV datasets containing human activity segmentations. During parsing, the code encounters strings representing numpy arrays: instead of deserializing them through safe parsers, the library passed the value directly to eval(val). Python's built-in eval() executes any expression arbitrarily in the context of the calling process: an apparently innocuous string like an array representation can contain system function calls, dangerous module imports, or payloads that establish outbound connections.

Advisory ZDI-26-469 describes the cause precisely. The user-supplied string received no validation before being used to execute Python code. This pattern, known in the ecosystem but still recurring, turns a data loading operation — typically considered passive and safe — into an active execution vector. Commit 7519180, verifiable on GitHub, shows the removal of the eval(val) call and its replacement with an internal function wrapping ast.literal_eval() in a try/except block to catch ValueError and SyntaxError.

Why the eval() Pattern Persists in Machine Learning

The use of eval() in Python scientific libraries stems from a legitimate need for convenience: developers must parse complex data structures serialized in text format, and the built-in solution appears immediate. The problem is that this choice blurs the line between data and code, creating attack surfaces where no one looks for them. Data science pipelines — Jupyter notebooks, automated ingestion scripts, dataset sharing platforms — are designed to consume external files without human oversight, which amplifies the risk when loading includes dynamic execution.

The fix commit is not limited to load_human_activity_segmentation_datasets. It applies the same pattern to load_time_series_segmentation_benchmark, where the same eval() logic was replicated. Additionally, it fixes load_rehab_pile_dataset by removing the allow_pickle=True parameter from np.load(): numpy's pickle deserialization is also a known arbitrary execution vector, and its coexistence with eval() in the same loading file suggests a development phase where deserialization security was not an architectural priority.

"The specific flaw exists within the load_human_activity_segmentation_datasets method. The issue results from the lack of proper validation of a user-supplied string before using it to execute Python code." — ZDI-26-469 advisory

What We Know and What the Dossier Does Not Document

Advisory ZDI-26-469 assigns CVE-2026-18286, whose record is reserved on cve.org but not yet populated by the CNA. The dossier does not reveal specific affected aeon versions nor the exact version that introduces the fix. The CVSS score and vector are not explicit in the extracted advisory. There is no evidence of in-the-wild exploitation, nor is the researcher who discovered and reported the vulnerability to the Zero Day Initiative identified. The precise date of GitHub commit 7519180 is not documented in the brief, although the diff content technically confirms the patch mechanism.

The user interaction condition — visiting a malicious page or opening a malicious file — limits the vector but does not eliminate it. In automated data ingestion environments, where scripts process files without supervision, a dataset downloaded from public repositories or received via email can trigger the chain without a human operator recognizing the anomaly. The data science supply chain risk, where datasets and pre-trained models are treated as trusted artifacts, finds concrete confirmation here.

What to Do Now

Verify whether dataset loading pipelines use aeon versions prior to commit 7519180, updating to the release that includes the fix.
Inspect any calls to eval() or literal_eval() in proprietary code that processes external input, replacing the former with the latter where the domain permits.
Assess the origin of automatically loaded datasets, favoring verified sources and implementing static scanning on CSV files before parsing.
Review the use of np.load() with allow_pickle=True in scientific codebases, given that the same aeon patch eliminated this pattern as an additional containment measure.

The story of ZDI-26-469 is not an isolated case of individual oversight, but proof that in machine learning the attack surface shifts from models to the data that feeds them. When a time series library — designed for predictive analytics and classification — becomes a remote execution vehicle due to a single line of eval(), it becomes clear that data science pipeline security requires architectural review, not just point patches. Commit 7519180 closes a specific flaw, but the pattern that generated it persists across multiple repositories in the Python scientific ecosystem.

Frequently Asked Questions

Is aeon a widely used library?

aeon is a toolkit for time series analysis and classification, evolved from tslearn and sktime, used in academic and industrial settings for benchmarking on human activity and sensory signal datasets. Its integration into data science pipelines exposes it to automated loading scenarios.

Why is literal_eval() safer than eval()?

ast.literal_eval() evaluates only expressions composed of Python literals — strings, numbers, tuples, lists, dictionaries, booleans, None — rejecting any function call, import operator, or unresolved name. eval() instead executes arbitrary code in the calling process namespace, with the same privileges as the calling application.

Is CVE-2026-18286 already available with technical details?

At the time of publication, the CVE-2026-18286 record is reserved on cve.org and not yet populated by the assigned CNA. Full technical details are available in advisory ZDI-26-469 and GitHub commit 7519180.

Information has been verified against cited sources and updated at the time of publication.

Sources

Sources and references