NLTK PyPI Package SSRF Vulnerability: Early Warning
- Severity
- HIGH
- Affected component
- nltk (pypi)
- Affected versions
- >= 3.8, <= 3.8 or >= 3.7, <= 3.7 or >= 3.6.7, <= 3.6.7 or >= 3.6.6, <= 3.6.6 or >= 3.6.5, <= 3.6.5 or >= 3.6.2, <= 3.6.2 or >= 3.6.1, <= 3.6.1 or >= 3.6, <= 3.6 or >= 3.5, <= 3.5 or >= 3.5b1, <= 3.5b1 or >= 3.4.4, <= 3.4.4 or >= 3.4.3, <= 3.4.3 or >= 3.4.1, <= 3.4.1 or >= 3.4, <= 3.4 or >= 3.3, <= 3.3 or >= 3.2.5, <= 3.2.5 or >= 3.2.4, <= 3.2.4 or >= 3.2.3, <= 3.2.3 or >= 3.2.2, <= 3.2.2 or >= 3.2.1, <= 3.2.1 or >= 3.2, <= 3.2 or >= 3.1, <= 3.1 or >= 3.0.5, <= 3.0.5 or >= 3.0.4, <= 3.0.4 or >= 3.0.3, <= 3.0.3 or >= 3.0.2, <= 3.0.2 or >= 3.0.0b1, <= 3.0.0b1 or >= 3.0a4, <= 3.0a4 or >= 2.0.1rc4, <= 2.0.1rc4 or >= 2.0.1rc3, <= 2.0.1rc3 or >= 2.0.1rc2, <= 2.0.1rc2 or >= 2.0.1rc1, <= 2.0.1rc1
- Patched version
- 3.10.3
An SSRF vulnerability has been reported in the NLTK package on PyPI. Users of affected versions are advised to upgrade.
What happened
An SSRF vulnerability has been identified in the NLTK package on PyPI. The vulnerability lies in the validate_network_url() function, which fails open when DNS resolution returns an error, potentially allowing SSRF attacks on cloud metadata endpoints. This issue is tracked under CVE-2024-39705, CVE-2026-33236, and GHSA-3GQM-FCW5-W839. The vulnerability affects a wide range of NLTK versions, from 3.8 down to 2.0.1rc1.
To assess your exposure, check if your project or dependencies include any of the affected NLTK versions. The vulnerability has not been exploited in the wild as of the latest reports, but it is recommended to take preventive action by upgrading to a patched version.
What to do about it
- Upgrade to NLTK version 3.10.3 or later to mitigate the SSRF vulnerability.
- Review your project dependencies to ensure no affected NLTK versions are in use.
- Monitor the primary sources for any updates or additional information on the vulnerability.
How 0Day would have caught this
nltk is anywhere in your dependency tree, the engineers who own the affected repositories get a push alert the moment it is flagged — no manual audit to remember to run.Read how this differs from waiting on a scanner to catch a known advisory, or see the exact, read-only access 0Day needs to do this for an organization.
Frequently asked questions
Am I affected?
You are affected if your project uses NLTK versions from 3.8 down to 2.0.1rc1.
What should I do right now?
Upgrade to NLTK version 3.10.3 or later to mitigate the vulnerability.
Has this been exploited in the wild?
There are no reports of this vulnerability being exploited in the wild as of the latest information.
Sources
- [GHSA-rhp5-r9x4-f5g2] NLTK: Unsafe Pickle Deserialization in TransitionParser Allows Remote Code Execution
- [GHSA-x99w-6fgc-pmfw] NLTK: Allowlisted pickle loaders still permit code execution in current source
- [GHSA-3gq4-3j92-5w49] NLTK: Corpus Reader Sandbox Bypass
- [GHSA-3gqm-fcw5-w839] NLTK: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure
- [GHSA-568f-pv23-39p4] NLTK: Stable FrameNet and NKJP readers parse outside-root XML