Nvidia — CraftedSignal Threat Feed

Jupyter Notebook Authentication Token Theft via CommandLinker XSS

hello@craftedsignal.io — Thu, 30 Apr 2026 17:25:47 +0000

A stored Cross-Site Scripting (XSS) vulnerability has been identified in Jupyter Notebook and JupyterLab, impacting versions 7.0.0 through 7.5.5 of Jupyter Notebook and versions up to 4.5.6 of JupyterLab. Discovered by Daniel Teixeira of the NVIDIA AI Red Team, this flaw allows an attacker to craft malicious notebook files containing XSS payloads embedded within the command linker functionality. When a user opens and interacts with these files, the injected script executes, potentially stealing the user’s authentication token. Successful exploitation grants the attacker full control over the user’s Jupyter account, enabling them to read, modify, and create files, execute arbitrary code via running kernels, and establish shell access through created terminals. This vulnerability poses a significant risk to data confidentiality, integrity, and system availability.

Attack Chain

Attacker crafts a malicious Jupyter Notebook file containing a stored XSS payload within the command linker functionality.
The attacker distributes the malicious notebook file to a target user (e.g., via email, shared repository, or compromised website).
The victim opens the malicious notebook file in a vulnerable version of Jupyter Notebook or JupyterLab.
The victim interacts with a seemingly legitimate control element within the notebook that is, in fact, part of the XSS payload.
The injected XSS code executes in the victim’s browser, stealing their authentication token.
The attacker uses the stolen authentication token to authenticate to the Jupyter REST API.
The attacker gains complete control over the victim’s Jupyter account.
The attacker performs malicious actions, such as reading files, modifying files, executing arbitrary code, or creating terminals for shell access.

Impact

Successful exploitation of this XSS vulnerability enables complete account takeover, allowing attackers to read, modify, and create files, access running kernels and execute arbitrary code, and create terminals for shell access within the victim’s Jupyter environment. This can lead to data exfiltration, code injection, and potential compromise of sensitive information stored within the Jupyter Notebook environment. Given the widespread use of Jupyter Notebook in data science, machine learning, and research environments, this vulnerability can have far-reaching consequences for individuals and organizations relying on these tools.

Recommendation

Immediately upgrade Jupyter Notebook to version 7.5.6 or later, and JupyterLab to version 4.5.7 or later to patch CVE-2026-40171.
Apply the workaround to disable the help extension via CLI as specified in the advisory to mitigate the vulnerability until patching is possible.
Implement the hardening measure by disabling the command linker functionality via overrides.json to prevent XSS attacks, referencing the configuration details in the advisory.
Deploy the Sigma rule “Detect Jupyter Notebook CommandLinker XSS Attempt” to detect potential exploitation attempts based on specific HTTP request characteristics.
Educate users about the risks of opening untrusted Jupyter Notebook files and interacting with potentially malicious content.

Registry Persistence via AppInit DLL Modification

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

The AppInit DLLs mechanism allows dynamic-link libraries (DLLs) to be loaded into every process that creates a user interface (loads user32.dll) on Microsoft Windows operating systems. This mechanism is intended for customization of the user interface and behavior of Windows-based applications. However, attackers can abuse this by adding malicious DLLs to the registry locations associated with AppInit DLLs. This enables them to execute code with elevated privileges, similar to process injection, and maintain a persistent presence on the compromised machine. This technique is often used to maintain access after initial compromise. Detection focuses on registry modifications to the relevant keys, excluding known legitimate processes to minimize false positives. The referenced Elastic rule was last updated on 2026/05/04.

Attack Chain

An attacker gains initial access to the system through a vulnerability, phishing, or other means.
The attacker identifies the AppInit DLLs registry keys: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows.
The attacker modifies the AppInit_DLLs registry value to include the path to their malicious DLL.
The attacker’s DLL is placed on the filesystem, typically in a location where it will persist across reboots.
Any new process that loads user32.dll will automatically load the attacker’s malicious DLL.
The malicious DLL executes arbitrary code within the context of the newly created process.
The attacker can use this code execution to perform further actions, such as installing backdoors or escalating privileges.
The attacker maintains persistent access to the system through the malicious DLL loaded into every user interface process.

Impact

Successful exploitation allows attackers to execute arbitrary code within the context of any process that loads user32.dll. This provides a persistent mechanism for maintaining access to the compromised system. The attacker gains code execution with elevated privileges, similar to process injection. This can lead to data theft, system compromise, or further lateral movement within the network. While no specific victim counts are mentioned, the widespread use of Windows makes this a potentially high-impact vulnerability.

Recommendation

Monitor registry modifications to the AppInit_DLLs value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows using the “Registry Persistence via AppInit DLL Modification” Sigma rule.
Enable Sysmon registry event logging to provide the data required for the Sigma rule to function correctly.
Deploy the “Registry Persistence via AppInit DLL Modification” Sigma rule to your SIEM and tune the filter to exclude known-good DLL paths in your environment.
Investigate any alerts triggered by the Sigma rule, focusing on the parent process and the DLL being loaded.

LSASS Loading Suspicious DLL

hello@craftedsignal.io — Wed, 03 Jan 2024 10:00:00 +0000

The Local Security Authority Subsystem Service (LSASS) is a critical Windows component that manages security policies and user authentication. Attackers often target LSASS to dump credentials, using techniques like injecting malicious DLLs. This detection focuses on identifying instances where LSASS loads a DLL that is either unsigned or not signed by a trusted vendor. The rule excludes known legitimate signatures and file hashes to reduce false positives. This activity is a strong indicator of credential access attempts, potentially leading to further compromise of the system and network. The signatures identified in the rule contain well-known software vendors like Microsoft, McAfee and Citrix.

Attack Chain

An attacker gains initial access to the system through various means (e.g., phishing, exploiting a vulnerability).
The attacker elevates privileges to gain sufficient access to interact with the LSASS process.
The attacker drops a malicious DLL onto the system, often disguised as a legitimate file.
The attacker injects the malicious DLL into the LSASS process using techniques like Reflective DLL Injection.
LSASS loads the injected DLL, granting the attacker access to sensitive credentials stored in memory.
The malicious DLL dumps credentials, such as plaintext passwords or NTLM hashes.
The attacker uses the stolen credentials for lateral movement to other systems on the network.
The attacker achieves their final objective, such as data exfiltration or deploying ransomware.

Impact

Successful exploitation leads to credential compromise, allowing attackers to move laterally within the network, access sensitive data, and potentially achieve complete domain dominance. This can result in data breaches, financial losses, and reputational damage. The impact depends on the level of access associated with the compromised credentials.

Recommendation

Deploy the LSASS Loading Untrusted DLL Sigma rule to your SIEM to detect suspicious DLLs loaded by LSASS.
Investigate any alerts generated by the Sigma rule and review the loaded DLL’s code signature and hash.
Block the identified SHA256 hashes listed in the IOC table to prevent the execution of known malicious DLLs.
Implement application whitelisting to restrict which DLLs can be loaded into LSASS.
Enable Sysmon process creation and image load logging to provide the necessary data for detection.