The vulnerability in NLTK's Stanford Java wrappers stems from incomplete validation of JVM options. While the global configuration path (config_java()) validates and blocks dangerous JVM flags such as -agentlib, -agentpath, -javaagent, -Xrunjdwp, and @argfile, the per-call java() function introduced in a prior fix does not perform this validation. Four wrapper classes (GenericStanfordParser, StanfordTagger, StanfordTokenizer, and StanfordSegmenter) accept user-supplied java_options and pass them through the unvalidated per-call path, effectively bypassing the earlier fix. This allows an attacker controlling java_options to inject arbitrary JVM flags, potentially leading to arbitrary code execution. The recommended fix is to add _validate_java_options() call within the java() function for per-call options.

If exploited, an attacker who can control the java_options parameter in any of the affected NLTK Stanford wrapper classes can inject arbitrary JVM flags. This includes loading malicious native agents or Java agents, enabling remote debugging, or expanding argument files to smuggle malicious flags. Such actions can lead to arbitrary code execution on the host running the NLTK service. This is particularly impactful in deployments where java_options are derived from untrusted user input or configuration sources.

A patch is available that adds validation of JVM options in the per-call java() function, closing the bypass. Users should update to the fixed version of NLTK that includes this patch. Until patched, avoid passing untrusted input to the java_options parameter of the affected Stanford wrapper classes. Do not rely solely on config_java() for JVM option validation, as it does not cover per-call options.