Server-Side Request Forgery (SSRF) Affecting label-studio package, versions <1.23.1-r0
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-MINIMOSLATEST-LABELSTUDIO-20416421
- published4 Oct 2026
- disclosed9 Aug 2026
Introduced: 9 Aug 2026
CVE-2026-12372 (opens in a new tab)How to fix?
Upgrade Minimos:latest label-studio to version 1.23.1-r0 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream label-studio package and not the label-studio package as distributed by Minimos.
See How to fix? for Minimos:latest relevant fixed versions and status.
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.