Eclipse Csi Pia
Monthly
Server-side request forgery in the Eclipse CSI PIA `POST /v1/upload/sbom` endpoint lets remote attackers coerce the server into connecting to an arbitrary host, port, and scheme of their choosing. By exploiting a parser-differential between Python's `urlparse` (used for the issuer allowlist check) and `requests`/`urllib3`/`urllib` (used for OIDC discovery and JWKS retrieval), an attacker crafts a JWT `iss` claim containing a backslash that passes validation but resolves to a different host during the actual fetch. The `iss` claim is only checked in its unverified form, so no legitimate token is needed; no public exploit has been identified at time of analysis and the issue is not listed in CISA KEV.
Server-side request forgery and OIDC token forgery in Eclipse CSI PIA lets an unauthenticated attacker abuse a flawed Jenkins issuer allowlist (a bare `startswith('https://ci.eclipse.org')` check in `is_issuer_known`, pia/models.py:139) to redirect OIDC discovery and JWKS fetches to an attacker-controlled host. By posting a crafted issuer such as `https://ci.eclipse.org@evil.host` or `https://ci.eclipse.org.evil.host` to `POST /v1/upload/sbom`, an attacker forces PIA to make outbound requests to arbitrary hosts and to accept a JWT signed with the attacker's own key, effectively bypassing token verification. No public exploit identified at time of analysis, but the flaw is unauthenticated and network-reachable, and the CVSS 3.1 base score is 8.2.
Blind server-side request forgery in Eclipse PIA allows an approved OIDC identity provider to force PIA's token-verification flow to fetch an arbitrary host and port, including plaintext HTTP, from PIA's network position. The issue is in verify_token (pia/oidc.py), which follows jwks_uri from a trusted issuer's discovery document without parsing it as a URL, comparing it to the issuer origin, or requiring HTTPS, and the fetch is triggered by an unauthenticated POST /v1/upload/sbom that is then rejected with 401. Because the response is not reflected to the attacker, impact is limited to outbound GET reconnaissance/interaction; exploitation requires a high-privileged position controlling a registered per-project Jenkins issuer under https://ci.eclipse.org/<project>/oidc (PR:H), and no public exploit was identified at time of analysis.
Eclipse CSI PIA executes its pre-authentication OIDC discovery and JWKS fetch operations synchronously directly on the asyncio event loop, so a single unauthenticated request can stall the entire service for every connected user. Any network-reachable deployment that has the OIDC authentication flow enabled is affected, and exploitation needs no credentials, privileges, or user interaction (CVSS 4.0 base 6.9, AV:N/AC:L/PR:N/UI:N, availability-only with VA:L). Impact is confined to denial of service with no confidentiality or integrity effect, and no public exploit code was identified at time of analysis.
Log injection in Eclipse CSI PIA's unauthenticated /v1/upload/sbom endpoint allows a remote attacker to plant forged authentication-success log entries that are byte-for-byte indistinguishable from genuine PIA audit events. PIA is an authentication broker whose logs are explicitly designated as the authoritative source for incident response (DESIGN.md §5.4), meaning the forgery directly subverts the audit trail the service exists to produce. No public exploit has been identified at time of analysis, but the attack requires no authentication and minimal technical sophistication.
Server-side request forgery in the Eclipse CSI PIA `POST /v1/upload/sbom` endpoint lets remote attackers coerce the server into connecting to an arbitrary host, port, and scheme of their choosing. By exploiting a parser-differential between Python's `urlparse` (used for the issuer allowlist check) and `requests`/`urllib3`/`urllib` (used for OIDC discovery and JWKS retrieval), an attacker crafts a JWT `iss` claim containing a backslash that passes validation but resolves to a different host during the actual fetch. The `iss` claim is only checked in its unverified form, so no legitimate token is needed; no public exploit has been identified at time of analysis and the issue is not listed in CISA KEV.
Server-side request forgery and OIDC token forgery in Eclipse CSI PIA lets an unauthenticated attacker abuse a flawed Jenkins issuer allowlist (a bare `startswith('https://ci.eclipse.org')` check in `is_issuer_known`, pia/models.py:139) to redirect OIDC discovery and JWKS fetches to an attacker-controlled host. By posting a crafted issuer such as `https://ci.eclipse.org@evil.host` or `https://ci.eclipse.org.evil.host` to `POST /v1/upload/sbom`, an attacker forces PIA to make outbound requests to arbitrary hosts and to accept a JWT signed with the attacker's own key, effectively bypassing token verification. No public exploit identified at time of analysis, but the flaw is unauthenticated and network-reachable, and the CVSS 3.1 base score is 8.2.
Blind server-side request forgery in Eclipse PIA allows an approved OIDC identity provider to force PIA's token-verification flow to fetch an arbitrary host and port, including plaintext HTTP, from PIA's network position. The issue is in verify_token (pia/oidc.py), which follows jwks_uri from a trusted issuer's discovery document without parsing it as a URL, comparing it to the issuer origin, or requiring HTTPS, and the fetch is triggered by an unauthenticated POST /v1/upload/sbom that is then rejected with 401. Because the response is not reflected to the attacker, impact is limited to outbound GET reconnaissance/interaction; exploitation requires a high-privileged position controlling a registered per-project Jenkins issuer under https://ci.eclipse.org/<project>/oidc (PR:H), and no public exploit was identified at time of analysis.
Eclipse CSI PIA executes its pre-authentication OIDC discovery and JWKS fetch operations synchronously directly on the asyncio event loop, so a single unauthenticated request can stall the entire service for every connected user. Any network-reachable deployment that has the OIDC authentication flow enabled is affected, and exploitation needs no credentials, privileges, or user interaction (CVSS 4.0 base 6.9, AV:N/AC:L/PR:N/UI:N, availability-only with VA:L). Impact is confined to denial of service with no confidentiality or integrity effect, and no public exploit code was identified at time of analysis.
Log injection in Eclipse CSI PIA's unauthenticated /v1/upload/sbom endpoint allows a remote attacker to plant forged authentication-success log entries that are byte-for-byte indistinguishable from genuine PIA audit events. PIA is an authentication broker whose logs are explicitly designated as the authoritative source for incident response (DESIGN.md §5.4), meaning the forgery directly subverts the audit trail the service exists to produce. No public exploit has been identified at time of analysis, but the attack requires no authentication and minimal technical sophistication.