CVE-2026-102739: unsafe NPZ pickle load

CISO Take

ESPectre, an open-source Wi-Fi motion sensing platform for ESP32, shipped analysis tools that load NumPy .npz datasets with pickle support enabled (CWE-502), so a booby-trapped dataset runs attacker code on the machine of whoever analyzes it. The realistic target is a maintainer or contributor who pulls a pull request containing a malicious file under micro-espectre/data and runs one of the documented analysis or ML training scripts. There is no KEV listing, no public exploit, no Nuclei template, and no EPSS data, and the product is a niche sensing project with no tracked downstream dependents, so enterprise-wide exposure is low. The risk is concentrated on developer workstations and CI runners, where stolen credentials, SSH keys, and tokens could become a stepping stone into a wider software supply chain. Upgrade to 3.0.0-rc1, treat datasets from external contributors as untrusted, and avoid running analysis tools on unreviewed PRs outside an isolated environment.

Sources:NVDGitHub AdvisoryATLASgithub.com/francescopace/espectre

What is the risk?

CVSS 7.8 (High), but practical risk is moderate to low for most organizations. Exploitation requires local execution and user interaction: a victim must obtain the malicious .npz and run an affected tool. Complexity is low and no privileges are needed, and crafting a pickle payload is well-known and trivial. There is no evidence of active exploitation (not in KEV, no public exploit, EPSS unavailable) and no tracked dependents. Impact is full compromise of the developer or maintainer account (confidentiality, integrity, availability), and it can extend to source repositories and CI secrets, which makes the supply chain angle the primary concern.

How does the attack unfold?

Initial Access

Attacker submits a pull request or dataset containing a .npz file with an object-typed array holding a pickle payload.

AML.T0010.002

User Execution

A maintainer or developer runs a documented analysis or training tool that loads the NPZ with pickle enabled.

AML.T0011.000

Code Execution

Deserialization executes the attacker's code with the developer's privileges.

AML.T0112.001

Impact

Credentials, source code, and CI tokens are stolen, enabling repository compromise or a downstream supply chain attack.

AML.T0025

Initial Access

Attacker submits a pull request or dataset containing a .npz file with an object-typed array holding a pickle payload.

AML.T0010.002

User Execution

A maintainer or developer runs a documented analysis or training tool that loads the NPZ with pickle enabled.

AML.T0011.000

Code Execution

Deserialization executes the attacker's code with the developer's privileges.

AML.T0112.001

Impact

Credentials, source code, and CI tokens are stolen, enabling repository compromise or a downstream supply chain attack.

AML.T0025

How severe is it?

CVSS 3.1

7.8 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVLocal

ACLow

PRNone

UIRequired

SUnchanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Upgrade ESPectre to 3.0.0-rc1 or later, which disables pickle loading for NPZ datasets (see commit adf495c and PR #154). 2) Review all existing .npz files under micro-espectre/data from untrusted contributors; check for object-dtype arrays, or load them with allow_pickle=False to see whether they fail. 3) Run analysis and training tools on external PRs only in a disposable container or VM with no credentials mounted. 4) Do not run CI jobs that execute dataset-loading scripts on forked-PR content with access to secrets. 5) Detect: grep for allow_pickle=True and np.load usage in internal scripts, scan datasets with pickle scanners such as picklescan or fickling, and monitor developer endpoints for unexpected child processes spawned by Python analysis scripts. 6) Prefer safe formats for shared datasets, such as plain numeric arrays, CSV, or safetensors.

How is it classified?

Code ExecutionSupply ChainModel PoisoningTraining DataFrameworkAML.T0010.002- Data AML.T0011.000- Unsafe AI Artifacts AML.T0019- Publish Poisoned Datasets AML.T0112.001- AI Artifacts

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.7.4-Quality of data for AI systems

NIST AI RMF

MAP 4.1-Risks of third-party software and data are mapped

OWASP LLM Top 10

LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-102739?

ESPectre, an open-source Wi-Fi motion sensing platform for ESP32, shipped analysis tools that load NumPy .npz datasets with pickle support enabled (CWE-502), so a booby-trapped dataset runs attacker code on the machine of whoever analyzes it. The realistic target is a maintainer or contributor who pulls a pull request containing a malicious file under micro-espectre/data and runs one of the documented analysis or ML training scripts. There is no KEV listing, no public exploit, no Nuclei template, and no EPSS data, and the product is a niche sensing project with no tracked downstream dependents, so enterprise-wide exposure is low. The risk is concentrated on developer workstations and CI runners, where stolen credentials, SSH keys, and tokens could become a stepping stone into a wider software supply chain. Upgrade to 3.0.0-rc1, treat datasets from external contributors as untrusted, and avoid running analysis tools on unreviewed PRs outside an isolated environment.

Is CVE-2026-102739 actively exploited?

No confirmed active exploitation of CVE-2026-102739 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-102739?

1) Upgrade ESPectre to 3.0.0-rc1 or later, which disables pickle loading for NPZ datasets (see commit adf495c and PR #154). 2) Review all existing .npz files under micro-espectre/data from untrusted contributors; check for object-dtype arrays, or load them with allow_pickle=False to see whether they fail. 3) Run analysis and training tools on external PRs only in a disposable container or VM with no credentials mounted. 4) Do not run CI jobs that execute dataset-loading scripts on forked-PR content with access to secrets. 5) Detect: grep for allow_pickle=True and np.load usage in internal scripts, scan datasets with pickle scanners such as picklescan or fickling, and monitor developer endpoints for unexpected child processes spawned by Python analysis scripts. 6) Prefer safe formats for shared datasets, such as plain numeric arrays, CSV, or safetensors.

What systems are affected by CVE-2026-102739?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, ML data preprocessing, developer workstations, dataset sharing workflows.

What is the CVSS score for CVE-2026-102739?

CVE-2026-102739 has a CVSS v3.1 base score of 7.8 (HIGH).

What is the AI security impact?

Affected AI Architectures

training pipelinesML data preprocessingdeveloper workstationsdataset sharing workflows

MITRE ATLAS Techniques

AML.T0010.002Data

AML.T0011.000Unsafe AI Artifacts

AML.T0019Publish Poisoned Datasets

AML.T0112.001AI Artifacts

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.7.4

NIST AI RMF: MAP 4.1

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

ESPectre is a Wi-Fi motion sensing platform for ESP32. Prior to 3.0.0-rc1, Micro-ESPectre analysis tools, including tools/6_optimize_filter_params.py, tools/1_analyze_raw_data.py, and tools/10_train_ml_model.py, load NPZ datasets with NumPy pickle support enabled through micro-espectre/tools/csi_utils.py and a direct loader. A malicious dataset contributor or pull-request author can place an object-typed array in a .npz file under micro-espectre/data, causing pickle-controlled code to execute as the maintainer or developer when a documented analysis tool accesses the field. This issue is fixed in version 3.0.0-rc1.

Exploitation Scenario

An attacker opens a pull request to the ESPectre repository adding a plausible new CSI capture dataset as a .npz file. One array is object-typed and holds a pickle payload that executes a shell command on deserialization. A maintainer checks out the branch to validate the data and runs tools/1_analyze_raw_data.py or the ML training script as documented. When the tool accesses the poisoned field, the payload runs with the maintainer's privileges and exfiltrates SSH keys, GitHub tokens, and cloud credentials, or implants a backdoor. The attacker can then use those credentials to push malicious code or releases.

Weaknesses (CWE)

CWE-502Deserialization of Untrusted DataPrimary CWE-502Deserialization of Untrusted Data

CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

[Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
[Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Source: MITRE CWE corpus.