Loading vulnerability…
CVE-2026-0848 is an arbitrary code execution vulnerability in the StanfordSegmenter module of NLTK versions 3.9.2 and earlier. The module loads external Java JAR files without integrity verification or sandboxing and executes Java through a subprocess using unvalidated classpath input. An attacker able to supply or replace a loaded JAR can cause malicious classes to execute when loaded by the JVM, including at import time. Model poisoning, man-in-the-middle attacks, and dependency poisoning can provide exploitation avenues.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (2 hidden).
This repository is a functional local proof-of-concept exploit for CVE-2026-0848, targeting NLTK's StanfordSegmenter JAR-loading behavior. It is not part of a larger exploit framework. The repository contains three code files: exploit.py, which orchestrates prerequisite checks, optional dependency installation, malicious JAR creation, exploit triggering, and post-exploitation verification; create_malicious_jar.py, which builds a crafted JAR by placing a Java class at the package path edu/stanford/nlp/ie/crf/CRFClassifier.java, compiling it with javac, and packaging it with jar; and payloads/Payload.java, the Java payload whose static initializer executes immediately when the class is loaded. The exploit capability is arbitrary code execution in the context of the local user running the Python process. The included payload is simple but real: it runs the shell command touch /tmp/pwned_cve_2026_0848 via Runtime.getRuntime().exec and prints OS name, username, and working directory. The exploit then attempts a normal segmentation call through StanfordSegmenter to demonstrate that malicious behavior can occur during expected library usage. The verification routine checks for the marker file to confirm successful execution. Repository structure is straightforward: README.md explains usage and prerequisites; requirements pins nltk==3.9.2; docs/expected_output.txt shows a sample successful run. There are no network callbacks, remote C2 endpoints, hardcoded IPs, or URLs in the exploit logic itself. The main fingerprintable artifacts are local filesystem paths and Java package/class names used to masquerade as the expected Stanford NLP class. Overall, this is an operational PoC demonstrating unsafe loading of an attacker-controlled JAR through NLTK StanfordSegmenter, with a hardcoded payload and local confirmation artifact.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
17 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
An arbitrary-code-execution vulnerability in NLTK's StanfordSegmenter module. An attacker able to supply or replace an externally loaded Java JAR can cause arbitrary Java bytecode execution at import time.
An untrusted JAR code execution vulnerability affecting NLTK's StanfordSegmenter, referenced as the previously fixed counterpart to CVE-2026-12252. Its fix added SHA256 verification but was not extended to the five additional Stanford wrapper classes discussed in this advisory.
Arbitrary code execution / remote code execution risk in NLTK (<= 3.9.2) StanfordSegmenter due to unvalidated dynamic loading/execution of external Java JARs via subprocess/classpath, enabling malicious bytecode execution (e.g., via model/dependency poisoning or MITM).
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.