GHSA-h8wq-7xc4-p3qx CVE-2026-0846 PYSEC-2026-97

NLTK has Arbitrary File Read via Absolute Path Input in nltk.util.filestring()

High PyPI

Severity: 8.6 / 10; High · CVSS 3.0
Exploit chance (EPSS): 0.55%; Chance of exploitation in the next 30 days. Higher than 46.12% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-36 Absolute Path Traversal
Fix: 3.9.3; Upgrade nltk to this version or later

Description

A vulnerability in the filestring() function of the nltk.util module in nltk version 3.9.2 allows arbitrary file read due to improper validation of input paths. The function directly opens files specified by user input without sanitization, enabling attackers to access sensitive system files by providing absolute paths or traversal paths. This vulnerability can be exploited locally or remotely, particularly in scenarios where the function is used in web APIs or other interfaces that accept user-supplied input.

Affected versions

PyPI

Package	Vulnerable	Fixed in
nltk	`< 3.9.3`	`3.9.3`
nltk	`<= 3.9.2`	No fix yet

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

nltk PyPI → `3.9.3`

pip

pip install --upgrade "nltk>=3.9.3"

poetry

poetry add "nltk>=3.9.3"

uv

uv add "nltk>=3.9.3"

Severity breakdown

CVSS 3.0 8.6

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: High
Integrity: Low
Availability: Low

Weakness

CWE-36: Absolute Path Traversal

The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory.

How to prevent it

Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would b
Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

References

Advisories

Packages

github.com/nltk/nltk

Timeline

Mar 9, 2026 Published
Jul 15, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-j456-xh4h-cpf2 NLTK: WekaClassifier passes an unvalidated caller-controlled model path to the weka JVM, bypassing nltk.pathsec containment	High	Also affects nltk
GHSA-ff5c-cp5c-9wjf NLTK: Uncontrolled resource consumption in RecursiveDescentParser via ambiguous or left-recursive grammars	Medium	Also affects nltk
GHSA-f794-5jv7-7672 NLTK: Downloader.download follows hardlinks and overwrites outside-root files	High	Also affects nltk
GHSA-8mgp-746c-j5xp NLTK: Model-artifact APIs bypass pathsec and touch files outside allowed roots	High	Also affects nltk
GHSA-8mpw-7fpc-4gqj NLTK: Pl196xCorpusReader has quadratic ReDoS on malformed TEI blocks	Low	Also affects nltk
GHSA-cw6x-m8jw-qmrh NLTK: Uncontrolled recursion in nltk.featstruct.FeatStructReader causes unhandled RecursionError (DoS) via deeply nested feature-structure input	Medium	Also affects nltk
GHSA-vp2x-qp44-57v7 NLTK: Quadratic CPU Exhaustion in `XMLCorpusView._read_xml_fragment()`	Low	Also affects nltk
GHSA-ww6m-cw3f-q94g NLTK: Quadratic-time DoS in PorterStemmer via long runs of 'y'	High	Also affects nltk

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor