Eclipse CSI PIA CVE-2026-108062

Exploitation requires that the Eclipse CSI PIA instance be network-reachable with its OIDC authentication flow enabled, since the vulnerable code path is the pre-authentication OIDC discovery and JWKS fetch logic. No credentials, user interaction, or special privileges are needed (PR:N/UI:N), and default OIDC-enabled deployments are affected. Limiting factors: the target must actually expose the OIDC endpoint to the attacker (deployments not using OIDC or firewalled from untrusted networks are not exposed), and the impact is confined to availability - a service stall - with no data exposure or code execution.

This is a moderate-severity availability-only denial-of-service issue (CVSS 4.0 base 6.9, vector AV:N/AC:L/AT:N/PR:N/UI:N with only VA:L and no confidentiality or integrity impact). The vector signals favor exploitability: network reachable, low complexity, no privileges (PR:N), and no user interaction, meaning a remote unauthenticated attacker can trigger it against the pre-authentication OIDC code path. However, the technical impact is limited - it is a transient service stall/resource-exhaustion condition (CWE-400), not code execution or data compromise, which is why impact is scored VA:L rather than VA:H. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no evidence of active exploitation or weaponization; the elevated 6.9 reflects easy triggering rather than severe consequence. Net assessment: a credible real but contained risk for operators running Eclipse CSI PIA as a reachable service, prioritized below RCE/auth-bypass classes. Note the 4.0 vector reports VA:L (low, not high) despite the description implying the 'whole service' stalls - verify with the vendor advisory whether a single request causes a full, sustained outage, which would argue for a higher availability impact.

A remote unauthenticated attacker sends crafted or repeated OIDC discovery / JWKS requests to the exposed Eclipse CSI PIA endpoint; because these fetches execute synchronously on the asyncio event loop, each in-flight request blocks the loop and stalls all concurrent processing, denying service to legitimate users. No public exploit code is identified at time of analysis, but the pre-auth, low-complexity, no-interaction nature makes manual triggering trivial.