NLTK EUVD-2026-98660

Exploitation requires an application that uses NLTK's WekaClassifier AND passes attacker-controllable values into the model_filename or model argument; a functioning Weka Java/JVM toolchain must also be installed and invoked. Under these conditions the nltk.pathsec containment that normally restricts paths to allowed data roots is bypassed, enabling file writes (Weka -d) or existence probes (Weka -l) outside those roots. Limiting factors: this is a non-default, niche integration - the vast majority of NLTK deployments never invoke WekaClassifier - and the attacker must control the specific model-path argument. The CVSS PR:N indicates no authentication to the vulnerable function itself, but AT:P reflects the required application-wiring/configuration precondition.

The CVSS 4.0 score of 8.3 (High) is driven by a network vector with low complexity and no required privileges (AV:N/AC:L/PR:N/UI:N), combined with a high integrity impact (VI:H) reflecting arbitrary file write via the Weka '-d' option. However, the vector also carries AT:P (Attack Requirements: Present), which signals that exploitation is NOT unconditional - it depends on an application actually routing attacker-controlled input into the WekaClassifier model_filename/model argument. No EPSS score, CISA KEV listing, or public exploit was provided in the intelligence, so exploitation status is 'no public exploit identified at time of analysis.' Signals are therefore consistent but modest: the flaw is legitimately network-reachable and unauthenticated at the function level, yet the AT:P requirement plus the niche nature of the WekaClassifier integration (which needs an installed Weka JVM) sharply narrows the realistically exploitable population. This reads as a real-but-situational issue rather than a mass-exploitation priority: treat it as high-priority ONLY where an application exposes Weka classification with user-influenced model paths. Note that EPSS/KEV/POC data were absent from the input, so widespread-exploitation likelihood could not be quantified and should be verified against VulnCheck/EPSS feeds.

An application that calls NLTK's WekaClassifier and lets a user influence the model_filename or model argument is targeted by a remote attacker who supplies a path containing traversal sequences. Because the input bypasses nltk.pathsec containment, the invoked Weka JVM writes attacker-chosen files (via -d) or probes for file existence (via -l) outside the permitted data roots. No public proof-of-concept was identified in the provided intelligence.