Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI
Not in CISA KEV

CVE-2026-79657 — nltk

Fix: nltk/nltk@c3e3711

CVE-2026-79657 is a Deserialization of Untrusted Data vulnerability in nltk. A fix is available for nltk — see the affected versions and patch details below.

NLTK before 3.10.3 Remote Code Execution via Unsafe Pickle Deserialization

Also known asGHSA-x99w-6fgc-pmfwPYSEC-2026-3735
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 8, 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.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

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

EPSS Exploitation Probability

via FIRST.org ↗
1.3%probability of exploitation in next 30 days
Lower Risk+0.05%
Lower risk than most CVEs69th percentile — riskier than 69% of all scored CVEsHighest risk
0.71%1.06%1.42%1.77%1.2%1.3%Sep 26Oct 26

Probability of exploitation in the next 30 days, from 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

Summary

The current source tree still allows arbitrary code execution during supposedly safer allowlisted pickle loading. The allowlist trusts whole module namespaces instead of exact safe globals, so crafted pickles can invoke dangerous in-namespace callables through pickle REDUCE.

Details

  • Vulnerability type: Remote code execution via unsafe deserialization
  • Affected component: nltk.picklesec.allowlisted_pickle_load, nltk.tokenize.punkt.punkt_pickle_load, nltk.parse.transitionparser.TransitionParser.parse
  • Affected versions: Current source v3.10.0-rc2; published 3.9.4 was not the claim target for this bypass.
  • Patched versions: Not yet patched
  • Root cause: Module-prefix allowlists include dangerous callables such as nltk.tokenize.repp.ReppTokenizer._execute and numpy.f2py.crackfortran.myeval.

punkt_pickle_load() allowlists both nltk.tokenize.punkt and the whole nltk.tokenize namespace, which exposes ReppTokenizer._execute() and its subprocess.Popen(...) sink during unpickling. TransitionParser.parse() uses allowlisted_pickle_load(..., allowed_modules=("numpy", "scipy", "sklearn")), which permits numpy.f2py.crackfortran.myeval() and its attacker-controlled eval(...) path. I confirmed both gadgets create marker files before the caller returns or later aborts on type misuse.

PoC

Preconditions

  • The application loads an attacker-controlled tokenizer or model artifact through these public loaders.

Steps

  1. Create a pickle whose REDUCE callable is ReppTokenizer._execute and point its command to a harmless marker-file write.
  2. Pass that payload to punkt_pickle_load(BytesIO(payload)) and observe the marker file is created during unpickling.
  3. Create a second pickle whose REDUCE callable is numpy.f2py.crackfortran.myeval and load it through TransitionParser.parse().
  4. Observe the second marker file is created before TransitionParser.parse() later fails on the returned object type.

Minimal reproducible excerpt

{'punkt_marker': 'PUNKT_RCE', 'transitionparser_marker': 'TP_RCE'}

Impact

Any caller that trusts these current allowlisted loaders can still execute attacker-controlled commands while loading model or tokenizer artifacts. This defeats the protection mechanism that replaced unrestricted pickle loading and creates a dangerous false sense of safety.

Remediation

Replace broad module-prefix allowlists with exact (module, qualname) pairs for the few safe classes or functions genuinely required. Do not allow entire namespaces such as nltk.tokenize or numpy, and keep post-load type validation only as a secondary defense.

Resources


Fix + attack demonstration (verified)

  • tightened callers find_class now, before the allowlists:
  1. Rejects any dotted name → closes 4489 with zero legit impact.
  2. Denies dangerous modules (os, subprocess, sys, builtins, numpy.f2py, nltk.tokenize.repp, …) even under a broad allowed_modules — a defense-in-depth backstop so a future too-broad allowlist can't silently reopen RCE.
  3. builtins denied wholesale; safe primitives (int, str, …) must be named exactly via allowed_globals.

Callers tightened: punkt drops the broad nltk.tokenize (keeps nltk.tokenize.punkt + exact collections.defaultdict/builtins.int); transitionparser keeps numpy/scipy/sklearn (array unpickling needs their submodules) with the new guards blocking the gadgets.

Full pickle-sink audit

Every deserialization sink in the tree was reviewed: no raw pickle.load anywhere, and no joblib/numpy/torch/dill/yaml/marshal loaders. data.load + wordnet_app use RestrictedUnpickler (blocks all globals — safe); the remaining pickle_load sites (chartparser_app, tbl/demo) load user-selected or self-written files and keep their warning.

Attack demonstration (captured; fork clone)

=== EXPLOITS blocked ===
  4489 sklearn.os.system (dotted)      -> BLOCKED
  x99w numpy.f2py.crackfortran.myeval  -> BLOCKED
  x99w nltk.tokenize.repp._execute     -> BLOCKED
  backstop os.system (os allowlisted)  -> BLOCKED
  backstop builtins.eval (exact global)-> BLOCKED
=== LEGIT loads still work ===
  punkt round-trip via punkt_pickle_load -> OK
  builtins.int (safe primitive)          -> OK

Tests

test_pickle_allowlist_security.py — added 5 regressions (dotted traversal, both namespace gadgets, denied-module backstop, legit round-trip). Suite: 122 passed / 9 skipped (sklearn-dependent) across pickle/punkt/transition/tokenize. pre-commit (black/isort/ruff) clean.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPInltkall versions3.10.3pip install --upgrade 'nltk==3.10.3'

Affected Products

1 product · 1 configurations
Application
nltknltk
< 3.10.3
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.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-79657 is resolved across your whole dependency graph.

  3. Workarounds

    Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.

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

Red Hat rates the impact of this vulnerability as Important. Exploitation requires the consuming application to load an attacker-supplied artifact through specific NLTK deserialization functions.

Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Source: Red Hat security advisory for CVE-2026-79657 (CC BY 4.0)

Frequently Asked Questions

### Summary The current source tree still allows arbitrary code execution during supposedly safer allowlisted pickle loading. The allowlist trusts whole module namespaces instead of exact safe globals, so crafted pickles can invoke dangerous in-namespace callables through pickle REDUCE. ### Details - **Vulnerability type:** Remote code execution via unsafe deserialization - **Affected component:** `nltk.picklesec.allowlisted_pickle_load`, `nltk.tokenize.punkt.punkt_pickle_load`, `nltk.parse.transitionparser.TransitionParser.parse` - **Affected versions:** Current source `v3.10.0-rc2`; publi
O3 Security · Impact-Aware SCA

Is CVE-2026-79657 in your dependencies?

Find it across PyPI, including transitive dependencies.

CVE-2026-79657: nltk RCE — Fixed in 3.10.3