EUVD-2026-104420
GHSA-rv4m-xm3f-3ccq
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach default tokenless Mercury endpoint
-
DeliveryPOST /api/kernels to create python3 kernel
-
ExploitOpen /api/kernels/<id>/channels websocket
-
ExecutionSend execute_request with arbitrary Python
-
PersistCode execution as server process user
-
ImpactCompromise host/container and reachable secrets
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the target to run in Mercury's default tokenless deployment mode: mercury_app/__main__.py sets --IdentityProvider.token='' (and --ServerApp.disable_check_xsrf=True) when no --token or MERCURY_TOKEN is supplied, giving anonymous JupyterLab access. The specific exposed feature is the /api/kernels endpoint, which is deliberately absent from the BLOCKED_PATTERNS blocklist (/lab, /api/terminals, /api/shutdown, /files) because Mercury needs kernels to run notebooks, combined with patch_kernel_websocket_handler() wrapping on_message only for idle-timeout tracking and performing no filtering of execute_request. The decisive LIMITING factor is configuration: deployments launched with a token or password (MERCURY_TOKEN / --token) require per-request authentication and are not exploitable via this path; only default anonymous, network-reachable instances are affected. No user interaction and no authentication are needed against a default instance. |
| Impact | This is a genuine high-priority issue, not a CVSS-inflation case. The CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N) describes network-reachable, low-complexity, unauthenticated exploitation with full C/I/A impact, and the multi-source evidence corroborates rather than contradicts it: the GHSA advisory documents a runtime-proven, deterministic PoC that achieved code execution (ran 'whoami' and wrote /tmp/PWNED_MERCURY_RCE) on the default tokenless configuration of mercury 3.2.4, and CWE-862 (Missing Authorization) aligns with the described blocklist gap at /api/kernels. The signals are therefore mutually reinforcing for a working, unauthenticated RCE. Tempering factors: no EPSS score is provided in the input, and there is no CISA KEV listing, so there is no evidence of active in-the-wild exploitation at this time - the risk is driven by a public, reliable exploit against default configs rather than by observed mass exploitation. The one real limiter is deployment mode: exploitation depends on the default tokenless/anonymous JupyterLab configuration; operators who set MERCURY_TOKEN or a password are not exposed via this path. Prevalence of the product itself is modest, which bounds the aggregate internet-wide risk even though per-instance impact is maximal. |
| Exploit ScenarioDerived | An unauthenticated attacker who can reach a default (tokenless) Mercury deployment sends POST /api/kernels to spawn a python3 kernel, opens the kernel websocket, and sends an execute_request carrying arbitrary Python, obtaining code execution as the server process user. A deterministic, runtime-verified proof-of-concept (client script plus notebook) already exists and was demonstrated to run commands and write files on a patched-for-the-previous-bug 3.2.4 host. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Unauthenticated remote code execution in MLJAR Mercury deployments running the default tokenless configuration allows any network-reachable client to create a Jupyter kernel and send execute_request messages containing arbitrary Python, resulting in code execution as the Mercury server process user. Mercury versions through 3.2.5 are affected and 3.2.6 is the fixed release; deployments that require a token or password via MERCURY_TOKEN or --token are not exploitable through this path. The issue is assessed at CVSS 9.8, publicly available exploit code exists, but no active exploitation is confirmed (not in CISA KEV).
RemediationAI
Vendor-released patch: upgrade to MLJAR Mercury 3.2.6 or later (release tag 3.2.6; commit 73a40ceb0becf057f495a5738ad7f5a5222a53e1). The primary fix is to upgrade, because 3.2.6 adds kernel message authorization and blocks /api/contents; see the advisory at https://github.com/mljar/mercury/security/advisories/GHSA-rv4m-xm3f-3ccq. If an immediate upgrade is not possible, do not run Mercury in tokenless mode on a network-reachable interface: set MERCURY_TOKEN or --token so per-request authentication is required, and avoid disable_check_xsrf=True; this changes the deployment model and may break anonymous dashboard access, but it prevents the unauthenticated kernel path. Additionally, restrict access to the Mercury service with a firewall, reverse proxy, or authenticated gateway until the upgrade is complete. Blocking /api/kernels at a proxy is not a safe long-term workaround because Mercury needs kernels to execute notebooks, and attempting to block or disable kernels will break notebook execution.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Mercury is a Python framework that exposes Jupyter notebooks as web apps and runs a JupyterLab/Tornado server behind its own handlers. In the default deployment mode, mercury_app/__main__.py sets --IdentityProvider.token='' and --ServerApp.disable_check_xsrf=True when no token is supplied, so anonymous clients can reach Jupyter endpoints. The design relied on a path blocklist (BLOCKED_PATTERNS containing /lab, /api/terminals, /api/shutdown, /files) to protect sensitive endpoints, but /api/kernels is intentionally absent because Mercury needs kernels to run notebooks. patch_kernel_websocket_handler() in mercury_app/idle_timeout.py only wraps on_message to touch the idle timeout manager and does not inspect or authorize message types, so an anonymous client can POST /api/kernels to create a kernel, open /api/kernels/<id>/channels, and send an execute_request with arbitrary code. This is CWE-862 Missing Authorization: the server neither requires authentication nor authorizes kernel message types for anonymous websocket clients. It is distinct from GHSA-f8c7-rwf9-fmgm, which fixed a /api/terminals blocklist bypass; that fix does not cover kernels. Version 3.2.6 adds execution/connection.py and execution/policy.py that rewrite execute_request code from the notebook manifest, reject debug_request, shutdown_request, complete_request, and input_reply, restrict comm messages to known comm IDs, enforce MAX_MESSAGE_BYTES for widget buffers, and add /api/contents to the blocklist.
Know when Mercury gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Default tokenless config grants anonymous network clients unfiltered kernel execution (AV:N/AC:L/PR:N/UI:N), yielding full arbitrary code execution and complete C/I/A loss.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Mercury is a Python framework for sharing Jupyter notebooks as web applications and dashboards. Prior to 3.2.6, default tokenless deployments allow anonymous clients to create Jupyter kernels and send execute_request messages containing arbitrary Python. The endpoint blocklist does not cover /api/kernels, and the websocket wrapper previously tracked idle activity without authorizing executable messages. This issue is fixed in version 3.2.6.
Articles & Coverage 1
Technical POC Analysis
Bug class: CWE-862 Missing Authorization.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
MLJAR Mercury deployments through 3.2.5 that use the default tokenless configuration are exposed to remote code execution, letting any network-reachable client run arbitrary Python as the Mercury server process. Publicly available exploit code exists, so exposed instances should be treated as high-priority until upgraded to 3.2.6 or otherwise isolated. Leadership should care because compromise could affect the server and any data or credentials accessible to that process.
Apply vendor patch: upgrade to MLJAR Mercury 3.2.6 or later. If upgrade is delayed, enforce MERCURY_TOKEN/--token authentication and restrict network access to trusted clients.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Unauthenticated remote command execution is possible in MLJAR Mercury 3.0.0 through 3.2.3 because a missing comma in the
An XXE issue exists in Accenture Mercury before 1.12.28 because of the platformlambda/core/serializers/SimpleXmlParser.j
Stored/DOM cross-site scripting in Mercury's mr.Markdown widget (versions 3.0.0 through 3.2.10) allows attacker-supplied
Exploit-DB