CVE-2024-39700: JupyterLab extension-template: CI workflow RCE

CRITICAL

Published July 16, 2024

CISO Take

The JupyterLab extension template generates a GitHub Actions workflow (update-integration-tests.yml) that contains a code injection flaw. Anyone who can open a pull request against a repository built from the template can run arbitrary commands in its CI. This is rated CVSS 10.0 (critical) because the workflow runs with repository-level privileges and can reach secrets and publishing credentials. The package has 1,881 downstream dependents and 46 other CVEs, and its OpenSSF Scorecard is a middling 5.8/10. It is not in CISA KEV, no public exploit or Nuclei template is known, and EPSS and SSVC data are unavailable, so there is no evidence of active exploitation. Have extension authors upgrade the template to the latest version, accept the overwrite of update-integration-tests.yml and re-apply local changes afterwards. They should also rebase open PRs from untrusted contributors and audit CI logs and repository secrets for signs of tampering.

Sources:NVDGitHub AdvisoryATLASOpenSSF

What is the risk?

Severity is critical on paper (CVSS 10.0, network, low complexity, low privileges, no user interaction, scope changed). Real-world exploitability depends on the repository accepting PRs from external contributors, which is the norm for open-source extensions. No public exploit, scanner template or KEV listing exists, and EPSS is not available, so the exploitation likelihood is unquantified. The main exposure is the CI/CD supply chain rather than runtime AI systems: stolen tokens or publishing credentials could lead to compromised PyPI or npm releases of JupyterLab extensions. Existing PRs may still run the vulnerable workflow version from the main branch, so patching alone does not close the window.

How does the attack unfold?

Initial Access

Attacker opens a pull request to a public repository built from the extension template, carrying a crafted payload in an attacker-controlled field.

AML.T0049

Execution

The vulnerable update-integration-tests.yml workflow interpolates the payload and runs arbitrary commands on the GitHub Actions runner.

AML.T0050

Credential Access

Injected commands read the GITHUB_TOKEN and repository secrets, including package registry publishing tokens.

Impact

Attacker pushes or publishes a trojanized extension release that executes in downstream JupyterLab environments.

AML.T0010.001

Initial Access

Attacker opens a pull request to a public repository built from the extension template, carrying a crafted payload in an attacker-controlled field.

AML.T0049

Execution

The vulnerable update-integration-tests.yml workflow interpolates the payload and runs arbitrary commands on the GitHub Actions runner.

AML.T0050

Credential Access

Injected commands read the GITHUB_TOKEN and repository secrets, including package registry publishing tokens.

Impact

Attacker pushes or publishes a trojanized extension release that executes in downstream JupyterLab environments.

AML.T0010.001

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	—	No patch
13.5KOpenSSF 5.81.9K dependentsPushed 4d ago56% patched~28d to patchFull package profile →

Do you use Jupyter? You're affected.

How severe is it?

CVSS 3.1

10.0 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SChanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Upgrade repositories to the latest extension-template version using copier update; accept the overwrite of update-integration-tests.yml and re-apply any custom changes afterward. 2) Temporarily disable GitHub Actions while upgrading. 3) Rebase all open PRs from untrusted users, since Actions may run the main-branch workflow version from the time the PR was created. 4) If upgrading from a template version older than 4.3.0, consider leaving out the proposed release workflow changes until the extra configuration is ready. 5) Rotate secrets, PyPI/npm tokens and deploy keys for any repo that ran the vulnerable workflow with external PRs. 6) Detect: review the Actions run history and logs for unexpected commands, outbound connections or workflow runs triggered by unknown contributors, and check for unauthorized commits or releases. 7) Harden: restrict workflow token permissions to read-only by default and require approval for workflow runs from first-time contributors.

How is it classified?

Code ExecutionSupply ChainPluginFrameworkAML.T0010.001- AI Software AML.T0049- Exploit Public-Facing Application AML.T0050- Command and Scripting Interpreter

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.10.3-Suppliers

NIST AI RMF

GOVERN 6.1-Policies and procedures address AI risks arising from third-party software and data

OWASP LLM Top 10

LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2024-39700?

Is CVE-2024-39700 actively exploited?

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

How to fix CVE-2024-39700?

1) Upgrade repositories to the latest extension-template version using copier update; accept the overwrite of update-integration-tests.yml and re-apply any custom changes afterward. 2) Temporarily disable GitHub Actions while upgrading. 3) Rebase all open PRs from untrusted users, since Actions may run the main-branch workflow version from the time the PR was created. 4) If upgrading from a template version older than 4.3.0, consider leaving out the proposed release workflow changes until the extra configuration is ready. 5) Rotate secrets, PyPI/npm tokens and deploy keys for any repo that ran the vulnerable workflow with external PRs. 6) Detect: review the Actions run history and logs for unexpected commands, outbound connections or workflow runs triggered by unknown contributors, and check for unauthorized commits or releases. 7) Harden: restrict workflow token permissions to read-only by default and require approval for workflow runs from first-time contributors.

What systems are affected by CVE-2024-39700?

This vulnerability affects the following AI/ML architecture patterns: CI/CD pipelines, Jupyter notebook environments, ML development workflows, AI software supply chain.

What is the CVSS score for CVE-2024-39700?

CVE-2024-39700 has a CVSS v3.1 base score of 10.0 (CRITICAL).

What is the AI security impact?

Affected AI Architectures

CI/CD pipelinesJupyter notebook environmentsML development workflowsAI software supply chain

MITRE ATLAS Techniques

AML.T0010.001AI Software

AML.T0049Exploit Public-Facing Application

AML.T0050Command and Scripting Interpreter

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.10.3

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

JupyterLab extension template is a `copier` template for JupyterLab extensions. Repositories created using this template with `test` option include `update-integration-tests.yml` workflow which has an RCE vulnerability. Extension authors hosting their code on GitHub are urged to upgrade the template to the latest version. Users who made changes to `update-integration-tests.yml`, accept overwriting of this file and re-apply your changes later. Users may wish to temporarily disable GitHub Actions while working on the upgrade. We recommend rebasing all open pull requests from untrusted users as actions may run using the version from the `main` branch at the time when the pull request was created. Users who are upgrading from template version prior to 4.3.0 may wish to leave out proposed changes to the release workflow for now as it requires additional configuration.

Exploitation Scenario

An attacker forks a public JupyterLab extension repository created from the template and opens a pull request with a crafted branch name, title or file content that carries shell payload text. The vulnerable update-integration-tests.yml workflow interpolates that attacker-controlled value into a command and executes it on the runner. The payload reads the workflow's GITHUB_TOKEN and any repository secrets, such as PyPI or npm publishing tokens. The attacker then pushes a trojanized release of the extension, which runs in the JupyterLab environments of data scientists and ML engineers who install or update it.

Weaknesses (CWE)

CWE-94Improper Control of Generation of Code

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.