{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/cpes/cpe2.3amljarmercury/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":["cpe:2.3:a:mljar:mercury:*:*:*:*:*:*:*:*"],"_cs_cves":[{"cvss":9.8,"id":"CVE-2026-111058"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["mercury (\u003c= 3.2.5)"],"_cs_severities":["critical"],"_cs_tags":["remote-code-execution","web-application-vulnerability","jupyter"],"_cs_type":"advisory","_cs_vendors":["MLJAR"],"content_html":"\u003cp\u003eMercury, a framework for converting Jupyter notebooks into web applications, is vulnerable to unauthenticated remote code execution due to its default insecure configuration. By default, the application runs without requiring authentication tokens or passwords and disables XSRF checks. While Mercury attempts to restrict access to sensitive endpoints via a hardcoded blocklist, the \u003ccode\u003e/api/kernels\u003c/code\u003e endpoint is omitted to maintain core functionality. A flaw in the \u003ccode\u003epatch_kernel_websocket_handler\u003c/code\u003e function fails to filter or validate incoming WebSocket messages, specifically \u003ccode\u003eexecute_request\u003c/code\u003e packets. Consequently, any unauthenticated network attacker can bypass intended security boundaries to provision kernels and execute arbitrary Python commands with the privileges of the Mercury server process. This vulnerability, tracked as CVE-2026-111058, affects all versions up to and including 3.2.5. This issue is distinct from previously patched terminal-based vulnerabilities and highlights a fundamental architectural risk in the reliance on blacklisting for securing Jupyter-based environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker performs reconnaissance to identify a network-exposed Mercury instance running with default (unauthenticated) settings.\u003c/li\u003e\n\u003cli\u003eAttacker sends an HTTP POST request to \u003ccode\u003e/api/kernels\u003c/code\u003e to request a new kernel session.\u003c/li\u003e\n\u003cli\u003eThe Mercury server returns a 201 Created response containing a new kernel ID, as the endpoint is not covered by the security blocklist.\u003c/li\u003e\n\u003cli\u003eAttacker initiates a WebSocket connection to the \u003ccode\u003e/api/kernels/\u0026lt;id\u0026gt;/channels\u003c/code\u003e endpoint associated with the created kernel.\u003c/li\u003e\n\u003cli\u003eAttacker transmits an \u003ccode\u003eexecute_request\u003c/code\u003e message over the established WebSocket connection containing malicious Python payloads.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003epatch_kernel_websocket_handler\u003c/code\u003e intercepts the message to perform idle-timeout tracking but fails to inspect or block the execution request content.\u003c/li\u003e\n\u003cli\u003eThe server processes the malicious payload, resulting in arbitrary code execution under the context of the Mercury application service account.\u003c/li\u003e\n\u003cli\u003eFinal objective achieved: unauthorized host or container compromise, allowing for data exfiltration or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation leads to full remote code execution on the server hosting the Mercury instance. Because the application typically runs with service-level privileges, this allows attackers to access sensitive environment variables, secrets, application data, and potentially pivot to underlying host systems or adjacent cloud infrastructure. All default deployments of Mercury versions 3.2.5 and earlier are considered critically exposed.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cp\u003ePrioritized actions for security teams:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately restrict network access to the Mercury service using firewall rules or ingress controllers, allowing only known, authorized IP ranges.\u003c/li\u003e\n\u003cli\u003ePatch Mercury instances or migrate to a configuration that mandates robust per-request authentication (tokens or passwords) by default, as the existing blocklist architecture is fundamentally insufficient.\u003c/li\u003e\n\u003cli\u003eReview web server access logs for anomalous POST requests to \u003ccode\u003e/api/kernels\u003c/code\u003e from unauthorized external source IPs.\u003c/li\u003e\n\u003cli\u003eMonitor for unexpected child processes spawned by the Mercury service user (e.g., shells, network utilities, or scripts) using EDR telemetry.\u003c/li\u003e\n\u003cli\u003eVerify that XSRF protections are enabled in the application configuration, as they are disabled by default in tokenless deployments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-10-19T20:10:37Z","date_published":"2026-10-19T20:10:37Z","id":"https://feed.craftedsignal.io/briefs/2026-10-mercury-rce/","summary":"The Mercury server defaults to unauthenticated access and uses an ineffective blocklist mechanism, enabling remote, unauthenticated attackers to execute arbitrary Python code via the /api/kernels websocket endpoint.","title":"Unauthenticated Remote Code Execution in Mercury via /api/kernels","url":"https://feed.craftedsignal.io/briefs/2026-10-mercury-rce/"}],"language":"en","title":"CraftedSignal Threat Feed - Cpe:2.3:a:mljar:mercury:*:*:*:*:*:*:*:*","version":"https://jsonfeed.org/version/1.1"}