CVE-2026-107597 in PIA Plugin
Summary
by MITRE • 10/20/2026
PIA's token verification (`verify_token` in `pia/oidc.py`) fetches the OIDC discovery document of an allowlisted issuer and then follows the `jwks_uri` contained in that response without parsing it as a URL, comparing it against the approved issuer's origin, or requiring HTTPS — the only check is that the field is non-empty (`pia/oidc.py:42-52`). An approved identity provider — and every registered per-project Jenkins instance under `https://ci.eclipse.org/<project>/oidc` is a separate such party (`pia/models.py`) — can therefore direct PIA to issue a GET request to an arbitrary host and port, including over plaintext `http`, from PIA's own network position. The fetch happens before any signature is verified, as a side effect of an unauthenticated `POST /v1/upload/sbom` request that is ultimately rejected with 401.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability in the Platform Integration Assistant (PIA) represents a critical server-side request forgery flaw rooted in improper validation of OpenID Connect discovery metadata. Specifically, within the `verify_token` function located in `pia/oidc.py`, the system retrieves the OIDC discovery document from an allowlisted issuer and subsequently extracts the JSON Web Key Set URI (`jwks_uri`) to fetch public keys for signature verification. The implementation fails to perform any structural validation on this URI field, relying solely on a check that ensures the string is non-empty. This lack of rigorous parsing allows an attacker who controls or influences an approved identity provider to inject arbitrary URLs into the discovery response. Consequently, when PIA processes these tokens, it initiates HTTP GET requests to hosts and ports specified by the attacker, bypassing standard security expectations such as origin verification and protocol enforcement.
This flaw effectively transforms PIA into a server-side request forgery proxy capable of interacting with internal network resources that are not directly accessible from external networks. Because the fetch operation occurs before any cryptographic signature validation takes place, an unauthenticated user can trigger this behavior by sending a POST request to the `/v1/upload/sbom` endpoint. Although the final upload action is rejected with a 401 Unauthorized status due to missing authentication credentials for the actual resource access, the side effect of fetching the arbitrary URL has already occurred during the token verification phase. This means that even failed or unauthorized requests can be leveraged to probe internal services, exfiltrate data from internal endpoints via response content if reflected back through error messages, or potentially interact with vulnerable internal APIs that do not require authentication themselves.
The operational impact is severe due to PIA's network position and its role as a trusted intermediary for Jenkins instances under `https://ci.eclipse.org`. Every registered per-project instance acts as an approved party within the system's trust model. If any of these identity providers are compromised or if their OIDC configuration can be manipulated, attackers gain the ability to direct traffic from PIA’s infrastructure into internal networks. This capability facilitates reconnaissance against backend services, potential data exfiltration through DNS tunneling or HTTP response parsing, and could serve as a pivot point for further lateral movement within the organization's network perimeter. The use of plaintext `http` is particularly dangerous in this context, as it allows interception of sensitive keys if any intermediate proxies are compromised, although the primary risk lies in the ability to reach internal hosts that would otherwise be firewalled off from direct internet access.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically involving improper validation of server-side input leading to unauthorized network interactions. It also maps to MITRE ATT&CK technique T1572 Protocol Tunneling or T1046 Network Service Discovery, as the attacker uses a trusted application to scan and interact with internal services. The root cause is CWE-20 Improper Input Validation, where the system fails to validate that the `jwks_uri` conforms to expected formats such as HTTPS URLs belonging to the same origin or approved domains.
To mitigate this vulnerability, immediate remediation should focus on strict validation of the `jwks_uri`. The implementation must parse the URI and enforce that it uses the HTTPS protocol to prevent plaintext interception and ensure encrypted communication. Additionally, the system should validate that the host portion of the URL matches an allowlist of approved domains or IP ranges associated with trusted identity providers, preventing redirection to arbitrary internal hosts. Implementing a network-level egress filter on PIA servers can provide defense in depth by blocking outbound connections to private IP address ranges and non-standard ports. Furthermore, moving signature verification logic earlier in the request processing pipeline would prevent side effects from occurring before authentication is confirmed, although input validation remains the primary control needed to close this specific SSRF vector.