CVE-2026-79675: nltk (PyPI)

Should you act?

Critical and remotely reachable

No known exploitation yet, but it is network-reachable without credentials. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

Not in CISA KEV, but CISA’s SSVC assessment records a public proof-of-concept, so attack code exists.
EPSS 0.8%, percentile 55: FIRST’s model estimates a 0.8% chance of exploitation activity in the next 30 days, higher than 55% of all scored CVEs (moderate). EPSS is a probability, not a verdict.
Remotely reachable with no login and no user interaction. If the vulnerable service is exposed to the internet, prioritize it.
Only applies if your dependency tree includes nltk (PyPI) <= 3.10.2, fixed in 3.10.3. Check your lockfile, including transitive dependencies.

What it is

NLTK before 3.10.3 fails to validate JVM options passed through the per-call options parameter in the java() function, allowing attackers to inject dangerous JVM flags. Attackers can supply malicious options like -agentpath, -javaagent, or @argfile to Stanford wrapper classes to achieve arbitrary code execution.

From the GitHub advisory

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:

Weakness type: CWE-88.

Product: nltk (PyPI) · Assigned by: VulnCheck · Published: 2026-08-25

Affected and fixed versions

Ecosystem	Package	Vulnerable	First fixed
PyPI	`nltk`	<= 3.10.2	3.10.3

Vendor	Product	Affected versions (per CVE record)
nltk	nltk	< 3.10.3

Severity scores

Scored by	CVSS	Score	Vector
VulnCheck	4.0	9.3 Critical	`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`
VulnCheck	3.1	9.8 Critical	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`
GitHub	4.0	9.3	`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`

Attack vector: network (remotely reachable)
Attack complexity: low
Attack requirements: none
Privileges required: none (no login)
User interaction: none

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
CISA SSVC assessment: exploitation poc, automatable yes, technical impact total.
FIRST EPSS (model of 2026-10-21): 0.78% probability of exploitation activity in the next 30 days; percentile 55.

Timeline

2026-08-25 — CVE record published by VulnCheck
2026-08-27 — CVE record last updated
2026-09-01 — GitHub-reviewed advisory GHSA-m4rf-3fr8-xwx3 published (critical)

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.