CVE-2026-102830 in JupyterLab
Summary
by MITRE • 09/29/2026
JupyterLab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From JupyterLab 3.0.0 until 4.5.11 and 4.6.4, and in JupyterLite Core 0.8.3 and earlier, the Plural-Forms header in a selected third-party language pack can append JavaScript after a valid plural rule because prefix-only regular-expression validation accepts a matching prefix without requiring the entire header to match. JupyterLab passes the accepted expression to new Function, so loading the catalogue and translating a plural string executes the appended code in the authenticated JupyterLab origin. Where Jupyter Server kernels, terminals, and APIs are exposed, the code can use authenticated server APIs to read or modify files and run code. Impact is much more limited in JupyterLite because it typically lacks most exposed Jupyter Server surfaces. The default English locale is unaffected because it does not load a translation catalogue. This issue is fixed in JupyterLab 4.5.11 and 4.6.4 and JupyterLite Core 0.8.4.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified involves a critical input validation flaw within the language pack processing logic of JupyterLab, specifically affecting versions from 3.0.0 through 4.5.11 and 4.6.4, as well as JupyterLite Core version 0.8.3 and earlier. This security issue stems from an insufficient regular-expression validation mechanism used to parse the Plural-Forms header found in third-party language packs. The core technical flaw lies in the fact that the validation logic accepts a matching prefix of the expected plural rule format without requiring the entire header string to conform strictly to the valid syntax. Consequently, malicious actors can craft a language pack containing a specially crafted Plural-Forms header that appears syntactically correct for its initial segment but contains appended JavaScript code after what should be the end of the valid expression.
When JupyterLab processes these malformed language packs, it passes the accepted, yet compromised, expression directly to the JavaScript Function constructor. This action results in the immediate execution of the embedded malicious script within the context of the authenticated JupyterLab origin. The impact is particularly severe because this code execution occurs during the loading and translation of plural strings, a routine operation that may be triggered simply by selecting or initializing a specific language pack. Since the executed code runs with the privileges of the authenticated user in the current session, it inherits full access to the browser's local storage, cookies, and any active API sessions associated with the JupyterLab instance.
In environments where Jupyter Server components such as kernels, terminals, and REST APIs are exposed to the network or accessible via the frontend interface, the consequences of this vulnerability escalate significantly. The injected JavaScript can leverage authenticated server APIs to perform unauthorized actions, including reading sensitive files from the underlying file system, modifying existing data, executing arbitrary code on remote kernels, or establishing persistent backdoors within the session. This effectively allows an attacker who controls a malicious language pack to achieve Remote Code Execution (RCE) with the privileges of any user interacting with that specific locale setting. The threat model assumes that users may install third-party extensions or language packs from untrusted sources, making this a significant risk in collaborative or public-facing Jupyter deployments.
The severity and impact are somewhat mitigated by deployment context. In JupyterLite environments, which typically operate as client-side only applications without exposed Jupyter Server surfaces like kernels or file system APIs, the ability to read or modify server-side resources is severely limited. However, even in these constrained environments, the execution of arbitrary JavaScript within the authenticated origin can still lead to data exfiltration via browser-based attacks such as Cross-Site Scripting (XSS) variants or session hijacking if other vulnerabilities are present. The default English locale remains unaffected by this specific vector because it does not load an external translation catalogue that would trigger the vulnerable parsing logic, highlighting how localized features can introduce unexpected attack surfaces when input validation is lax.
To address this vulnerability, users must upgrade to JupyterLab version 4.5.11 or later, specifically versions 4.6.4 and above for newer releases, as well as updating JupyterLite Core to version 0.8.4 or higher. These patched versions implement stricter validation that ensures the entire Plural-Forms header matches the expected format rather than just a prefix, thereby preventing the injection of arbitrary code. Organizations should also enforce strict policies regarding the installation and sourcing of third-party extensions and language packs, ensuring they originate from trusted repositories such as the official Jupyter extension registry. Implementing Content Security Policy (CSP) headers that restrict script execution to whitelisted sources can provide an additional layer of defense against similar injection attacks in broader web application contexts.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code or Script, commonly known as Injection, due to the untrusted input being interpreted and executed by the system's runtime environment. It also relates to CWE-20 Improper Input Validation, specifically regarding insufficient checking for malicious content in structured data fields like headers. In terms of adversary tactics, this flaw facilitates initial access and execution phases within the MITRE ATT&CK framework, allowing attackers to leverage trusted application components to execute arbitrary code on target systems or user browsers. The remediation strategy emphasizes both software updates and operational security practices such as verifying extension integrity before installation.