CVE-2026-33230 in NLTK
Summary
by MITRE • 03/21/2026
NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. In versions 3.9.3 and prior, `nltk.app.wordnet_app` contains a reflected cross-site scripting issue in the `lookup_...` route. A crafted `lookup_<payload>` URL can inject arbitrary HTML/JavaScript into the response page because attacker-controlled `word` data is reflected into HTML without escaping. This impacts users running the local WordNet Browser server and can lead to script execution in the browser origin of that application. Commit 1c3f799607eeb088cab2491dcf806ae83c29ad8f fixes the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/28/2026
The vulnerability identified as CVE-2026-33230 affects the Natural Language Toolkit (NLTK) library, specifically its wordnet_app module that provides a local WordNet Browser server for natural language processing research and development. This issue represents a classic reflected cross-site scripting vulnerability that impacts users running the local NLTK server in development environments. The vulnerability exists in NLTK versions 3.9.3 and prior, making it a significant concern for developers who rely on the toolkit's built-in web interface for exploring WordNet data. The security flaw manifests in the lookup_... route handler where user-provided input is directly incorporated into HTML responses without proper sanitization or escaping mechanisms.
The technical flaw stems from improper input validation and output encoding within the NLTK wordnet_app implementation. When a user accesses a URL containing a crafted lookup_<payload> parameter, the application reflects the attacker-controlled word data directly into the HTML response page without any HTML escaping or sanitization. This creates a condition where malicious JavaScript code can be injected and executed within the browser context of the NLTK WordNet Browser application. The vulnerability follows the CWE-79 pattern for cross-site scripting, specifically classified as reflected XSS where the malicious payload is reflected back to the user through the application's response. The issue occurs because the application treats user input as trusted content and incorporates it directly into dynamically generated HTML without proper security measures.
The operational impact of this vulnerability extends beyond simple script execution, as it can enable attackers to perform various malicious activities within the context of the NLTK application. An attacker could craft payloads that steal session cookies, redirect users to malicious sites, or perform actions on behalf of the user within the browser. Since the vulnerability affects the local WordNet Browser server, it primarily impacts developers and researchers who run the NLTK application on their local machines for testing and development purposes. The attack vector requires an attacker to convince a victim to visit a malicious URL containing the crafted payload, making it a user-interaction dependent vulnerability that could be exploited through social engineering or compromised development environments. The vulnerability is particularly concerning in research environments where developers may have elevated privileges or access to sensitive data through the NLTK applications.
The fix implemented in commit 1c3f799607eeb088cab2491dcf806ae83c29ad8f addresses the root cause by properly escaping user-provided input before incorporating it into HTML responses. This approach aligns with established security practices for preventing XSS vulnerabilities and follows the ATT&CK technique T1203 for legitimate credential exposure through web application vulnerabilities. Organizations should immediately upgrade to NLTK version 3.9.4 or later to mitigate this risk, particularly in development environments where the WordNet Browser server is actively used. System administrators and developers should also consider implementing additional security measures such as input validation at multiple layers and monitoring for suspicious URL patterns in development environments. The vulnerability demonstrates the importance of proper input sanitization even in seemingly benign applications and highlights the need for security testing in open source libraries used for research and development activities.