CVE-2026-79675 in NLTK
Summary
by MITRE • 08/25/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The Natural Language Toolkit (NLTK) is a widely used Python library for symbolic and statistical natural language processing that includes interfaces to external Java-based NLP tools such as the Stanford CoreNLP suite. A critical security vulnerability exists in versions of NLTK prior to 3.10.3 regarding how it handles configuration parameters passed to the java() function, which serves as a wrapper for invoking JVM processes from within Python scripts. This flaw stems from an insufficient validation mechanism when processing the per-call options parameter, allowing attackers who have control over this input vector to inject arbitrary Java Virtual Machine flags directly into the command line arguments used to launch the external process.
The technical nature of this vulnerability is classified as CWE-78 Improper Neutralization of Special Elements used in an OS Command or CWE-94 Code Injection depending on the specific execution context, but it fundamentally represents a failure to sanitize user-supplied input before passing it to system-level interfaces. By manipulating the options parameter, an attacker can introduce dangerous JVM startup flags such as -agentpath, -javaagent, or argfile. These flags are powerful mechanisms within the Java ecosystem that allow for deep integration with the runtime environment. For instance, the -javaagent flag permits loading a pre-compiled agent JAR file into the target JVM process before main() execution begins, while -agentpath allows specifying native libraries to be loaded via JNI. The argfile feature enables reading additional command-line arguments from a specified file, which can further facilitate complex injection chains if the attacker has write access to certain directories or can influence environment variables that dictate temporary file locations.
The operational impact of this vulnerability is severe, as it leads directly to Arbitrary Code Execution on the host system where NLTK is deployed. When an application utilizes NLTK to process text data and passes untrusted content into the options parameter for Stanford wrapper classes, a malicious actor can exploit this flaw to execute arbitrary Java code within the context of the JVM instance launched by NLTK. This effectively bypasses standard Python sandboxing measures because the execution occurs in a separate native process with its own permissions and capabilities. If the underlying system runs the application with elevated privileges or if the injected agent exploits other vulnerabilities in the installed JRE, the attacker may gain full control over the server infrastructure, leading to data exfiltration, lateral movement within the network, or complete compromise of the host environment.
This vulnerability aligns with MITRE ATT&CK technique T1059 Command and Scripting Interpreter, specifically sub-techniques related to Java execution such as T1620 Reflective Code Loading if agents are used for stealthy injection, or generally T1053 Scheduled Task/Job which may be leveraged if the agent sets up persistent backdoors. The lack of input validation represents a classic insecure configuration and command injection pattern often seen in libraries that bridge high-level scripting languages with lower-level system binaries without adequate sanitization layers.
To mitigate this risk, organizations must immediately upgrade NLTK to version 3.10.3 or later where the issue has been addressed through stricter input filtering and validation of JVM options. In environments where upgrading is not immediately feasible, developers should implement strict allow-listing for any parameters passed to the java() function, ensuring that only known safe flags are permitted while blocking all potentially dangerous arguments like -agentpath, -javaagent, and @argfile. Additionally, applying principle of least privilege by running NLTK processes with minimal necessary permissions can reduce the blast radius in case an exploitation attempt occurs. Regular security audits of third-party library usage patterns and input handling mechanisms are essential to prevent similar injection vulnerabilities in future deployments.