Описание
NLTK before 3.10.3 contains a server-side request forgery vulnerability in nltk.pathsec.urlopen (and callers nltk.data.load, nltk.downloader.Downloader.index/download) when an HTTP proxy is configured. pathsec.urlopen validates the requested hostname locally, but proxy-handler inheritance disables the safe HTTP/HTTPS handlers so the actual fetch is performed by the proxy against a destination that is never re-validated. An attacker can supply a validated public URL that the proxy forwards to an internal loopback-only service, allowing disclosure of internal HTTP resources, loading of forged downloader indexes, and installation of attacker-chosen package content.
A flaw was found in NLTK. When an HTTP proxy is configured, a server-side request forgery (SSRF) vulnerability exists in the nltk.pathsec.urlopen function. An attacker can exploit this by providing a seemingly valid public URL, which the proxy then forwards to an internal service without proper re-validation. This could lead to the disclosure of internal network resources, the loading of malicious downloader indexes, and the installation of attacker-controlled package content.
Отчет
This is a server-side request forgery (SSRF) vulnerability in NLTK when an HTTP proxy is configured. The flaw allows an attacker to bypass local hostname validation, enabling the proxy to forward requests to internal loopback services. This can lead to the disclosure of internal HTTP resources or the installation of attacker-controlled package content in Red Hat products utilizing NLTK with an HTTP proxy.
Меры по смягчению последствий
To mitigate this issue, avoid configuring an HTTP proxy for NLTK if it is not strictly necessary. If an HTTP proxy must be used, implement strict network egress filtering to prevent NLTK from initiating connections to internal or loopback network addresses. This measure restricts the potential for an attacker to exploit the SSRF to access internal resources.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Exploit Intelligence | exploit-intelligence-tech-preview/vulnerability-analysis-rhel9 | Affected | ||
| Lightspeed Core | lightspeed-core/lightspeed-stack-rhel9 | Affected | ||
| Lightspeed Core | lightspeed-core/rag-tool-cpu-rhel9 | Affected | ||
| Lightspeed Core | lightspeed-core/rag-tool-cuda-12.9-rhel9 | Affected | ||
| OpenShift Lightspeed | openshift-lightspeed/lightspeed-ocp-rag-rhel9 | Affected | ||
| OpenShift Lightspeed | openshift-lightspeed/lightspeed-service-api-rhel9 | Affected | ||
| OpenShift Lightspeed | openshift-lightspeed-tech-preview/lightspeed-rag-tool-rhel9 | Affected | ||
| Red Hat Ansible Automation Platform 2 | ansible-automation-platform-25/lightspeed-chatbot-rhel8 | Will not fix | ||
| Red Hat OpenShift AI (RHOAI) | rhoai/odh-llama-stack-core-rhel9 | Affected | ||
| Red Hat OpenShift AI (RHOAI) | rhoai/odh-ogx-core-rhel9 | Affected |
Показывать по
Дополнительная информация
Статус:
EPSS
7.5 High
CVSS3
Связанные уязвимости
NLTK before 3.10.3 contains a server-side request forgery vulnerability in nltk.pathsec.urlopen (and callers nltk.data.load, nltk.downloader.Downloader.index/download) when an HTTP proxy is configured. pathsec.urlopen validates the requested hostname locally, but proxy-handler inheritance disables the safe HTTP/HTTPS handlers so the actual fetch is performed by the proxy against a destination that is never re-validated. An attacker can supply a validated public URL that the proxy forwards to an internal loopback-only service, allowing disclosure of internal HTTP resources, loading of forged downloader indexes, and installation of attacker-chosen package content.
NLTK before 3.10.3 contains a server-side request forgery vulnerability in nltk.pathsec.urlopen (and callers nltk.data.load, nltk.downloader.Downloader.index/download) when an HTTP proxy is configured. pathsec.urlopen validates the requested hostname locally, but proxy-handler inheritance disables the safe HTTP/HTTPS handlers so the actual fetch is performed by the proxy against a destination that is never re-validated. An attacker can supply a validated public URL that the proxy forwards to an internal loopback-only service, allowing disclosure of internal HTTP resources, loading of forged downloader indexes, and installation of attacker-chosen package content.
NLTK before 3.10.3 contains a server-side request forgery vulnerabilit ...
NLTK: pathsec SSRF protection can be bypassed when a proxy is configured
Уязвимость функций pathsec.urlopen(), nltk.data.load(), Downloader.index() и Downloader.download() пакета библиотек для символьной и статистической обработки естественного языка NLTK, позволяющая нарушителю осуществить SSRF-атаку
EPSS
7.5 High
CVSS3