CVE-2026-86049 in Jupyter Server
Summary
by MITRE • 09/17/2026
Jupyter Server is the backend for Jupyter web applications. Prior to version 2.21.0, the 5xx request logging path in jupyter_server/log.py copies the Referer header into a JSON header block without applying the token scrubbing used for the request URI. A request that returns HTTP 500 while the Referer contains a token-bearing URL can therefore write that token to server logs in plaintext. An attacker who can read those logs can recover the token and use the affected user's Jupyter Server permissions. This issue is fixed in version 2.21.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified involves a critical information disclosure flaw within the logging mechanism of Jupyter Server, specifically affecting versions prior to 2.21.0. As the backend infrastructure for various Jupyter web applications such as JupyterLab and Notebook, Jupyter Server handles sensitive user interactions including code execution and data management. The core issue resides in the error handling logic located in the log.py module, which is responsible for generating structured JSON logs when server-side errors occur. When a request results in an HTTP 500 Internal Server Error, the logging routine attempts to capture contextual details about the failed request to aid in debugging and monitoring. However, this process fails to apply consistent sanitization protocols across all captured headers.
The technical flaw is characterized by an inconsistency in data scrubbing practices. While the implementation correctly applies token scrubbing to the Request URI field within the JSON log block, it neglects to do so for the Referer header. The Referer header often contains URLs that include authentication tokens or session identifiers as query parameters when users navigate via links containing these credentials. Consequently, if a user triggers an internal server error while their browser sends a Referer header containing such a token, the logging system writes this sensitive credential to the log files in plaintext without any masking or removal. This creates a direct path for unauthorized access through the compromise of server-side logs rather than exploiting a code execution vulnerability directly.
The operational impact of this vulnerability is severe due to the potential for full account takeover and privilege escalation within the Jupyter environment. An attacker with read access to the server log files, which may be accessible via local file system permissions, misconfigured logging aggregators like ELK Stack or Splunk, or through other secondary vulnerabilities that allow reading static assets or logs, can extract these plaintext tokens. Once obtained, these tokens can be used by the attacker to authenticate as the affected user without needing their password. This grants the attacker full administrative privileges associated with that Jupyter Server instance, allowing them to execute arbitrary code on the host system, access sensitive datasets stored within the notebook environment, and potentially pivot further into the internal network depending on the server's configuration and exposure level.
This vulnerability aligns with CWE-532, which defines Information Exposure Through Log Files, as it involves the inclusion of security-relevant information in log output that could be exploited by an attacker. Furthermore, from a threat modeling perspective using the MITRE ATT&CK framework, this flaw facilitates Initial Access and Credential Access techniques. Specifically, it relates to T1530 Data from Local System which covers accessing data stored on local systems such as logs, and potentially contributes to T1078 Valid Accounts if the stolen tokens are used for persistent access. The lack of consistent sanitization across different request attributes highlights a broader architectural weakness in handling sensitive headers during error reporting phases.
To mitigate this risk, organizations must upgrade Jupyter Server to version 2.21.0 or later where the logging logic has been corrected to scrub authentication tokens from all relevant fields including the Referer header. For environments that cannot immediately patch due to dependency constraints, temporary mitigations should be implemented at the infrastructure level. This includes restricting file system permissions on log directories so that only authorized service accounts can read them, configuring web servers or reverse proxies like Nginx or Apache to strip sensitive query parameters from headers before they reach the application server, and ensuring that logging aggregation systems do not expose raw logs over unauthenticated endpoints. Additionally, implementing strict Content Security Policy (CSP) directives on client-side applications can reduce the likelihood of tokens being passed in the Referer header by preventing cross-origin navigation or restricting referrer policies to same-origin only.