A significant security flaw in Jupyter notebook deployments could allow attackers to gain complete system control by exploiting default configurations and unauthenticated API access.
Security researchers discovered that improperly configured Jupyter servers running with root privileges and disabled authentication can be leveraged to execute arbitrary commands with the highest system permissions.
The vulnerability stems from a combination of misconfigurations rather than a single code flaw. When Jupyter notebook servers run as the root user without authentication tokens enabled, they expose dangerous functionality through their REST API.
Specifically, the terminal API endpoint allows attackers to create and interact with shell sessions directly through WebSocket connections.
How the Attack Works
An attacker with local network access to a vulnerable Jupyter server can create a terminal session using a simple HTTP POST request to the /api/terminals endpoint.
The attacker then communicates with this terminal through WebSocket protocol using tools like websocat, which translates standard commands into the JSON format expected by Jupyter’s terminal interface.
The critical issue is that the terminal session inherits the privileges of the Jupyter process itself. When running as root, this grants attackers complete administrative access.
Through this channel, attackers can execute arbitrary system commands, read sensitive files, establish reverse shells for persistent access, and compromise the entire system.
After identifying a root-privilege Jupyter server running without authentication, they created a terminal session and executed the id command, confirming root access.
With this foothold, they accessed Jupyter’s kernel connection files containing HMAC signing keys and session information, enabling session hijacking across multiple user notebooks.
Finally, they established a persistent reverse shell that appears as legitimate Jupyter activity to monitoring systems. Organizations can prevent this vulnerability through fundamental security practices.
First, Jupyter services should never run as the root user. Instead, administrators should create dedicated unprivileged user accounts for Jupyter processes.
For environments requiring GPU access or special permissions, use capability-based security controls rather than elevating to root.
Second, always enable authentication on Jupyter servers. Even in internal networks, requiring valid tokens prevents unauthorized access.
Third, consider disabling terminal functionality entirely if users don’t require shell access through Jupyter, as reported by Adversis.
For multi-user deployments, use JupyterHub with proper user isolation and capability-based security models. Apply the principle of least privilege by limiting users to only the permissions they genuinely need.
Security teams should monitor Jupyter logs for terminal API usage and track access to kernel runtime files. Unusual outbound connections from Jupyter processes and privilege escalation attempts warrant immediate investigation.
Process monitoring can detect suspicious shell invocations, such as socat or netcat, initiated by Jupyter processes. This vulnerability demonstrates how default configurations and disabled security features can turn convenience into significant risk.
Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.
