CVE-2026-12616
MediumCVSS 6.9Summary
The vulnerability in the /v1/upload/sbom endpoint allows an unauthenticated attacker to inject fake log entries by manipulating the iss claim in a JWT token. Due to disabled JWT signature verification and literal newline rendering in the log format, the attacker can create entries indistinguishable from genuine successful authentication messages.
Risk Assessment
The organization loses the integrity of the audit log, which is critical for incident response. Fake authentication success entries can hide actual security breaches and prevent effective investigation.
Recommendation
Immediately enable JWT signature verification for the /v1/upload/sbom endpoint and implement input validation before using data in logs. Additionally, change the log format to one that does not render newline characters literally.
Other vulnerabilities in PIA
See all- CVE-2026-18353High
PIA's `POST /v1/upload/sbom` endpoint accepts a Bearer JWT and checks its unverified `iss` claim against an issuer allowlist using Python's `urlparse` before performing OIDC discovery with `requests`. Because `urlparse` and `requests`/`urllib3` parse an authority string containing a backslash into different hostnames, an attacker can craft an issuer that passes the allowlist check yet drives `requests` to connect to an arbitrary attacker-chosen host.
- CVE-2026-14336High
The vulnerability in PIA uses a bare string-prefix check for the OIDC issuer allowlist instead of validating the issuer as a properly host-bounded URL. An attacker can craft an issuer that passes the prefix check but points to a controlled server. This allows an unauthenticated caller of POST /v1/upload/sbom to force outbound HTTP(S) requests to an arbitrary host and accept a JWT signed with the attacker's key.
Original NVD description (English source)
The /v1/upload/sbom endpoint extracts the iss claim from the attacker-supplied JWT with signature verification disabled, then interpolates that string into three log statements before any validation gate. Because the configured log format ("%(asctime)s - %(name)s - %(levelname)s - %(message)s") renders newlines literally, an unauthenticated attacker can forge log records that are byte-for-byte indistinguishable from PIA's genuine "Successfully authenticated project" message. PIA is an authentication broker whose logs are explicitly relied upon for incident response (DESIGN.md §5.4 lists "Token verifications" and "Errors" as events to log), so the ability to plant fake auth-success entries directly undermines the audit trail the service exists to produce.