HarnessRouter EUVD-2026-107502

Requires an authenticated caller possessing a valid API key (PR:L) who can reach the '/v1/cloud-upload/targets/test' (and '/v1/cloud-upload/targets') route and control the 'base_url' argument; the server then fetches that address and returns the response, enabling SSRF to private, loopback or cloud-metadata ranges (e.g., 169.254.169.254). The key LIMITING factor is deployment mode: the fix shows self-hosted instances where '_pool_is_local()' is true intentionally allow any http(s) internal address (operator's own network), so meaningful exploitation targets SHARED/cloud deployments, where pre-patch code applied no scheme or private-range filtering. No user interaction is needed, but valid credentials and a shared-deployment posture are prerequisites.

This is a genuine but moderate-priority issue, best characterized as a credible-but-not-urgent SSRF. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and score of 5.3 indicate remote, low-complexity exploitation that nonetheless requires authentication (PR:L) - the source diff confirms this, since the vulnerable '/v1/cloud-upload/targets/test' route fetches the attacker-supplied address only 'for any caller with a key.' Impact is rated Low across confidentiality, integrity and availability (VC:L/VI:L/VA:L), consistent with an SSRF that returns the fetched response to the caller rather than granting code execution. No exploitation-probability signals elevate this: there is no EPSS score in the input, the CVE is not listed in CISA KEV, and no public exploit is identified - the E:X (Exploit Maturity: Not Defined) in the vector reinforces that exploitation status is undetermined. No SSVC decision data was provided. The sole reporting/intelligence source is VulDB; there is no independent corroboration of severity. One nuance worth flagging for defenders: the fix shows exploitability is deployment-dependent - on self-hosted ('_pool_is_local') instances internal fetches are intentionally permitted, so the real risk concentrates on shared/cloud-hosted deployments where private, loopback and cloud-metadata ranges (e.g., 169.254.169.254) were previously reachable. In short, a real and patchable flaw, but one gated by authentication and deployment mode rather than a high-urgency widespread threat.

An attacker holding a valid API key submits a crafted base_url (for example, pointing at the cloud metadata service at 169.254.169.254 or an internal-only host) to the Targets Test Endpoint, which fetches that address server-side and returns the response to the caller, leaking internal data. Because the server trusts the supplied address without validation on shared deployments, the attacker can probe and read internal services reachable from the gateway. No public exploit code is identified at time of analysis, though the fixing PR and advisory describe the mechanism in detail.