CVE-2026-12243: 
Python Analisi e mitigazione delle vulnerabilità

CVE-2026-12243 is a path traversal vulnerability in NLTK (Natural Language Toolkit) version 3.9.4 that allows unauthenticated remote attackers to read arbitrary files accessible to the Python process. The flaw stems from an incomplete fix for GitHub Issue #3504, where the _UNSAFE_NO_PROTOCOL_RE regex in nltk/data.py fails to account for percent-encoded traversal sequences (e.g., ..%2f). It was published on June 30, 2026, and carries a CVSS v3.0 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). The _UNSAFE_NO_PROTOCOL_RE regex in nltk/data.py validates resource names by checking for literal ../ sequences, but the url2pathname() function decodes percent-encoded sequences (e.g., ..%2f → ../) after this validation step, allowing the check to be trivially bypassed. An attacker who can control the resource name parameter passed to nltk.data.load() or nltk.data.find() — for example, via a web API or CLI input — can supply a crafted percent-encoded path to traverse outside the intended directory. The default pathsec.ENFORCE=False configuration further exacerbates the issue by not blocking the file read at the open() stage (GitHub Advisory, Huntr Bounty).

Successful exploitation allows an unauthenticated network attacker to read arbitrary files accessible to the Python process running NLTK, resulting in a high confidentiality impact with no integrity or availability impact. Sensitive files such as application configuration files, credentials, private keys, or system files (e.g., /etc/passwd) could be exfiltrated depending on the process's file system permissions. Affected application types include NLP web applications, Jupyter notebooks, and CLI tools that pass user-controlled input to NLTK resource loading functions (GitHub Advisory, Red Hat Bugzilla).

1. Identify a vulnerable target: Find an application that exposes NLTK resource loading functionality (e.g., an NLP web API, Jupyter notebook, or CLI tool) and accepts user-controlled input passed to nltk.data.load() or nltk.data.find(), running NLTK version 3.9.4.
2. Craft a percent-encoded path traversal payload: Instead of using a literal ../ sequence (which would be caught by the regex), construct a resource name using percent-encoded traversal, e.g., ..%2f..%2f..%2fetc%2fpasswd.
3. Submit the payload: Pass the crafted resource name to the vulnerable application endpoint or function call. The _UNSAFE_NO_PROTOCOL_RE regex validation passes because it only checks for literal ../.
4. Trigger decoding and file read: The url2pathname() function decodes %2f to / after validation, resolving the path to an arbitrary file outside the intended directory. With pathsec.ENFORCE=False (the default), no additional blocking occurs at the open() stage.
5. Retrieve file contents: The contents of the targeted file (e.g., /etc/passwd, application config files, or secrets) are returned to the attacker via the application's response (Huntr Bounty, GitHub Advisory).

• Network: Unusual or unexpected HTTP requests to NLP application endpoints containing percent-encoded sequences such as %2f, %2F, %2e, or %2E in resource name parameters; requests referencing system paths like etc, passwd, shadow, or application config directories.
• Logs: Application logs showing calls to nltk.data.load() or nltk.data.find() with resource names containing ..%2f, ..%2F, or other encoded traversal patterns; Python exception traces related to unexpected file paths in NLTK data loading.
• File System: Evidence of access to files outside the NLTK data directory (e.g., /etc/passwd, SSH keys, application .env files) in OS-level file access audit logs (e.g., auditd records).
• Process: Python process accessing files in unexpected directories not associated with NLTK data storage (GitHub Advisory, Red Hat Bugzilla).

Upgrade NLTK to a patched version that properly validates percent-encoded path traversal sequences (check the GitHub Advisory for the specific fixed version once published). As an immediate workaround, set pathsec.ENFORCE=True in your NLTK configuration to add an additional blocking layer at the open() stage. Additionally, restrict the resource names that can be passed to nltk.data.load() and nltk.data.find() to a strict allowlist of expected values, and avoid passing unsanitized user input directly to these functions (GitHub Advisory, Red Hat Bugzilla).

The vulnerability was reported through the Huntr bug bounty platform and assigned a high severity rating. Red Hat opened a tracking bug (BZ#2494748) with high priority, indicating concern for downstream distributions that package NLTK. Social media activity was observed on Bluesky and Mastodon/infosec.exchange shortly after disclosure, with automated CVE tracking accounts amplifying the advisory (Red Hat Bugzilla, GitHub Advisory).