Natural Language Toolkit (NLTK): URL-Encoded Path Traversal in nltk.data.load() Allows Arbitrary Local File Read

## Vulnerability nltk.data.load() in NLTK versions up to and including 3.9.4 is vulnerable to a path traversal attack when using the nltk: URL scheme [1][2]. The _UNSAFE_NO_PROTOCOL_RE regex check is performed on the raw resource string before url2pathname() decodes percent-encoded sequences. This decode-after-check flaw allows an attacker to bypass the security regex by encoding path traversal components such as %2f (/) and %2e (.) so they are invisible to the regex but become dangerous after decoding [1][2]. The affected code is in nltk/data.py in functions find(), normalize_resource_url(), and the regex check itself [1][2].

Exploitation

An attacker can supply a crafted resource name containing URL-encoded traversal sequences (e.g., %2e%2e%2f..%2fetc%2fpasswd) to nltk.data.load() or nltk.data.find(). The regex check passes because the encoded dots and slashes do not match the literal patterns [1][2]. After the check, url2pathname() decodes the string, producing a path like ../../../etc/passwd that reads arbitrary files [1][2]. The attacker does not need authentication if the application exposes the load() function to user input; no special privileges are required [1][2].

Impact

Successful exploitation allows an attacker to read arbitrary files on the local filesystem, leading to disclosure of sensitive information such as configuration files, passwords, or application source code [1][2]. The vulnerability does not directly enable code execution, but leaked credentials may facilitate further attacks. The scope of compromise is limited to file read under the privileges of the NLTK process [1][2].

Mitigation

No official patch has been released as of the advisory publication date [1][2]. Users are advised to avoid using the nltk: URL scheme with untrusted input, or to implement additional input validation after decoding. The default configuration of NLTK does not enforce the security check (ENFORCE=False), so enabling strict validation may reduce risk [1][2]. Until a fix is available, applications should sanitize or reject any user-supplied resource names that contain percent-encoded characters [1][2].