# CVE-2026-62388: nltk RCE — Fixed in 3.10.0 | O3 Security

🐍 PyPI

Not in CISA KEV

# CVE-2026-62388 — nltk

[Fix: nltk/nltk#3593](https://github.com/nltk/nltk/pull/3593)

CVE-2026-62388 is a CWE-1188 vulnerability in nltk. A fix is available for nltk — see the affected versions and patch details below.

NLTK before 3.10.0 Insecure Default Configuration in pathsec.py

Also known as[GHSA-p3m8-78j2-g5p3](/vulnerability/GHSA-p3m8-78j2-g5p3)PYSEC-2026-3722

Published

Aug 22, 2026

Updated

Aug 30, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 5, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

## Exploitation Status

### Proof-of-concept exploit code exists

-   CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
-   CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-62388.

## EPSS Exploitation Probability

[via FIRST.org ↗](https://www.first.org/epss/)

0.5%probability of exploitation in next 30 days

Lower Risk+0.06%

Lower risk than most CVEs42th percentile — riskier than 42% of all scored CVEsHighest risk

0.00%0.34%0.67%1.01%0.5%0.5%Sep 26Oct 26

Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/).

## Real-World Exposure

1 pkg affected

🐍`nltk`

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

## Description

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.validate\_network\_url('[http://169.254.169.254/](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:

```
ENFORCE = os.environ.get('NLTK_PATHSEC_ENFORCE', '').lower() in ('1', 'true', 'yes')

def validate_something(path):
    if is_violation(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 NLTK\_PATHSEC\_ENFORCE=1.

PoC:

```
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.catch_warnings(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 NLTK\_PATHSEC\_ENFORCE=0 to explicitly disable.

## Affected Packages

1 total 1 fixed

Ecosystem

Package

Vulnerable range

Fix

🐍PyPI

`nltk` 

all versions

3.10.0`pip install --upgrade 'nltk==3.10.0'`

## Affected Products

1 product · 1 configurations

Application

`nltk`nltk

< 3.10.0

range

## Detection & mitigation playbook

Open-source dependency

1.  ### Detect
    
    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nltk, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
    
2.  ### Fix
    
    Update nltk to 3.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-62388 is resolved across your whole dependency graph.
    
3.  ### Workarounds
    
    Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
    

## Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

NLTK versions before 3.10.0 in Red Hat products are configured by default to not enforce security validations for path traversal and pickle deserialization. This insecure default allows attackers to bypass these protections, as security controls are only active when manually enabled, increasing the risk of arbitrary…

Workaround published by Red Hat

> To mitigate this issue, ensure that the NLTK security validation enforcement is enabled. This can be achieved by setting \`nltk.internals.pathsec.ENFORCE = True\` in your application's initialization code before processing untrusted data. This change may require restarting any services or applications that utilize NLTK.

Source: [Red Hat security advisory for CVE-2026-62388](https://access.redhat.com/security/cve/cve-2026-62388) (CC BY 4.0)

## Frequently Asked Questions

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.validate\_network\_url('http://169.254.169.254/...') succeeds (warning only) 3. pickle.loads() via nltk.data.load() proceeds despit

O3 Security · Impact-Aware SCA

### Is CVE-2026-62388 in your dependencies?

Find it across PyPI, including transitive dependencies.

[Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)