Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
53 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Vulnerability The fix for CVE-2026-12841 (CWE-88, JVM argument injection) added validatejavaoptions() to block dangerous JVM flags such as -agentlib, -agentpath, -javaagent, -Xrunjdwp, and @argfile references. However, the validation is only applied when setting global options via configjava(). The java() function's per-call options parameter -- added by PR #3683 (CVE-2026-12615 fix) -- passes options directly to subprocess.Popen without calling validatejavaoptions(). All four Stanford Java wrapper classes accept user-supplied javaoptions and route them through the unvalidated per-call path, bypassing the CVE-2026-12841 fix entirely. Root Cause In nltk/internals.py, the java() function (line 128) accepts an options keyword argument. When options is not None, it is converted to a list and prepended to the JVM command (lines 211-217) without any validation: Compare with configjava() (line 92) which does validate: The four affected wrapper classes store user-supplied javaoptions without…
Recommended action: Upgrade to 3.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Two NLTK sites executed the Graphviz dot program by bare name, so process creation resolved it via the search path — and on Windows via the current working directory — rather than a validated absolute location. An attacker who can place a file named dot where resolution looks (the CWD on Windows, or a writable/relative entry such as . on PATH) has their binary executed in place of Graphviz (arbitrary code execution). Affected (<= 3.10.2): - nltk.parse.dependencygraph.dot2img — called findbinary("dot") but discarded the returned validated path and then ran the bare name ["dot", ...], so the validation had no effect. - nltk.translate.api.AlignedSent.reprsvg — ran the bare name with no validation at all (IPython SVG rendering). This is the same class already fixed for the senna, weka, boxer, malt, repp and hunpos wrappers. nltk.internals.findbinary refuses a CWD-relative match for a bare tool name and returns only a trusted absolute path; the fix runs that path in both sites. --- Attack…
Recommended action: Upgrade to 3.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
NLTK before 3.10.3 contains a remote code execution vulnerability in AllowlistUnpickler that validates only the pickle module string and not the global name, allowing attackers to resolve dotted names by attribute traversal to callables outside the allowlisted namespace. Attackers can craft untrusted transition-parser models that execute arbitrary commands when TransitionParser.parse loads the model through allowlistedpickleload.
Recommended action: Upgrade to 3.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
NLTK 3.9.4 through 3.10.2 contains a path traversal vulnerability in CrubadanCorpusReader. loadlangngrams joins the corpus root with crubadancode, the column-0 value read from the corpus table.txt mapping file, and opens the result with the builtin open() rather than the pathsec-validated opener, so os.path.join discards the root when that value is absolute and the read escapes the corpus directory without the containment check nltk.pathsec applies when ENFORCE is set. An attacker who controls a corpus package can disclose file contents outside the corpus root through langfreq, limited to paths ending in -3grams.txt whose contents parse as token count lines.
Recommended action: Upgrade to 3.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The URLS regular expression in nltk/tokenize/casual.py, compiled into TweetTokenizer.WORDRE and applied by TweetTokenizer.tokenize, contains a naked-domain branch whose domain-label prefix [a-z0-9]+(?:[.\-][a-z0-9]+) is unbounded. Input consisting of many alternating label separators can be partitioned in exponentially many ways, and because the branch also requires a trailing top-level domain that such input never supplies, the engine explores those partitions before failing at each offset. A few kilobytes of input therefore consumes seconds to minutes of single-threaded CPU, and the HANGRE substitution performed before matching does not collapse the pattern. TweetTokenizer is intended for tokenizing untrusted social-media text, so any service that applies it, or the module-level casualtokenize, to submitted text can be stalled per request without authentication. Version 3.10.1 bounds the label repetition.
Recommended action: Upgrade to 3.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Request Forgery (SSRF) vulnerability exists in nltk/nltk versions 3.9.4 and the current develop branch. The nltk.pathsec.validatenetworkurl() function, intended to prevent SSRF by rejecting internal network addresses, fails to reject IPs in the RFC 6598 shared address space (100.64.0.0/10). This occurs because Python's ipaddress module does not classify such addresses as isprivate or isglobal, and the current guard only checks isprivate and a few explicit categories. An attacker who can influence a URL passed to NLTK's network-loading helpers can exploit this vulnerability to make a strict-mode application send requests to shared-address-space hosts, potentially exposing non-public infrastructure reachable from the application host. The impact is limited to SSRF-style confidentiality exposure, with no code execution claimed.
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in nltk.downloader in nltk/nltk versions <= 3.9.4 allows for cross-package resource and model poisoning. The downloader extracts package archives into shared namespaces such as corpora/ and taggers/ instead of package-isolated roots, and validates package integrity only after the archive has been written and extracted. This design flaw enables one package to overwrite another package's trusted resources within the same namespace, making the changes immediately active through ordinary NLTK APIs. This issue persists across fresh interpreter restarts and can affect downstream workflows, including machine learning pipelines and reproducibility-sensitive environments.
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
nltk.pathsec provides an SSRF filter that NLTK documents as a security control, blocking loopback, private, link-local, and multicast ranges (including obfuscated forms) and recommending strict ENFORCE mode for security-sensitive environments. The filter is bypassable by DNS rebinding: validatenetworkurl() resolves the hostname and checks the resulting IP, but the actual HTTP connection re-resolves the hostname independently at connect time and connects to that second result. The validated IP is never the one connected to. An attacker controlling DNS for a hostname (a TTL-0 rebinding record) returns a public IP for the validation lookup and an internal/loopback IP for the connection lookup, defeating the filter even under nltk.pathsec.ENFORCE = True. Details urlopen() validates, then hands the raw hostname to urllib, which performs a second name resolution deep in the connection layer (http.client.HTTPConnection.connect → socket.createconnection → socket.getaddrinfo). The…
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ReviewsCorpusReader extracts feature annotations of the form label followed by a bracketed signed digit (e.g. a label then [+2]) from each review line, using the module-level FEATURES regex. The feature-label sub-pattern is unbounded — an optional greedy run of word-plus-whitespace groups followed by another word, which must then be followed by a literal . On a long bracket-less line the label can match from every search position to the end of the line, causing quadratic backtracking. A single crafted line in a reviews corpus hangs reviews(), features(), and sents(). Details The label alternative is a greedy, unanchored run of word-plus-whitespace groups followed by a word, which must then be followed by a literal [. On an input that is a long sequence of word-plus-whitespace with no bracket, at each of the n starting positions the engine greedily extends the label to the end of the line, only then fails to find the bracket, and backtracks the whole way. re.findall repeats…
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path-traversal vulnerability in NKJPCorpusReader allows an attacker who can influence the fileids argument of its public read methods (header, raw, words, sents, taggedwords) to read files outside the corpus root. The reader builds the file path with no containment check and opens it with the builtin open(), so it bypasses NLTK's nltk.pathsec sandbox — including the strict ENFORCE = True mode that SECURITY.md recommends for web/multi-tenant deployments. header() returns the parsed content of the out-of-root file to the caller (arbitrary file read). Details SECURITY.md promises that file access is "validated against allowed NLTK data directories" and that with nltk.pathsec.ENFORCE = True "unauthorized file access … will raise PermissionError." That guarantee is enforced via FileSystemPathPointer.open() / CorpusReader.open(), which call nltk.pathsec.validatepath(...). NKJPCorpusReader never uses that protected path. In nltk/corpus/reader/nkjp.py: - addroot() builds the…
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FramenetCorpusReader.frame(name) interpolates a caller-supplied frame name into an XML file path that is read with the builtin open(), bypassing CorpusReader.open() and the nltk.pathsec sandbox — including strict ENFORCE=True mode. A ../ sequence in the name escapes the corpus root, yielding an arbitrary XML file read whose parsed content is returned to the caller. Details framebyname builds the path by joining the corpus root, the frame directory, and the caller-supplied name with a fixed .xml extension, with no containment check, then constructs an XMLCorpusView from that string path. Because the view is built from a string rather than a PathPointer, it reads with the builtin open(), so nltk.pathsec.validatepath() is never invoked and ENFORCE=True does not block the access. This is the same path-traversal class previously hardened for the generic corpus readers; framebyname never goes through CorpusReader.open(), so that protection does not apply. The same…
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
NLTK (Natural Language Toolkit) before version 3.9.3 contains an eval injection vulnerability in the nltk.collocations module that allows an attacker who controls command-line arguments to execute arbitrary Python code. When collocations.py is invoked directly, the main block passes command-line arguments directly to eval() as suffixes of BigramAssocMeasures without allowlist validation or sanitization, enabling an attacker to supply a Python expression that escapes the intended attribute lookup and executes arbitrary code including OS commands via the os module.
Recommended action: Upgrade to 3.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In nltk/nltk versions 3.9.3 and earlier, five Stanford interface classes (StanfordPOSTagger, StanfordNERTagger, StanfordParser, StanfordDependencyParser, and StanfordNeuralDependencyParser) are vulnerable to untrusted JAR code execution. These classes accept user-controllable JAR paths and execute them via the java() function, which invokes subprocess.Popen() without integrity verification. This vulnerability is identical to CVE-2026-0848, which was fixed for StanfordSegmenter by adding SHA256 verification. However, the fix was not applied to these additional classes, leaving them susceptible to arbitrary code execution when loading untrusted JAR files.
Recommended action: Upgrade to 3.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
nltk.data.load() and nltk.data.find() resolve user-supplied resource names to filesystem paths using url2pathname(), which decodes percent-encoded sequences (e.g. %2e%2e to ..). Path safety checks are performed on the raw, still-encoded string before decoding occurs. An attacker supplying %2e%2e instead of .. bypasses all path validation and reads arbitrary files outside the NLTK data directory. Vulnerable Code nltk/data.py - find() function: url2pathname() decodes %2e%2e - .. AFTER any safety check p = os.path.join(path, url2pathname(resourcename)) if os.path.exists(p): return FileSystemPathPointer(p) Proof of Concept import nltk.data nltk.data.path = ["/home/user/nltkdata"] %2e%2e decodes to .. via url2pathname(), escaping the data dir data = nltk.data.load("%2e%2e/SECRETcredentials.txt", format="raw") print(data) b'AWSSECRETKEY=AKIAIOSFODNN7EXAMPLE\nDATABASEPASS=hunter2\n' All of these bypass path checks and decode identically: Payload After url2pathname() %2e%2e/secret…
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
nltk.data.load() in NLTK is vulnerable to path traversal via URL-encoded path separators and traversal segments when using the nltk: URL scheme. The unsafe-path regex check is performed before url2pathname() decodes the %xx sequences (a classic decode-after-check / TOCTOU-style flaw), allowing an attacker to bypass the protection documented in NLTK's SECURITY.md and read arbitrary files from the filesystem. While literal traversal strings such as ../../../etc/passwd are correctly blocked, encoded variants such as %2fetc%2fpasswd, %2e%2e%2f..., and ..%2f..%2f slip past the regex and are subsequently decoded into a real filesystem path. Affected Component nltk/data.py — find(), normalizeresourceurl(), and the UNSAFENOPROTOCOLRE regex check. Relevant occurrences: data.py L650–L653 — final path constructed from url2pathname(resourcename) after checks data.py L54–L69 — UNSAFENOPROTOCOLRE operates only on the undecoded string data.py L219–L245 — normalizeresourceurl() for nltk:…
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Description The NLTK downloader does not validate the `subdir` and `id` attributes when processing remote XML index files. Attackers can control a remote XML index server to provide malicious values containing path traversal sequences (such as `../`), which can lead to: 1. Arbitrary Directory Creation: Create directories at arbitrary locations in the file system 2. Arbitrary File Creation: Create arbitrary files 3. Arbitrary File Overwrite: Overwrite critical system files (such as `/etc/passwd`, `~/.ssh/authorized_keys`, etc.) Vulnerability Principle Key Code Locations 1. XML Parsing Without Validation (`nltk/downloader.py:253`) ```python self.filename = os.path.join(subdir, id + ext) ``` - `subdir` and `id` are directly from XML attributes without any validation 2. Path Construction Without Checks (`nltk/downloader.py:679`) ```python filepath = os.path.join(download_dir, info.filename) ``` - Directly uses `filename` which may contain path…
Recommended action: Upgrade to 3.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
nltk.app.wordnetapp allows unauthenticated remote shutdown of the local WordNet Browser HTTP server when it is started in its default mode. A simple GET /SHUTDOWN%20THE%20SERVER request causes the process to terminate immediately via os.exit(0), resulting in a denial of service. Details The vulnerable logic is in nltk/app/wordnetapp.py: - nltk/app/wordnetapp.py:242 - The server listens on all interfaces: - server = HTTPServer(("", port), MyServerHandler) - nltk/app/wordnetapp.py:87 - Incoming requests are checked for the exact path: - if unquoteplus(sp) == "SHUTDOWN THE SERVER": - nltk/app/wordnetapp.py:88 - The shutdown protection only depends on servermode - nltk/app/wordnetapp.py:93 - In the default mode (runBrowser=True, therefore servermode=False), the handler terminates the process directly: - os.exit(0) This means any party that can reach the listening port can stop the service with a single unauthenticated GET request when the browser is started in its normal mode.…
Recommended action: Upgrade to 3.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
nltk.app.wordnetapp contains a reflected cross-site scripting issue in the lookup... route. A crafted lookup<payload URL can inject arbitrary HTML/JavaScript into the response page because attacker-controlled word data is reflected into HTML without escaping. This impacts users running the local WordNet Browser server and can lead to script execution in the browser origin of that application. Details The vulnerable flow is in nltk/app/wordnetapp.py: - nltk/app/wordnetapp.py:144 - Requests starting with lookup are handled as HTML responses: - page, word = pagefromhref(sp) - nltk/app/wordnetapp.py:755 - pagefromhref() calls pagefromreference(Reference.decode(href)) - nltk/app/wordnetapp.py:769 - word = href.word - nltk/app/wordnetapp.py:796 - If no results are found, word is inserted directly into the HTML body: - body = "The word or words '%s' were not found in the dictionary." % word This is inconsistent with the search route, which does escape user input: -…
Recommended action: Upgrade to 3.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
JSONTaggedDecoder.decodeobj() in nltk/jsontags.py calls itself recursively without any depth limit. A deeply nested JSON structure exceeding sys.getrecursionlimit() (default: 1000) will raise an unhandled RecursionError, crashing the Python process. Affected code File: nltk/jsontags.py, lines 47–52 Proof of Concept Impact Any code path that passes externally-supplied JSON to JSONTaggedDecoder is vulnerable to denial of service. The severity depends on whether such a path exists in the calling code (e.g. nltk/data.py). Suggested Fix Add a depth parameter with a hard limit:
Recommended action: Upgrade to 3.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
NLTK versions <=3.9.2 are vulnerable to arbitrary code execution due to improper input validation in the StanfordSegmenter module. The module dynamically loads external Java .jar files without verification or sandboxing. An attacker can supply or replace the JAR file, enabling the execution of arbitrary Java bytecode at import time. This vulnerability can be exploited through methods such as model poisoning, MITM attacks, or dependency poisoning, leading to remote code execution. The issue arises from the direct execution of the JAR file via subprocess with unvalidated classpath input, allowing malicious classes to execute when loaded by the JVM.
Recommended action: Upgrade to 3.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in NLTK versions up to and including 3.9.2 allows arbitrary file read via path traversal in multiple CorpusReader classes, including WordListCorpusReader, TaggedCorpusReader, and BracketParseCorpusReader. These classes fail to properly sanitize or validate file paths, enabling attackers to traverse directories and access sensitive files on the server. This issue is particularly critical in scenarios where user-controlled file inputs are processed, such as in machine learning APIs, chatbots, or NLP pipelines. Exploitation of this vulnerability can lead to unauthorized access to sensitive files, including system files, SSH private keys, and API tokens, and may potentially escalate to remote code execution when combined with other vulnerabilities.
Recommended action: Upgrade to 3.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A critical vulnerability exists in the NLTK downloader component of nltk/nltk, affecting all versions. The unzipiter function in nltk/downloader.py uses zipfile.extractall() without performing path validation or security checks. This allows attackers to craft malicious zip packages that, when downloaded and extracted by NLTK, can execute arbitrary code. The vulnerability arises because NLTK assumes all downloaded packages are trusted and extracts them without validation. If a malicious package contains Python files, such as init.py, these files are executed automatically upon import, leading to remote code execution. This issue can result in full system compromise, including file system access, network access, and potential persistence mechanisms.
Recommended action: Upgrade to 3.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
NLTK through 3.8.1 allows remote code execution if untrusted packages have pickled Python code, and the integrated data package download functionality is used. This affects, for example, averagedperceptrontagger and punkt.
Recommended action: Upgrade to 3.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
NLTK is vulnerable to REDoS in some RegexpTaggers used in the functions getpostagger and maltregextagger.
Recommended action: Upgrade to 3.6.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.