Label Studio EUVD-2026-115906

Requires an authenticated account of any role (PR:L) that can create a project and import a task - no admin action and no storage registration is needed, since data.image accepts an absolute attacker-supplied URL. The export MUST use an image-bearing format that forces resource download: YOLO_WITH_IMAGES, YOLO_OBB_WITH_IMAGES, or COCO_WITH_IMAGES; the advisory notes that plain YOLO even with download_resources=true downloads nothing because the format overrides the flag, so this is a concrete limiting factor. The core full-read SSRF needs no configuration toggles. The organization-owner token-disclosure variant additionally requires: spoofing the Host header so its netloc matches the task URL's netloc (possible because ALLOWED_HOSTS defaults to '*'), plus a header credential (a JWT obtained via POST /api/token/ then /api/token/refresh/) because spoofing Host invalidates session-cookie auth and returns 401. A further limiting factor on replay: the leaked token is only usable for authentication if legacy_api_tokens_enabled is turned on, which is off by default, so on a stock instance the disclosed token is inert unless/until an operator enables that setting.

This is a genuine but mid-tier priority, not a drop-everything emergency, and the signals are mostly consistent. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) describes a network-reachable, low-complexity flaw requiring an authenticated low-privileged account; impact is split as VC:L on Label Studio itself but SC:H on the internal systems reached through the SSRF, which is why this is a full-read (not blind) SSRF with a credible internal-exposure consequence. The vuln.today decision label is 'this_month' rather than act_now/emergency, and the input supplies no EPSS score and no CISA KEV listing, so there is no evidence of active exploitation or mass scanning. A detailed, vendor-tested reproduction exists in the GHSA advisory (full attack walkthrough against label-studio 1.23.0), which raises practical exploitability for any attacker who already holds an account. The one tension to flag explicitly: the SSRF itself reproduces on default settings and is a real confidentiality risk, but the headline credential-disclosure variant leaks the organization owner's long-lived API token to an attacker-chosen host on default settings YET that token is rejected at authentication while legacy_api_tokens_enabled stays at its default of False - so the leaked secret is currently inert and only becomes retroactively replayable if an operator later enables legacy tokens. Net: patch this month; treat the SSRF as the live risk and the token leak as a latent, configuration-gated one.

An authenticated low-privileged member creates their own project, imports a task whose data.image points at an internal target (for example a cloud metadata endpoint or an internal admin interface), then requests an image-bearing export (YOLO_WITH_IMAGES or COCO_WITH_IMAGES); the Label Studio server fetches that URL with no destination validation and returns the raw response body inside the ZIP the attacker downloads. By additionally spoofing the Host header (ALLOWED_HOSTS defaults to '*') and authenticating with a JWT instead of a session cookie, the same export causes the organization owner's API token to be sent to the attacker's collector. A detailed, vendor-tested public PoC reference exists in the GHSA advisory; it is a step-by-step reproduction, not verified as packaged standalone exploit code.