HowToFixMe
● High · CVSS 8.2

How to Fix CVE-2026-33589: Improper input validation in Open Notebook

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

Last verified: 2026-05-25

CVE-2026-33589 is a path-traversal arbitrary file read in Open Notebook, the open-source AI research-notebook app maintained at lfnovo/open-notebook. The upload feature in version 1.8.3 and earlier fails to validate the file path it is handed, so a logged-in user can walk out of the intended upload directory and read any file the app process can reach inside its Docker container. The fix is to upgrade past 1.8.3 to the release named in the GitHub Security Advisory. Because Open Notebook ships as a container image or a Python package, this page covers the Docker pull, the pip/uv upgrade, the local-account hardening you can apply while you schedule the change, and the version check that proves the patched code is actually running.

⚡ At a glance
SeverityCVSS 4.0 base 8.2 - High (AV:L/AC:L/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H)
Actively exploited?No. Not on CISA KEV; CISA SSVC Exploitation: none, Automatable: no
ProductOpen Notebook (open-source, lfnovo/open-notebook)
AffectedAll versions up to and including 1.8.3
Fixed inSee vendor advisory GHSA-842v-h4cj-r646 for the patched release
Type (CWE)CWE-20 improper input validation, exploited as path-traversal arbitrary file read (LFI)
Attacker needsA valid application account; local attack vector, no user interaction

Exploitation status

There is no CISA KEV entry for CVE-2026-33589 at present, so active in-the-wild exploitation has not been officially confirmed for this CVE. That is not a guarantee of safety, since KEV listings often lag real exploitation, so patch on the normal severity-based schedule rather than waiting for confirmation.

Public exploit availability: the primary references list no public exploit or Metasploit module as of writing. Private or unpublished exploit code may still exist, so do not downgrade the risk on that basis alone.

Authoritative references:

What is CVE-2026-33589?

Open Notebook is a self-hosted research notebook that lets users upload documents and notes for an AI assistant to work over. The flaw lives in the upload handler. When a user uploads a file, the application takes a path or filename from the request and uses it to write or read on disk without checking that the path stays inside the directory it is supposed to. The CVE record describes it plainly: "Lack of user input validation in the file upload functionality of Open Notebook v1.8.3 allows the application user to access local files content from the docker container via path traversal."

In practical terms, an attacker who already has a working Open Notebook account supplies a crafted path containing traversal sequences such as ../../etc/passwd. Instead of staying in the upload sandbox, the request climbs back up the directory tree and reads files belonging to the running container. That is a classic Local File Inclusion (LFI) pattern. MITRE classes the root cause as CWE-20, improper input validation, and maps the technique to CAPEC-76 (manipulating web input to file-system calls) and CAPEC-545 (pulling data from system resources). The advisory itself is titled "Arbitrary File Read via Local File Inclusion (LFI)".

The CVSS 4.0 vector tells you precisely how much an attacker needs and what they get: AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N, base score 8.2 (High). Read it field by field. Attack Vector is Local, and attack complexity is low with no special requirements. Privileges Required is None at the vulnerable component level, but the description makes clear the actor is "the application user", meaning someone who can reach the upload feature. User Interaction is None, so no victim has to click anything. The impact metrics are the important part: vulnerable-system Confidentiality is High and subsequent-system Confidentiality is High, while Integrity and Availability are None on both. This is a read-only information-disclosure bug. The attacker exfiltrates file contents; they do not modify your data or take the service down through this specific weakness.

Full technical detail is in the vendor advisory and the NVD entry. The finding is credited to CERT-EU, and the CVE was assigned through ENISA.

Why this CVE matters

An arbitrary file read sounds tame next to remote code execution. It is not. Whatever sits on that container filesystem is now readable by anyone with a login. Think about what an AI notebook deployment usually has on disk: a .env file with API keys for the language model provider, database connection strings, session secrets, OAuth client secrets, TLS private keys, and the uploaded documents of every other user on the instance. Reading any one of those turns a low-stakes account into a much bigger problem.

The damage flows from the confidentiality impact. With the model provider key, an attacker runs up your billing or pivots into your account. With the database credentials, they can connect directly if the database is reachable. With another user's uploaded research, they get data that was never meant to be shared. Because both the vulnerable system and its subsequent systems carry a High confidentiality rating, the leak does not stop at the app's own files; it reaches secrets that unlock adjacent services.

Who is exposed? Any organisation running Open Notebook 1.8.3 or earlier where more than one person can log in, or where the login surface is reachable by anyone you do not fully trust. A single-user instance on your own laptop is far lower risk than a shared team deployment or a demo instance exposed to the internet. The CISA SSVC assessment rates Exploitation as none and Automatable as no, and the technical impact as partial, which is consistent with a manual, authenticated, read-only bug rather than a wormable internet-wide threat. That is good news for prioritisation, not a reason to skip the patch.

Am I affected?

The affected range is everything from the first release through 1.8.3 inclusive. There is no lower bound carve-out in the record, so if you are on 1.8.3 or anything older, you are in scope. Open Notebook is a Python application, normally run as a Docker container or installed from PyPI, so check the version the way you actually deployed it rather than asking a system package manager.

For a Docker deployment, read the image tag and the version reported by the running container:

# Show the image and tag your container is running
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i notebook

# Inspect the exact image reference
docker inspect --format '{{.Config.Image}}' <your-open-notebook-container>

# Read the package version from inside the running container
docker exec <your-open-notebook-container> pip show open-notebook 2>/dev/null | grep -i '^Version'

For a pip or uv install on the host:

pip show open-notebook | grep -i '^Version'
# or, if you installed with uv:
uv pip show open-notebook | grep -i '^Version'

If the version string is 1.8.3 or lower, the fix applies to you. The CVE record does not publish a fixed version number, so the patched release is whatever the maintainer names in advisory GHSA-842v-h4cj-r646; confirm your target is strictly newer than 1.8.3.

How to fix CVE-2026-33589

The fix is a version upgrade. Move Open Notebook off 1.8.3 (or older) to the patched release named in the advisory. Open Notebook is distributed as a container image and as a Python package, so pick the path that matches how you run it. There is no Linux distro package, no npm package, and no Windows installer for this app, so ignore any guidance that points you at apt, npm, or an MSI.

Docker / Docker Compose deployment

Most people run Open Notebook from its published image. Back up your data volume first, then pull the patched tag and recreate the container. If you use Compose:

# 1. Back up the data volume before touching anything
docker run --rm -v open_notebook_data:/data -v "$PWD":/backup \
  alpine tar czf /backup/open-notebook-data-$(date +%F).tar.gz -C /data .

# 2. Pin the patched version in docker-compose.yml, e.g.
#    image: lfnovo/open_notebook:<patched-version>   # from advisory GHSA-842v-h4cj-r646
#    Then pull and recreate:
docker compose pull
docker compose up -d

# 3. Confirm the new image is the one running
docker compose images

If you run a plain docker run instead of Compose:

docker pull lfnovo/open_notebook:<patched-version>   # tag from the advisory
docker stop open-notebook && docker rm open-notebook
docker run -d --name open-notebook \
  -v open_notebook_data:/app/data \
  lfnovo/open_notebook:<patched-version>

Prefer pinning an explicit patched tag over :latest so a future pull cannot silently roll you onto an unexpected build.

PyPI (pip / uv) install

If you installed Open Notebook as a Python package rather than a container, upgrade it in place. Do this inside the same virtual environment the app runs from:

# Activate the venv Open Notebook runs in first, then:
pip install --upgrade open-notebook
pip show open-notebook | grep -i '^Version'

# If you manage the project with uv:
uv pip install --upgrade open-notebook
uv pip show open-notebook | grep -i '^Version'

After either path, restart the application process so the patched code is loaded. A pulled image or an upgraded package on disk does nothing until the running process is replaced.

# Container: already handled by 'up -d' / 'docker run' above.
# Bare process under systemd:
sudo systemctl restart open-notebook

If you can't patch immediately

Upgrading is the only durable fix. The mitigations below shrink the exposure window because the bug requires an authenticated account and only leaks file contents. They do not remove the flaw.

Cut down who can log in. The attacker has to be an Open Notebook user. If the instance is shared, audit the account list and remove anyone who does not need access. If it is exposed to the internet, put it behind a VPN or an authenticating reverse proxy so only known users reach the login page at all.

Strip secrets out of the container's reach. The real loss here is whatever sensitive files sit on the container filesystem. Move provider API keys, database passwords, and other secrets into a secrets manager or injected environment so they are not readable flat files inside the container, and rotate any key that has been sitting in a readable .env on an exposed 1.8.3 instance.

Add a traversal filter at the proxy, if you have one. If a reverse proxy already fronts the app, you can reject obvious traversal payloads in the upload request. This is partial cover only, because an authenticated user can encode payloads in ways a generic rule misses, but it raises the bar against lazy attempts. Sample ModSecurity rule:

# Append to /etc/modsecurity/rules/local.conf and reload the proxy.
SecRule REQUEST_URI|ARGS "@rx (?:\.\./|\.\.%2f|%2e%2e/|%2e%2e%2f)" \
    "id:900001,phase:2,deny,status:403,msg:'Path traversal attempt blocked (CVE-2026-33589)'"

sudo systemctl reload nginx    # or apache2, matching your proxy

How to verify the fix worked

This is a version-bound bug, so the verification that actually matters is the version string. Read it the same way you deployed the app and confirm the running build is newer than 1.8.3 and matches the patched release in the advisory.

# Container deployment
docker exec <your-open-notebook-container> pip show open-notebook | grep -i '^Version'

# Bare pip / uv install
pip show open-notebook | grep -i '^Version'

Then prove the behaviour is gone. Log in as a normal user and try a benign traversal in the upload path, for example a filename like ../../../etc/hostname. On a patched build the request is rejected or the path is normalised back into the upload directory; you should not see the contents of a file outside it. If you ran an unpatched, multi-user or internet-reachable instance during the disclosure window, treat any secret the container could read as potentially exposed: rotate model-provider API keys, database credentials, and session secrets, and review access logs for unusual upload requests carrying ../ sequences.

Frequently asked questions

Is CVE-2026-33589 being exploited in the wild?

No public exploitation is known. CVE-2026-33589 is not on CISA's KEV catalog, and CISA's SSVC assessment records Exploitation as none and Automatable as no. No public exploit or Metasploit module is linked in the CVE references. Patch on a normal severity-based schedule for a high-confidentiality bug, and pull it forward if exploit reports surface.

What exactly can an attacker do with CVE-2026-33589?

A logged-in Open Notebook user can abuse the upload feature to traverse paths and read arbitrary files inside the Docker container the app runs in. The CVSS 4.0 vector (AV:L/AC:L/PR:N/UI:N/VC:H, base 8.2) shows confidentiality-only impact. The attacker reads files such as .env secrets or other users' uploads; they cannot modify your data or crash the service through this flaw. It needs a usable application account, not remote unauthenticated access.

Which versions are affected, and which version is fixed?

Every release up to and including Open Notebook 1.8.3 is affected. The CVE record does not name a fixed version number, so upgrade to the patched release identified in GitHub Security Advisory GHSA-842v-h4cj-r646 and confirm the running build is strictly newer than 1.8.3.

Will a WAF or firewall rule fully mitigate CVE-2026-33589?

No. A WAF in front of the app can filter obvious traversal payloads, but the bug is reached by an already-authenticated user, so a network filter is partial cover at best. Upgrading to the patched Open Notebook build is the only durable fix. Restricting who can log in and keeping secrets out of the container's filesystem also reduce exposure.

Nearby vulnerabilities you may as well remediate alongside this fix:

References

Assembled from the official GitHub Security Advisory (GHSA-842v-h4cj-r646), the MITRE/NVD record, and the CISA ADP SSVC assessment. Last reviewed 2026-06-16. Always confirm against the vendor advisory before applying changes in production.