Jupyter Server CVE-2026-86049

Exploitation requires two concurrent conditions: (1) the attacker must be able to READ the Jupyter Server logs (local log files, host access, or a log-aggregation/SIEM pipeline), and (2) a valid token must have traversed the Referer header - which happens naturally during token-based login and notebook-launch flows where the token appears in the URL - coinciding with a request that returns HTTP 500. The 500 can be induced on demand (e.g., a malformed JSON POST to /api/kernels as shown in the PoC). Limiting factors: no direct remote attacker primitive - value is gated on log-read privilege; deployments that authenticate via headers/OAuth rather than ?token= URLs, or that already restrict log access, materially reduce exposure. Affects all jupyter_server versions <= 2.20.0; fixed in 2.21.0 which scrubs the Referer before logging.

The vendor CVSS 3.1 score is 7.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H), but the vector overstates the direct impact and mis-sets the attack vector. This is a CWE-532 sensitive-data-in-logs flaw: a token-bearing Referer header is written verbatim into a JSON header block whenever a request returns HTTP 500. The direct, primary impact is confidentiality (token disclosure); the I:H/A:H metrics reflect the DOWNSTREAM consequence - a leaked Jupyter token grants full session access and code execution - rather than an integrity/availability effect of the logging bug itself, so the base impact is best modeled as C:H/I:N/A:N. AV:N is also questionable: exploitation hinges on an actor who can READ the server logs, which is typically a local/privileged position (log files, log aggregation, or shared hosts), pushing toward AV:L and PR:L rather than a purely network-reachable primitive. A functional PoC is published in the GHSA advisory and a fixing commit/PR and regression test exist, so this is 'publicly available exploit code exists.' There is no EPSS, KEV, or SSVC data in the input; absence of KEV means no confirmed active exploitation. Net: a real, credible confidentiality/token-leak issue worth patching in exposed multi-tenant or shared-log deployments, but the 7.1 High rating is inflated by counting token-reuse consequences as base I/A impact, and real-world risk is gated by who can read logs plus a token actually flowing through a Referer during a 500.

During normal token-based login or notebook-launch flows, a user's URL (containing ?token=...) is sent as the Referer header; when any request to that Jupyter Server returns a 500, the raw Referer - token included - is written to the server log. An attacker or insider with read access to those logs (local file, syslog, or a centralized log pipeline) harvests the plaintext token and replays it to gain authenticated access to the Jupyter Server. A working PoC (a malformed POST that reliably triggers a 500 while carrying a token in the Referer) is published in the GitHub advisory.