Описание
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.
A flaw was found in NLTK. A Server-Side Request Forgery (SSRF) vulnerability allows an attacker to influence a URL passed to NLTK's network-loading helpers. This occurs because the nltk.pathsec.validate_network_url() function fails to properly identify and reject IP addresses within the RFC 6598 shared address space (100.64.0.0/10). This could lead to the exposure of non-public infrastructure reachable from the application host, resulting in confidentiality exposure.
Отчет
This is a Low impact Server-Side Request Forgery (SSRF) vulnerability in the NLTK library. Red Hat products that incorporate NLTK and process untrusted URLs via its network-loading functions may be vulnerable. An attacker could influence a URL to cause the application to send requests to RFC 6598 shared address space hosts, potentially exposing internal network information. This flaw is limited to confidentiality exposure and does not enable code execution.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Exploit Intelligence | exploit-intelligence-tech-preview/vulnerability-analysis-rhel9 | Out of support scope | ||
| Lightspeed Core | lightspeed-core/lightspeed-stack-rhel9 | Fix deferred | ||
| Lightspeed Core | lightspeed-core/rag-tool-cpu-rhel9 | Fix deferred | ||
| Lightspeed Core | lightspeed-core/rag-tool-cuda-12.9-rhel9 | Fix deferred | ||
| OpenShift Lightspeed | openshift-lightspeed/lightspeed-ocp-rag-rhel9 | Fix deferred | ||
| OpenShift Lightspeed | openshift-lightspeed/lightspeed-service-api-rhel9 | Fix deferred | ||
| OpenShift Lightspeed | openshift-lightspeed-tech-preview/lightspeed-rag-tool-rhel9 | Fix deferred | ||
| Red Hat Ansible Automation Platform 2 | ansible-automation-platform-25/lightspeed-chatbot-rhel8 | Out of support scope | ||
| Red Hat OpenShift AI (RHOAI) | rhoai/odh-llama-stack-core-rhel9 | Fix deferred | ||
| Red Hat OpenShift AI (RHOAI) | rhoai/odh-pipeline-runtime-pytorch-llmcompressor-cuda-py312-rhel9 | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
3.7 Low
CVSS3
Связанные уязвимости
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.
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.
A Server-Side Request Forgery (SSRF) vulnerability exists in nltk/nltk ...
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.
Уязвимость функции validate_network_url() компонента nltk.pathsec пакета библиотек для символьной и статистической обработки естественного языка NLTK, позволяющая нарушителю осуществить SSRF-атаку
EPSS
3.7 Low
CVSS3