CVE-2026-33230

What it actually does

Reflected cross-site scripting in NLTK's local WordNet Browser (nltk.app.wordnet_app) in 3.9.3 and earlier. Attacker-controlled word values on lookup_* routes are written into the HTML response without output encoding, so injected markup or script can execute in the browser origin of that local application. Confidentiality and integrity impact is limited to that origin; availability is not affected.

Why it matters to the business

Researchers and developers who run the WordNet Browser can have content or session data in that local app origin altered or read if they open a malicious link. The service is typically a local/dev tool rather than a production internet-facing app, so organizational blast radius is usually limited to workstations and lab machines using NLTK. CVSS is 6.1 (user interaction required, scope changed). EPSS is low (~0.39%) with a modest 30-day rise (0.0033 → 0.0039). Not in CISA KEV, no ransomware use reported, and exploit maturity is none. Residual risk is mainly to NLP/research environments that leave the browser running and click untrusted links.

How an attack unfolds

The attacker crafts a WordNet lookup URL in which the word parameter contains unescaped HTML or JavaScript, then delivers that URL (phishing, chat, or a page the victim visits). If the victim has the WordNet Browser listening and opens the link, the server reflects the unsanitized value into the page and the browser executes it in the WordNet app origin. No authentication is required; the victim must interact. There are no named APT groups, campaigns, or ransomware families associated with this CVE.

How to fix it

Upgrade NLTK beyond 3.9.3 to a build that includes commit 1c3f799607eeb088cab2491dcf806ae83c29ad8f so lookup responses HTML-encode word data. Until patched, do not run nltk.app.wordnet_app on shared or networked hosts; bind only to loopback if it must run, and do not open untrusted WordNet lookup links while it is listening. Do not expose the WordNet Browser beyond localhost.

How to confirm the fix worked

Confirm the installed nltk package is newer than 3.9.3 and that wordnet_app lookup handlers escape HTML in word values. Verify the WordNet Browser is not listening on non-loopback interfaces. After upgrade, request a lookup with reserved HTML characters in the word parameter and confirm they appear encoded in the response rather than as live markup.

Typical attack path

1. Determine or induce that the target is running the NLTK WordNet Browser locally
2. Build a lookup URL whose word value includes unescaped markup destined for the lookup_* route
3. Deliver the URL to the victim via a channel they are likely to open
4. Victim opens the URL while the local WordNet server is running
5. Injected script runs in the WordNet Browser origin and can read or modify content in that context

How to detect it

This is reflected XSS against a local app, so evidence is mainly in the victim browser and any access logs of the WordNet process—not typical perimeter IDS. Review HTTP access logs and proxy/browser history for requests to lookup_* on the WordNet Browser (often localhost) where the word value contains HTML metacharacters or encoded tags. Look for nltk WordNet server processes listening on non-loopback interfaces. There is no public exploit kit or named-actor TTP set; correlate suspicious lookup URLs with the time the local server was running. Absence of logs does not prove non-exploitation because the server may log little by default.

• nltk.app.wordnet_app
• wordnet_app
• /lookup_
• lookup_%3C
• lookup_<

What your security team should do

• Inventory Python environments and pin or upgrade nltk past 3.9.3 (fix: commit 1c3f799607eeb088cab2491dcf806ae83c29ad8f)
• Prohibit or firewall the WordNet Browser on production, CI, and shared lab systems; allow loopback-only if required for research
• Warn NLP and data-science users not to open untrusted WordNet lookup links while the local server is running
• Hunt for wordnet_app or nltk WordNet listeners bound outside 127.0.0.1
• Treat as moderate priority: 6.1 CVSS, ~192 days public, low EPSS, not KEV, no known in-the-wild exploitation