What is the CVSS score of CVE-2026-14336?

CVE-2026-14336 has a CVSS 3.1 base score of 8.2 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N. EPSS exploitation probability: 0.3%.

Which versions of Eclipse CSI PIA are affected by CVE-2026-14336?

Eclipse CSI PIA allows unauthenticated attackers to forge OIDC authentication tokens through a flawed issuer allowlist validation, enabling unauthorized impersonation and complete bypass of token…

How to fix or mitigate CVE-2026-14336?

Within 24 hours: Determine whether Eclipse CSI PIA is deployed in your environment and whether the POST /v1/upload/sbom endpoint is internet-accessible or reachable from untrusted networks. Within 7 days: Implement network segmentation to restrict PIA egress to approved identity provider hosts only via firewall rules, and deploy alerting for OIDC discovery requests to non-approved destinations. Within 30 days: Contact the Eclipse Foundation for patch availability and testing timeline; deploy the released patch immediately, or if unavailable, implement permanent API-level access controls restricting the vulnerable endpoint to internal trusted services only.

Eclipse CSI PIA CVE-2026-14336

EUVD-2026-41259 HIGH

Server-Side Request Forgery (SSRF) (CWE-918)

2026-07-02 eclipse

SSRF Jenkins Eclipse Csi Pia

8.2

CVSS 3.1 · Vendor: eclipse

Severity by source

Vendor (eclipse) PRIMARY

8.2 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

vuln.today AI

8.2 HIGH

Unauthenticated network endpoint (PR:N/AV:N) exploited via a trivial string trick (AC:L); accepting attacker-signed JWTs breaks authentication (I:H) and SSRF exposes internal responses (C:L), with no availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (eclipse).

CVSS VectorVendor: eclipse

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Jul 02, 2026 - 10:15 vuln.today

CVE Published

Jul 02, 2026 - 08:29 cve.org

HIGH 8.2

DescriptionCVE.org

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.

AnalysisAI

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.

Technical ContextAI

The vulnerability sits in PIA's OpenID Connect (OIDC) trust logic for Jenkins-issued tokens. OIDC relies on the token issuer (iss claim) to locate the identity provider's discovery document and JWKS (public key set) used to verify a JWT's signature. PIA validates the issuer with a naive string-prefix comparison rather than parsing the value as a URL and enforcing a host-bounded match, which is the classic CWE-918 (Server-Side Request Forgery) root cause: user-controlled input is used to build an outbound request target without proper host validation. URL prefix checks are trivially defeated because https://ci.eclipse.org@evil.host treats ci.eclipse.org as HTTP userinfo (the real host is evil.host), and https://ci.eclipse.org.evil.host is a subdomain of the attacker's domain - both pass a startswith test yet resolve to attacker infrastructure. The affected component is identified in CPE data as cpe:2.3:a:eclipse_foundation:eclipse_csi_-_pia, the Eclipse Foundation's PIA service.

RemediationAI

No vendor-released patch identified at time of analysis; the provided references point only to the Eclipse GitLab CVE-assignment work item (https://gitlab.eclipse.org/security/cve-assignment/-/work_items/154) and do not name a fixed version, so operators should consult the Eclipse Foundation security team for a patched release before deploying. As a code-level fix, replace the bare startswith('https://ci.eclipse.org') prefix check in is_issuer_known (pia/models.py:139) with a parsed-URL comparison that validates the scheme and performs an exact hostname match against an allowlist (e.g. parse the issuer and require parsed.hostname == 'ci.eclipse.org'), which closes both the userinfo (@evil.host) and suffix (.evil.host) bypasses. As compensating controls until a fix is applied: restrict network egress from the PIA service so it can only reach known OIDC endpoints such as ci.eclipse.org (this blocks the SSRF outbound fetches but will break OIDC if the allowlisted egress is incomplete), and place authentication or network access controls in front of the POST /v1/upload/sbom endpoint (this reduces unauthenticated exposure but may interfere with legitimate SBOM upload automation).