https://vulnerability.circl.lu/rss/recent/all/10 Most recent entries from all 2026-09-30T01:06:56.444894+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://vulnerability.circl.lu/vuln/cve-2026-33230 CVE-2026-33230 — nltk Vulnerable to Cross-site Scripting 2026-09-30T01:06:57.715981+00:00

Affected: nltk

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.

 https://vulnerability.circl.lu/vuln/ghsa-gfwx-w7gr-fvh7 GHSA-gfwx-w7gr-fvh7 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in nltk 2026-09-30T01:06:57.716253+00:00

Affected: PyPI: nltk

### Summary `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.

### Details The vulnerable flow is in `nltk/app/wordnet_app.py`:

- [`nltk/app/wordnet_app.py:144`](/mnt/Data/my_brains/test/nltk/nltk/app/wordnet_app.py#L144) - Requests starting with `lookup_` are handled as HTML responses: - `page, word = page_from_href(sp)`

- [`nltk/app/wordnet_app.py:755`](/mnt/Data/my_brains/test/nltk/nltk/app/wordnet_app.py#L755) - `page_from_href()` calls `page_from_reference(Reference.decode(href))`

- [`nltk/app/wordnet_app.py:769`](/mnt/Data/my_brains/test/nltk/nltk/app/wordnet_app.py#L769) - `word = href.word`

- [`nltk/app/wordnet_app.py:796`](/mnt/Data/my_brains/test/nltk/nltk/app/wordnet_app.py#L796) - If no results are found, `word` is inserted directly into the HTML body: - `body = "The word or words '%s' were not found in the dictionary." % word`

This is inconsistent with the `search` route, which does escape user input:

- [`nltk/app/wordnet_app.py:136`](/mnt/Data/my_brains/test/nltk/nltk/app/wordnet_app.py#L136) - `word = html.escape(...)`

As a result, a malicious `lookup_...` payload can inject script into t…

 https://vulnerability.circl.lu/vuln/pysec-2026-2235 PYSEC-2026-2235 2026-09-30T01:06:57.716422+00:00

Affected: PyPI: nltk

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.