Уязвимость подделки запросов на стороне сервера (SSRF) существует в nltk/nltk версий 3.9.4 и текущей ветке разработки. Функция nltk.pathsec.validate_network_url(), предназначенная для предотвращения SSRF путем отклонения внутренних сетевых адресов, не может отклонять IP-адреса в общем адресном пространстве RFC 6598 (100.64.0.0/10). Это происходит потому, что модуль Python `ipaddress` не классифицирует такие адреса как `is_private` или `is_global`, а текущий охранник проверяет только `is_private` и несколько явных категорий.
Злоумышленник, который может повлиять на URL-адрес, передаваемый помощникам сетевой загрузки NLTK, может воспользоваться этой уязвимостью, чтобы заставить приложение строгого режима отправлять запросы на узлы общего адресного пространства, потенциально подвергая риску закрытую инфраструктуру, доступную с узла приложения. Влияние ограничивается раскрытием конфиденциальности в стиле SSRF, без заявлений о выполнении кода.
Показать оригинальное описание (EN)
A Server-Side Request Forgery (SSRF) vulnerability exists in nltk/nltk versions 3.9.4 and the current develop branch. The `nltk.pathsec.validate_network_url()` function, intended to prevent SSRF by rejecting internal network addresses, fails to reject IPs in the RFC 6598 shared address space (`100.64.0.0/10`). This occurs because Python's `ipaddress` module does not classify such addresses as `is_private` or `is_global`, and the current guard only checks `is_private` and a few explicit categories. An attacker who can influence a URL passed to NLTK's network-loading helpers can exploit this vulnerability to make a strict-mode application send requests to shared-address-space hosts, potentially exposing non-public infrastructure reachable from the application host. The impact is limited to SSRF-style confidentiality exposure, with no code execution claimed.
Характеристики атаки
Последствия
Строка CVSS v3.0