Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| nltk | pip | <= 3.9.4 |
Miggo AIRoot Cause AnalysisThe vulnerability (GHSA-8vh5-mgjj-w6hg, a duplicate of GHSA-p3m8-78j2-g5p3) stems from an insecure default configuration in NLTK's pathsec.py module. Specifically, the ENFORCE flag was set to False by default in versions prior to 3.10.0. This meant that security validation functions, which were designed to prevent path traversal and pickle deserialization vulnerabilities, would only emit warnings instead of raising exceptions when a security violation was detected. This effectively disabled the security controls, allowing attackers to exploit these vulnerabilities.
My analysis focused on identifying the functions within pathsec.py that implement these security checks and are governed by the ENFORCE flag. Although direct access to the vulnerable file content with ENFORCE = False was not possible due to tool limitations (fetching the latest version of the file on the default branch, which is already patched), the advisory explicitly states the nature of the vulnerability and points to pathsec.py and the ENFORCE flag on line 24.
By examining the structure of the pathsec.py file (from a patched version, which still shows the conditional logic), it's clear that the nltk.pathsec.validate_path function contains multiple instances of if ENFORCE: raise ... else: warnings.warn(...) blocks. These blocks are responsible for checking for various malicious path patterns (NUL bytes, URLs in file paths, path traversals, unauthorized CWD access). When ENFORCE was False, these critical checks would fail silently (with a warning), allowing the malicious input to be processed.
The advisory also mentions pathsec.open() and nltk.data.load() as entry points that would trigger these bypassed security controls. While the exact implementation of pathsec.open() was not available, it is understood to be a wrapper that would utilize validate_path for its security checks. Therefore, nltk.pathsec.validate_path is the core vulnerable function where the security logic is bypassed due to the ENFORCE=False default.
nltk.pathsec.validate_pathnltk/pathsec.py