NLTK CVE-2026-62385

Exploitation requires three concurrent conditions: (1) the target application must pass attacker-controlled input - from a network-reachable source such as an HTTP parameter, API call, or message queue entry - directly or with insufficient sanitization to one of the specific methods frame_by_name, doc, lu, or header on a FramenetCorpusReader or NKJPCorpusReader instance; (2) NLTK version before 3.10.0 must be installed; and (3) the FrameNet or NKJP corpus data must be present and the corresponding reader must be initialized, as these are optional downloads not bundled with NLTK by default. The AT:P condition in the CVSS 4.0 vector confirms that a specific attack target configuration must exist. Exploitation is further limited to reading files that are (a) accessible by the process's OS account, and (b) parseable as XML - binary files, files with non-XML content, or files outside the process's read permissions cannot be exfiltrated via this vector. Authentication requirements are not independently confirmable from the CVE description; the CVSS PR:N indicates no NLTK-level credentials are required, but application-layer authentication wrapping the corpus reader API, if present, would serve as a mitigating control.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N) communicates a nuanced risk profile. The AV:N and PR:N metrics indicate the attack path is network-accessible and requires no credentials, which would ordinarily elevate priority. However, AC:H and - critically - AT:P (attack target conditions present) significantly constrain exploitability: AT:P in CVSS 4.0 means a specific precondition must exist in the deployment, here that the application must relay externally-controlled input into the corpus reader methods. NLTK is predominantly used in research, academic, and data-science pipelines; production deployments that expose FramenetCorpusReader or NKJPCorpusReader methods to network-facing user input are uncommon. No EPSS data was provided in the input, no POC has been identified, and no active exploitation is confirmed (no CISA KEV listing). The high-sounding score of 8.2 reflects worst-case confidentiality impact but the realistic exploitable surface is narrow. Organizations running NLTK in isolated research environments with no external-facing corpus-reader exposure face minimal real-world risk; those with web services wrapping NLTK corpus functionality should treat this as higher priority.

An attacker targeting a web application that accepts user-specified corpus queries and passes them to an NLTK FramenetCorpusReader instance submits a frame name parameter containing path traversal sequences such as '../../../etc/passwd' or a crafted index-poisoning payload to the frame_by_name endpoint. NLTK constructs a file path by concatenating the corpus root with the unsanitized selector, causing the XML parser to open and return contents of an arbitrary file readable by the application process. No public POC has been identified at time of analysis, and successful exploitation requires the application to expose these specific corpus reader methods to attacker-controlled input.