GHSA-p3m8-78j2-g5p3: Path Traversal
NLTK's pathsec.py security module defaults to ENFORCE=False (line 24), which means all 8 security validation functions only emit RuntimeWarning instead of raising exceptions when violations are detected.
The pathsec module was introduced as the fix for CVE-2024-39705 (arbitrary code execution via pickle) and CVE-2026-0846 (path traversal). However, with ENFORCE=False as the default:
1. pathsec.open('/etc/passwd') succeeds (reads the file, emits warning) 2. pathsec.validatenetworkurl('http://169.254.169.254/...') succeeds (warning only) 3. pickle.loads() via nltk.data.load() proceeds despite unsafe source (warning only)
Every security gate follows the same pattern: python ENFORCE = os.environ.get('NLTKPATHSECENFORCE', '').lower() in ('1', 'true', 'yes')
def validatesomething(path): if isviolation(path): if ENFORCE: raise SecurityError('...') # Only raised when env var is set else: warnings.warn('...', RuntimeWarning) # Default: warning only # Execution continues regardless
This means the security remediations for CVE-2024-39705 and CVE-2026-0846 are effectively disabled by default. Any user who installed NLTK 3.9.x expecting the security fixes to be active is still vulnerable unless they manually set NLTKPATHSECENFORCE=1.
PoC: python import nltk.pathsec import warnings
Show that ENFORCE is False by default print(f'ENFORCE = {nltk.pathsec.ENFORCE}') # False
Attempt to read /etc/passwd through pathsec -- should be blocked with warnings.catchwarnings(record=True) as w: warnings.simplefilter('always') result = nltk.pathsec.open('/etc/passwd', 'r') print(f'File opened: {result.name}') # /etc/passwd print(f'Warning emitted: {w[0].message}') # RuntimeWarning (not an exception) # Attack succeeds -- file is readable
The correct default is fail-secure: ENFORCE should be True unless explicitly disabled. The current default makes the security module opt-in rather than opt-out, defeating its purpose.
Suggested fix: Change default to ENFORCE=True. Users who need backwards compatibility can set NLTKPATHSECENFORCE=0 to explicitly disable.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/nltkto a version that resolves this vulnerability.Fixed in 3.10.0 - Configuration
Change the module default behavior to be fail-secure by setting ENFORCE to True by default (ENFORCE should be enabled unless explicitly disabled). Concretely, configure the environment variable NLTK_PATHSEC_ENFORCE=1 so that ENFORCE is True (instead of the current default ENFORCE=False which only emits RuntimeWarning and does not raise exceptions for CVE-2024-39705 and CVE-2026-0846 protections).
NLTK pathsec.py security module NLTK_PATHSEC_ENFORCE = 1 - Configuration
Only if backwards compatibility is required, explicitly disable the security gates by setting NLTK_PATHSEC_ENFORCE=0 (the module currently treats ENFORCE=False as default and turns validation failures into RuntimeWarning instead of exceptions).
NLTK pathsec.py security module NLTK_PATHSEC_ENFORCE = 0
Event History
Frequently Asked Questions
Is a default NLTK deployment protected by these validation checks?
No. Enforcement is disabled unless NLTK_PATHSEC_ENFORCE is set to a recognized truthy value, so detected violations generate RuntimeWarning messages and execution continues.
What is required to make the checks block unsafe operations?
Set the NLTK_PATHSEC_ENFORCE environment variable to 1, true, or yes (case-insensitive). With enforcement enabled, validation failures raise SecurityError instead of only issuing a warning.
Who is exposed in practice?
Users running NLTK 3.9.x who expected the pathsec-based fixes for the referenced pickle and path-traversal issues to be active remain exposed when enforcement has not been enabled. This includes uses where NLTK processes unsafe file paths, network URLs, or pickle-backed data sources.
How can I determine whether enforcement is currently inactive?
Check whether NLTK_PATHSEC_ENFORCE is unset or is not one of 1, true, or yes. In that state, pathsec validation violations produce RuntimeWarning messages while allowing the underlying operation to proceed.