CVE-2026-62385 is a medium severity (CVSS 5.9) path traversal flaw in the Python NLTK library before 3.10.0. The FrameNet and NKJP corpus readers can parse XML files outside the corpus root when given unsafe selectors. The fix is NLTK 3.10.0.
What's affected
The record says NLTK before 3.10.0. The GitHub advisory (GHSA-568f-pv23-39p4) lists the pip package nltk, affected versions up to and including 3.9.4, patched in 3.10.0. The affected methods are FramenetCorpusReader (frame_by_name, doc, lu) and NKJPCorpusReader (header). The weakness is CWE-73 (external control of file name or path).
The advisory describes two routes: unsafe selectors passed by a caller, and poisoned index state. Either way the reader builds a file name without keeping it inside the corpus directory, then parses whatever XML it finds there.
Source conflict on severity. The record gives 5.9 Medium on CVSS 3.1, with high attack complexity and confidentiality impact only. The GitHub advisory labels it High, and VulnCheck lists medium with a CVSS 4.0 score of 8.2. The fixed version is the same everywhere: 3.10.0. Note that the impact is limited to reading XML the application can reach.
How to check if you're exposed
Check which NLTK version is installed in each environment.
pip show nltk
pip list 2>/dev/null | grep -i nltk
python -c "import nltk; print(nltk.__version__)"
Also search your code for use of the FrameNet and NKJP readers. If you never use them, the vulnerable paths are not called, though you should still update. Look for calls to frame_by_name, doc, lu or header on those readers where the argument comes from a user or a file you did not create. The free in-browser dependency scan at gold.safeguard.sh/scan can list the matching dependencies in a manifest or lockfile you paste in.
What to do now
- Upgrade to NLTK 3.10.0 or later in every environment, including notebooks, containers and CI images.
- Pin the new version in requirements files or lockfiles so a rebuild does not return to 3.9.4.
- Do not pass user supplied names or ids to the FrameNet or NKJP readers. Check them against an allowed list first.
- Keep corpus data in a directory the application can read but not write, and keep other sensitive XML out of its reach.
- Review notebooks and services that expose NLP features through an API, since they are the likeliest places for outside input to reach a reader.
Why it matters
Path traversal bugs happen when code builds a file path from input and never confirms the result stays inside the intended folder. The advisory notes that the patched code applies the same root confinement already used elsewhere in NLTK, which is the right fix: one shared check, used everywhere a path is built.
The practical risk depends on how you use the library. A research script that loads a fixed corpus is hardly exposed. A web service that takes a frame name from a request and hands it to a reader is a different matter. The record does not list this CVE as exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
I only use NLTK tokenizers. Am I affected?
The advisory names the FrameNet and NKJP corpus readers. If your code never calls them, the described path is not reachable, but upgrading to 3.10.0 is still the simplest way to close the question.
Sources
Last reviewed: 18 October 2026.
