What is the CVSS score of CVE-2026-12252?

CVE-2026-12252 has a CVSS 3.0 base score of 7.8 (High). CVSS vector: CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of NLTK are affected by CVE-2026-12252?

NLTK (Natural Language Toolkit) versions 3.9.3 and earlier contain an arbitrary code execution vulnerability in Stanford interface wrappers that allows code execution when users load…. A patch is available.

How to fix or mitigate CVE-2026-12252?

Within 24 hours: Identify all systems and applications using NLTK versions 3.9.3 or earlier, particularly those with Stanford wrapper dependencies (StanfordPOSTagger, StanfordNERTagger, StanfordParser, StanfordDependencyParser, StanfordNeuralDependencyParser); audit logs for suspicious JAR file access or loading. Within 7 days: Implement strict path allowlisting for JAR file loading and restrict access to directory trees containing JAR files. Within 30 days: Subscribe to NLTK security advisories and plan immediate deployment of patched versions when released.

NLTK CVE-2026-12252

EUVD-2026-41656 HIGH

Code Injection (CWE-94)

2026-07-04 @huntr_ai

GHSA-9r6g-266r-89x4

RCE Code Injection Red Hat Nltk Suse Nltk Nltk

7.8

CVSS 3.0 · Vendor: huntr_ai

Severity by source

Vendor (huntr_ai) PRIMARY

7.8 HIGH

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

vuln.today AI

7.8 HIGH

Local JAR-path control with a required victim action to load it (AV:L/UI:R); resulting Java code runs as the user, giving full C/I/A impact.

3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

SUSE

HIGH

qualitative

Red Hat

7.8 HIGH

qualitative

Primary rating from Vendor (huntr_ai).

CVSS VectorVendor: huntr_ai

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 04, 2026 - 02:28 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

184 pypi packages depend on nltk (42 direct, 142 indirect)

Ecosystem-wide dependent count for version 3.9.4.

DescriptionCVE.org

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.

AnalysisAI

Arbitrary code execution in the NLTK Python library (nltk/nltk 3.9.3 and earlier) allows an attacker to run untrusted Java code when a victim loads a malicious JAR through five Stanford interface wrappers (StanfordPOSTagger, StanfordNERTagger, StanfordParser, StanfordDependencyParser, StanfordNeuralDependencyParser). These classes pass a user-controllable JAR path to an internal java() helper that calls subprocess.Popen() with no SHA256 integrity check, so a substituted or poisoned JAR executes with the user's privileges. This is a regression of CVE-2026-0848, whose SHA256 verification fix was applied only to StanfordSegmenter and never propagated to these five classes; no public exploit is identified at time of analysis, though a huntr bounty report exists.

Technical ContextAI

NLTK (Natural Language Toolkit) is a widely used Python library for natural language processing that provides thin Python wrappers around external Java tools from the Stanford NLP suite (POS tagging, NER, constituency and dependency parsing). The affected classes shell out to the Java runtime by constructing a command that references a model/JAR path and executing it through the shared java() function, which ultimately invokes subprocess.Popen(). The root cause is CWE-94 (Improper Control of Generation of Code / code injection): because the JAR path is attacker-influenceable and the code launches whatever JAR it is pointed at without verifying its SHA256 hash, malicious bytecode is executed by the JVM. The companion fix for CVE-2026-0848 established that JAR integrity verification is the intended control, making the absence of that check in these five classes the specific defect. The CPE cpe:2.3:a:nltk:nltk/nltk:*:*:*:*:*:*:*:* covers all versions up to and including 3.9.3.

RemediationAI

Upgrade to a fixed NLTK release once published; the provided data does not include an exact patched version number, so this is best described as: no vendor-released fixed version is independently confirmed at time of analysis - track the huntr report (https://huntr.com/bounties/f5c93982-0cc9-4e2e-bb85-1b6ab29a2efb) and the nltk/nltk project for a release that extends the CVE-2026-0848 SHA256 verification to these five classes. As a compensating control, avoid loading Stanford JAR/model files from any path that is user-supplied, world-writable, or downloaded at runtime; pin JARs to a read-only, integrity-checked directory and verify their SHA256 hashes out-of-band before use (trade-off: manual hash management and breakage if legitimate JARs are updated). Where feasible, migrate off the deprecated Stanford interface classes to the maintained CoreNLP server-based API or equivalent, which changes integration effort but removes the local-JAR-execution path entirely; at minimum restrict filesystem permissions on the model directory so only trusted administrators can place JARs.