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.
The StanfordSegmenter module dynamically loads external Java .jar files without verification or isolation (sandboxing). The JAR file is executed directly by subprocess with an unvalidated classpath parameter, allowing the JVM to load malicious classes at the moment of module import. An attacker can provide or substitute a JAR file using techniques such as model poisoning, MITM attack, or dependency poisoning. As a result, any Java bytecode contained in the malicious JAR file is executed in the context of the process.
An attacker can gain full control over the system by executing arbitrary code (RCE), which threatens the confidentiality, integrity, and availability of the environment in which the application using NLTK operates.
Patches available from the vendor should be applied in accordance with the references. Until updates are applied, it is recommended to avoid using the StanfordSegmenter module and to verify the integrity of all external JAR files used by the application.
NLTK (Python package) in versions 3.9.2 and earlier that uses the StanfordSegmenter module.
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:HNltk
APPNltk≤ 3.9.2
Related vulnerabilities
NLTK versions before 3.10.3 contain a remote code execution vulnerability in allowlisted pickle loaders that t...
NLTK before 3.10.0 (affected versions <=3.9.4) contains an unsafe pickle deserialization vulnerability in the ...
NLTK before 3.10.3 fails to validate JVM options passed through the per-call options parameter in the java() f...
NLTK before 3.9.3 fails to verify file integrity after downloading packages and before extraction in the downl...
nltk PorterStemmer in versions <= 3.10.2 (fixed in 3.10.3) contains an inefficient-algorithmic-complexity deni...