Eclipse Csi Pia
Approved changes feed: RSS · Atom
cpe:2.3:a:eclipse_foundation:eclipse_csi_-_pia:*:*:*:*:*:*:*:*
part: a version: * update: *
| Vendor | Eclipse Foundation (2c315c48-0111-5572-bbde-cc70cfafb2e9) |
|---|---|
| Product | Eclipse Csi Pia (b11e1386-c5e8-532a-bfbf-407527619bc7) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
| Notes | Imported from gcve-enriched-dumps CVE data |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-14336 |
vulnerable | 2026-07-29 00:26:16.933800 |
Details available
HIGH (8.2)
PIA's OIDC issuer allowlist for Jenkins tokens uses a bare string-prefix check (issuer.startswith(' https://ci.eclipse.org ') in is_issuer_known, pia/models.py:139) instead of validating the issuer as a properly host-bounded URL. An attacker can craft an issuer such as https://ci.eclipse.org@evil.host (userinfo trick) or https://ci.eclipse.org.evil.host (suffix trick) that satisfies the prefix check while pointing the OIDC discovery and JWKS fetches at a server the attacker controls. An unauthenticated caller of POST /v1/upload/sbom can use this to force PIA to make outbound HTTP(S) requests to an arbitrary attacker-chosen host, and to have oidc.verify_token accept a JWT signed with the attacker's own key.
Published: 2026-07-02T08:29:16.010Z
Updated: 2026-07-02T12:26:16.287Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-12616 |
vulnerable | 2026-07-29 00:23:32.472871 |
Details available
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.
Published: 2026-06-29T13:23:38.967Z
Updated: 2026-06-29T13:51:57.117Z |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.