Eclipse CSI PIA CVE-2026-12616

The /v1/upload/sbom endpoint must be network-accessible, which is consistent with its function as an unauthenticated SBOM ingestion API (CVSS PR:N). The sole required condition is that PIA's JWT processing on this endpoint skips signature verification before extracting the iss claim - this is described as the current design behavior, not a misconfiguration. No special server-side configuration, non-default feature flag, or privileged network position is required. Exploitation is limited by the following factors: the attacker must know or guess the exact log message format PIA uses for 'Successfully authenticated project' entries to produce a convincing forgery; the impact is confined to log integrity and does not grant authentication, code execution, or data access; and the attack is only meaningful against environments where PIA logs are actively used for incident response decisions, as documented in DESIGN.md §5.4.

The CVSS 4.0 base score of 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N) accurately reflects a trivially exploitable, unauthenticated network attack with no special prerequisites. The integrity impact is scored VI:L, which numerically understates the operational consequence: because PIA's design documentation explicitly designates its token-verification and error logs as the authoritative audit trail for incident response, the ability to forge plausible authentication-success entries is a qualitative integrity failure that exceeds what a low-integrity rating conveys in isolation. There is no CISA KEV listing and no public POC, so active exploitation is not confirmed. EPSS data is absent from the provided intelligence. The realistic threat model is a sophisticated attacker seeking to suppress detection of credential abuse by pre-seeding the log with legitimate-looking entries - not mass exploitation. The niche deployment footprint of Eclipse CSI PIA limits broad exposure, but any environment using PIA as a trust anchor for token verification faces meaningful audit-trail risk.

An unauthenticated attacker sends a POST request to /v1/upload/sbom with a crafted JWT whose iss claim contains a newline character followed by a forged log line matching PIA's 'Successfully authenticated project' template, using a legitimate-looking project identifier. Because signature verification is skipped before logging, PIA writes the injected line verbatim, creating a fake audit record in the incident-response log. A security analyst investigating a credential-abuse incident then reviews the log and observes what appears to be a successful authentication for the targeted project, potentially discarding a true-positive alert.