Summary
Mercury deployments configured without authentication may allow anonymous clients to create Jupyter kernels and submit messages containing arbitrary Python code. This can enable remote code execution wherever the exposed application process has permission to act, particularly when the kernel endpoint is reachable from an untrusted network.
Mercury deployments configured without authentication may allow anonymous clients to create Jupyter kernels and submit messages containing arbitrary Python code. This can enable remote code execution wherever the exposed application process has permission to act, particularly when the kernel endpoint is reachable from an untrusted network.
Affected context
The issue occurs in Mercury deployments that allow tokenless access and expose Jupyter kernel functionality through the web application. It is especially risky when endpoint blocklists omit /api/kernels and websocket message handling tracks connection activity without separately authorizing executable kernel messages. The resulting exposure depends on network reachability and the permissions of the Mercury process or spawned kernels.
The issue occurs in Mercury deployments that allow tokenless access and expose Jupyter kernel functionality through the web application. It is especially risky when endpoint blocklists omit /api/kernels and websocket message handling tracks connection activity without separately authorizing executable kernel messages. The resulting exposure depends on network reachability and the permissions of the Mercury process or spawned kernels.
Exploit preconditions
- Attack surface: Mercury's HTTP and websocket interfaces, including the Jupyter
/api/kernelsendpoint - Required access: Network connectivity to the affected deployment; authentication may not be required in tokenless configurations
- Trigger point: Anonymous kernel creation followed by submission of executable
execute_requestmessages - Why exploitation is possible: Access-control enforcement does not consistently protect kernel creation and executable websocket messages, allowing untrusted clients to reach code execution functionality
- Attack surface: Mercury's HTTP and websocket interfaces, including the Jupyter
/api/kernelsendpoint - Required access: Network connectivity to the affected deployment; authentication may not be required in tokenless configurations
- Trigger point: Anonymous kernel creation followed by submission of executable
execute_requestmessages - Why exploitation is possible: Access-control enforcement does not consistently protect kernel creation and executable websocket messages, allowing untrusted clients to reach code execution functionality
Why this happens
The underlying flaw is a missing authorization check on sensitive Jupyter kernel operations, mapping to CWE-862: Missing Authorization. The application permits unauthenticated clients to reach functionality that creates execution contexts and accepts Python code, while endpoint filtering and websocket activity tracking do not establish authorization for executable messages. Treating transport activity or endpoint reachability as sufficient trust allows anonymous users to invoke privileged computation.
The underlying flaw is a missing authorization check on sensitive Jupyter kernel operations, mapping to CWE-862: Missing Authorization. The application permits unauthenticated clients to reach functionality that creates execution contexts and accepts Python code, while endpoint filtering and websocket activity tracking do not establish authorization for executable messages. Treating transport activity or endpoint reachability as sufficient trust allows anonymous users to invoke privileged computation.
Potential impact
- An unauthenticated attacker may execute arbitrary Python code in a Mercury process or kernel
- The attacker could access application data, environment variables, or credentials available to the runtime
- The compromised process may be used to modify files or affect connected services
- The deployment could experience data loss, service disruption, or lateral movement depending on runtime privileges
- An unauthenticated attacker may execute arbitrary Python code in a Mercury process or kernel
- The attacker could access application data, environment variables, or credentials available to the runtime
- The compromised process may be used to modify files or affect connected services
- The deployment could experience data loss, service disruption, or lateral movement depending on runtime privileges
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every sensitive kernel operation rather than relying only on endpoint filtering or connection-state tracking.
Common defensive patterns include:
- Require authentication and authorization before kernel creation, websocket connection, and executable message handling
- Prefer authenticated, non-tokenless deployment defaults for exposed applications
- Apply deny-by-default routing and explicitly protect all kernel-management endpoints
- Validate websocket message types and reject executable requests from unauthorized sessions
- Run kernels and application processes with least privilege and isolate them from sensitive services
- Reduce the trust granted to user-supplied notebook content and configuration
- Use network controls to restrict access to administrative and kernel interfaces
Mitigation generally focuses on enforcing authorization at every sensitive kernel operation rather than relying only on endpoint filtering or connection-state tracking.
Common defensive patterns include:
- Require authentication and authorization before kernel creation, websocket connection, and executable message handling
- Prefer authenticated, non-tokenless deployment defaults for exposed applications
- Apply deny-by-default routing and explicitly protect all kernel-management endpoints
- Validate websocket message types and reject executable requests from unauthorized sessions
- Run kernels and application processes with least privilege and isolate them from sensitive services
- Reduce the trust granted to user-supplied notebook content and configuration
- Use network controls to restrict access to administrative and kernel interfaces
How teams detect issues like this
Detection can include static analysis and code review for unauthenticated routes that create kernels, websocket handlers that process execute_request messages, and authorization checks applied only at connection time rather than per operation. Security testing can verify that anonymous requests cannot access /api/kernels or execute code through websocket channels. Policy enforcement may require authentication for notebook execution interfaces, deny-by-default endpoint rules, and automated checks for tokenless production deployments. Automated application-security review tools may help identify missing authorization boundaries, but runtime authorization tests should validate the deployed behavior.
Detection can include static analysis and code review for unauthenticated routes that create kernels, websocket handlers that process execute_request messages, and authorization checks applied only at connection time rather than per operation. Security testing can verify that anonymous requests cannot access /api/kernels or execute code through websocket channels. Policy enforcement may require authentication for notebook execution interfaces, deny-by-default endpoint rules, and automated checks for tokenless production deployments. Automated application-security review tools may help identify missing authorization boundaries, but runtime authorization tests should validate the deployed behavior.
