Eclipse PIA CVE-2026-107597

Exploitation requires the attacker to control the OIDC discovery document of an already-approved/allowlisted issuer - specifically a registered per-project Jenkins instance under https://ci.eclipse.org/<project>/oidc - so they can set jwks_uri to an arbitrary host:port (including plaintext http), since the code (pia/oidc.py:42-52) only checks that the field is non-empty and never parses it as a URL, compares it to the issuer origin, or requires HTTPS. The triggering request (POST /v1/upload/sbom) is itself unauthenticated and needs no user interaction, but the primitive is a blind GET from PIA's network position whose response is not reflected to the attacker. Key limiting factors: the attacker must be or compromise a trusted identity provider (PR:H), impact is confined to outbound GET requests usable mainly for internal reconnaissance/interaction, and no direct code execution, data read-back, or availability impact results.

This is a genuine but modest-severity blind SSRF (CWE-918), and the multiple signals largely agree on 'not a top priority.' The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N) scores 5.1 (medium), and the impact metrics are the key story: only SI:L (subsequent-system integrity Low) with VC:N/VI:N/VA:N/SC:N/SA:N, meaning no data is read back and no system is directly compromised - the attacker merely coerces PIA into issuing attacker-chosen GET requests from its network position. There is an important apparent contradiction worth flagging: the description stresses that the fetch happens via an 'unauthenticated POST /v1/upload/sbom,' which sounds like PR:N, yet the vendor assigns PR:H. These reconcile because triggering the SSRF to an ATTACKER-CONTROLLED target requires the attacker to control the OIDC discovery document of an already-allowlisted issuer (a registered per-project Jenkins instance), which is a privileged, trusted position - so PR:H is defensible and I concur with it. No EPSS score, no CISA KEV listing, and no public exploit were provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Net: a real defense-in-depth bug in a trust-boundary-sensitive path, but low real-world urgency given the privileged precondition, blind/low impact, and tiny deployment footprint.

An attacker who controls or compromises one of the per-project Jenkins instances that PIA already trusts as an OIDC issuer (e.g. https://ci.eclipse.org/<project>/oidc) publishes a discovery document whose jwks_uri points at an internal host and port - including plaintext http. They then send an unauthenticated POST /v1/upload/sbom to PIA, which follows that jwks_uri and issues the request from inside the Eclipse network before ultimately rejecting the upload with 401, giving a blind SSRF usable for internal port/service probing. No public exploit identified at time of analysis.