Skip to main content
VulnerabilityPublished

CVE-2026-0848: nltk/nltk · Improper Input Validation

Affects nltk/nltkSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 10.0 Critical.

Data as of 30 Oct 2026, 06:59 UTC

CVSS 3.0 base score
10.0Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.7% chance of exploitation in 30 days – higher than 56% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 5 Mar 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: evidence found.

    Public exploit code: GitHub proofs of concept

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), GitHub proofs of concept, the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
nltknltk/nltkAffected
  • ≥ unspecified, ≤ latest
Fixed in–
PyPInltkpkg:pypi/nltkOther threatsAffected
  • <=3.9.2
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

To mitigate CVE-2026-0848 effectively, organizations should take immediate and specific actions beyond generic advice: 1) Avoid using the StanfordSegmenter module in NLTK versions ≤3.9.2 until a patched version is released. 2) Implement strict controls on the source and integrity of Java .jar files used by NLP pipelines, including cryptographic verification (e.g., signatures or hashes) before loading. 3) Employ network-level protections such as TLS with certificate pinning to prevent MITM attacks on JAR file downloads. 4) Use application sandboxing or containerization to isolate the execution environment of NLP components, limiting the impact of potential code execution. 5) Monitor and audit file system and subprocess calls related to Java JAR loading to detect anomalous or unauthorized modifications. 6) Review and harden dependency management practices to prevent dependency poisoning, including locking dependencies to known good versions and using trusted repositories. 7) Consider alternative NLP tools or segmentation modules that do not rely on dynamic loading of external code until this vulnerability is resolved. 8) Stay informed about updates from the NLTK project and apply patches promptly once available. 9) Conduct threat modeling and penetration testing focused on the NLP pipeline to identify and remediate similar risks. These targeted mitigations reduce the attack surface and help contain potential exploitation.

Description

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.

References

Community reviews

Loading reviews…