CVE-2026-79676

CVE-2026-79676 is a high-severity path traversal vulnerability in nltk (pip), affecting versions <= 3.10.2. It is fixed in 3.10.3.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

NLTK: Corpus readers follow symlinks outside trusted roots despite pathsec enforcement

Several corpus readers still step outside NLTK's symlink-aware trusted-root model. They derive in-root paths from trusted corpus state, convert those paths back into plain strings, and reopen them with built-in open() rather than nltk.pathsec.open().

Details

  • Vulnerability type: Path traversal and symlink boundary bypass
  • Affected component: nltk.corpus.reader.ipipan, nltk.corpus.reader.crubadan, nltk.corpus.reader.lin
  • Affected versions: Published 3.9.4 and current source v3.10.0-rc2 both reproduced.
  • Patched versions: Not yet patched
  • Root cause: Root-derived paths are reopened with raw open() without preserving the trusted-root boundary.

IPIPANCorpusReader opens header.xml derived from morph.xml, CrubadanCorpusReader opens table.txt directly, and LinThesaurusCorpusReader opens simN.lsp paths returned from its own root helpers. Under pathsec.ENFORCE=True, a symlink placed inside the trusted corpus root can point outside the root and still be parsed successfully. It was confirmed parsed outside-root content is returned through public methods such as channels(), domains(), categories(), langs(), crubadan_to_iso(), synonyms(), and scored_synonyms().

PoC

Preconditions

  • The application processes attacker-influenced corpora inside a trusted NLTK data root or trusted corpus directory.

Steps

  1. Create a trusted corpus root and keep pathsec.ENFORCE=True with that root allowlisted.
  2. Place symlinked reader inputs such as header.xml, table.txt, or simN.lsp inside the root and point them to external files.
  3. Instantiate the corresponding corpus reader and call its normal public methods.
  4. Observe that parsed outside-root values are returned even though pathsec.open() blocks the same symlink targets.

Minimal reproducible excerpt

{'ipipan': ['LEAK', 'TOPSECRET', 'CLASSIFIED'], 'crubadan': ['LEAK'], 'lin': [('LEAK', 9.5)]}

References

Fix + full-codebase audit (verified)

I swept every raw file open in the corpus readers, not just the three the umbrella named:

Reader Site Advisory Root scoping
crubadan table.txt + <code>-3grams.txt p4rw / j5pw required_root=self.root
lin simN.lsp p4rw required_root=self.root
xmldocs XMLCorpusView bare-string fileid 934p (base reader) global fallback (view has no root)
pl196x textids index found by audit required_root=self._root
mte MTEFileReader mvf5 required_root threaded through 8 call sites
toolbox StandardFormat.open codecs.open cr8c global sandbox (low-level parser)
named_entity load_ace_file ann/text 7qj2 global sandbox
nkjp XML_Tool source file p4rw class required_root=self._root

ipipan already validates via the earlier #3727 fix, unchanged.

Fix

Each site now calls nltk.pathsec.validate_path(path, required_root=…) before opening. Where the reader has a concrete corpus root, the check is scoped with required_root (rejects any escape outside that root). XMLCorpusView carries no root, so it falls back to the global data-root sandbox via getattr(self, "_root", None), which also avoids an AttributeError on the bare-string path.

Reproduced (captured)

raw open(symlink) reads: 'TOPSECRET_OUTSIDE_ROOT'          <- the bypass
validate_path(symlink, required_root): ValueError -> BLOCKS the escape
validate_path(legit in-root): PASSED                       <- loads normally

Honest residual

The global-sandbox fallback (toolbox, named_entity, xmldocs-view) is only as tight as the allowed-roots list, which currently includes the system temp dir. Scoping every reader with required_root and removing the temp dir from the allowed roots would harden it further (separate advisory / task).

Tests

test_corpus_reader_pathsec.py, symlink escape rejected, in-root file allowed, XMLCorpusView string-fileid no AttributeError, MTEFileReader out-of-root rejected. 46 existing corpus/toolbox tests pass; all edited modules import (no circular import). pre-commit (black/isort/ruff) clean.

Scope caveat

validate_path blocks every symlink escape variant (verified) and equals pathsec.open()'s guarantee, but does NOT block hardlinks (no symlink to resolve; tracked separately as GHSA-f794-5jv7-7672) or the validate-then-open TOCTOU race (shared by pathsec.open; needs O_NOFOLLOW/openat).

Impact

An attacker who can stage corpus files or symlinks under a trusted data root can disclose outside-root content through normal corpus-reader results, defeating the boundary NLTK documents for shared and untrusted-input environments.

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

Affected versions

nltk (<= 3.10.2)

Security releases

nltk → 3.10.3 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Preserve PathPointer and required_root semantics end to end. Replace direct open() calls with nltk.pathsec.open() or a reader helper that keeps the trusted-root boundary intact.

Frequently Asked Questions

  1. What is CVE-2026-79676? CVE-2026-79676 is a high-severity path traversal vulnerability in nltk (pip), affecting versions <= 3.10.2. It is fixed in 3.10.3. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
  2. Which versions of nltk are affected by CVE-2026-79676? nltk (pip) versions <= 3.10.2 is affected.
  3. Is there a fix for CVE-2026-79676? Yes. CVE-2026-79676 is fixed in 3.10.3. Upgrade to this version or later.
  4. Is CVE-2026-79676 exploitable, and should I be worried? Whether CVE-2026-79676 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether CVE-2026-79676 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix CVE-2026-79676? Upgrade nltk to 3.10.3 or later.

Stop the waste.
Protect your environment with Kodem.