Only if you trust the extension and the person installing it. The JupyterLab documentation says installing an extension allows it to execute arbitrary code on the server, kernel and browser. On a shared GPU server, restrict who can install them and consider read only mode for the extension manager.
What the docs say
JupyterLab's extension guide is blunt. Installing an extension lets it run arbitrary code in three places: the server, the kernel and the browser. It asks users to avoid extensions they do not trust and to watch for extensions that masquerade as trusted ones.
The default extension manager is open. The docs say extensions can be freely downloaded without going through a vetting process, and the safety net is a blocklist that depends on users reporting malicious ones. Listings are not a substitute for isolating the server environment, especially in multi user deployments where users control kernels.
Types and their risk
| Type | Notes from the docs |
|---|---|
| Prebuilt extension via pip | Preferred type; may also include a server side part, so the general warning applies |
| Source extension | Highly discouraged; needs Node.js and a rebuild of JupyterLab |
A source extension pulls a JavaScript build chain onto the server, which adds another dependency tree to trust. Prebuilt packages are simpler, but they still come from a package index.
Why this matters for ML teams
A notebook server often has what attackers want: cloud credentials in the environment, mounted data, access to GPUs and to internal networks. An extension runs with that same reach. One careless install, or one lookalike package name, gets code onto that host. See pypi malware campaigns targeting ML and data science packages for how lookalikes spread.
Lock-down steps
- Decide who may install extensions. For shared servers, that should be an administrator, not every user.
- Use the read only extension manager option, which the docs show as the extension manager setting with the value readonly.
- Bake approved extensions into the server image, pinned to versions, and rebuild to change them.
- Keep an allow list with the reason and reviewer for each extension.
- Scan the image and the installed packages like any other dependency.
- Run each user's kernels in separate containers where possible, with minimal credentials.
The read only setting is documented as:
jupyter lab --LabApp.extension_manager=readonly
For single user laptops
The risk is smaller but real. Install fewer extensions, from known authors, and read the repository and recent release history first. Remove extensions you no longer use.
Review habits
Before approving an extension, check the package owner, the release history, the declared dependencies, and whether the name closely matches a popular one. Prefer extensions that your team already uses and pinned versions over latest.
Related: Jupyter server exposed to the network checklist.
Safeguard's dependency scanning and SBOM tooling can inventory what is installed on a server image, with a free scan at gold.safeguard.sh/scan.
Quick check
Do prebuilt extensions avoid the risk?
No. The docs apply the code execution warning to installing any extension.
Is a listing in the manager a vetting sign?
No. The docs say extensions can be downloaded without a vetting process.
Sources
Last reviewed: 19 October 2026.
