CVE-2026-14336: OIDC issuer allowlist bypass in Eclipse CSI PIA
TL;DR - Eclipse CSI PIA trusts certain OIDC issuers using a string prefix check, enabling issuer spoofing. - Unauthenticated attackers can target
POST /v1/upload/sbomto trigger SSRF and potentially bypass token trust. - No verified fixed version is publicly confirmed in the source material, so defenders should treat exposed instances as high priority.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-14336 |
| CVSS score | 8.2 (High) |
| Attack vector | Network, via unauthenticated POST /v1/upload/sbom |
| Auth required | None |
| Patch status | No publicly verified fixed version identified in available primary-source material |
Vulnerability at a glance
CVE-2026-14336 is a high-severity flaw in Eclipse CSI PIA that combines two security problems in one path: server-side request forgery and authentication trust bypass. According to the NVD description, the application uses a bare startswith(...) check to decide whether an OIDC issuer should be trusted for Jenkins tokens. That means the trust decision is made on a string prefix, not on a parsed, host-bounded URL.
In practical terms, that allows an attacker to submit issuer values that begin with the expected trusted string but actually resolve to attacker-controlled infrastructure. The examples described in the CVE are the classic userinfo trick, such as https://ci.eclipse.org@evil.host, and the subdomain/suffix trick, such as https://ci.eclipse.org.evil.host. Both can pass naive string validation while pointing discovery and JWKS retrieval at the wrong host.
This matters because the vulnerable flow is reachable through an unauthenticated request to POST /v1/upload/sbom. Based on the NVD description, a remote attacker does not need prior access or user interaction to trigger outbound HTTP(S) requests from PIA and influence how JWT validation is performed under that code path.
What this vulnerability actually means
The root cause is improper validation of a trusted OIDC issuer. In a secure implementation, the issuer should be parsed as a URL, normalized, and compared against an allowlist of exact trusted origins or hosts. Instead, the vulnerable logic described in the CVE relies on a string prefix comparison in is_issuer_known in pia/models.py:139.
That implementation error has a direct trust consequence. If PIA accepts an issuer that only looks right at the beginning of the string, it may then fetch OIDC discovery metadata and JWKS keys from a server the attacker controls. At that point, token verification can be subverted because the verifier may accept a JWT signed with the attacker’s own key, not the legitimate issuer’s key.
For defenders, the “so what” is straightforward: this is not just an SSRF bug. It is an SSRF bug tied to identity trust. If your deployment relies on that token verification path for authorization or workflow decisions, the downstream impact may include forged identity assertions, false trust in uploaded data, or access to processing paths that should only accept trusted Jenkins-originated tokens.
Who is affected
The available primary-source material identifies the affected product as Eclipse CSI PIA. The Eclipse GitLab reference title explicitly describes the issue as an unauthenticated SSRF via issuer allowlist prefix bypass in OIDC verification. The vulnerable functionality is tied to OIDC issuer allowlist logic for Jenkins tokens, specifically is_issuer_known, with the reachable endpoint identified as POST /v1/upload/sbom.
What is not currently verified from the available source material is the exact release range affected. There is no explicit affected version range published in the NVD text provided here, and no accessible vendor advisory text in the research note that states “versions X through Y are affected.” The most accurate statement, based on available evidence, is that affected builds are those containing the vulnerable prefix-check implementation described in the CVE.
Because the exact range is unknown, defenders should assume any deployed PIA version is potentially affected until they can verify one of the following: a vendor fix note, a code diff replacing the prefix check with strict URL validation, or a package/release version explicitly marked as remediated. In the absence of that data, assume exposed internet-facing instances are at risk.
Affected versions and fixed version status
The current evidence does not provide a verifiable affected version range. There is also no publicly verified fixed version number in the source material supplied for this article. That means I cannot responsibly claim a version range such as “before 1.2.3” or a fixed release such as “1.2.4” without inventing details.
Here is the precise status defenders should work from:
| Versioning detail | Current verified status |
|---|---|
| Affected version range | Unknown from available primary-source material |
| Fixed version number | Unknown from available primary-source material |
| Patch availability | Not publicly verified in supplied sources |
| Safe assumption | Any PIA build containing the vulnerable issuer prefix check may be affected |
In the absence of a confirmed fixed version, defenders should prioritize containment and verification over waiting for perfect metadata. Review your deployed source, image, or package contents for the vulnerable logic in is_issuer_known and any code path that accepts an issuer tied to POST /v1/upload/sbom. If you operate from source, a local code audit may give you faster certainty than waiting for a public release note.
Technical Notes
A minimal example of the vulnerable pattern described by NVD would look like this:
def is_issuer_known(issuer: str) -> bool:
return issuer.startswith("https://ci.eclipse.org")
A safer validation approach would parse and strictly validate the URL host and scheme instead of relying on string prefixes:
from urllib.parse import urlparse
ALLOWED_ISSUERS = {"https://ci.eclipse.org"}
def is_issuer_known(issuer: str) -> bool:
parsed = urlparse(issuer)
normalized = f"{parsed.scheme}://{parsed.hostname}"
return normalized in ALLOWED_ISSUERS and parsed.username is None
Exploitation status and risk assessment
At the time of writing, there is no confirmed evidence of exploitation in the wild from the CISA Known Exploited Vulnerabilities catalog. The research note indicates on_kev: false, which means CISA is not currently listing CVE-2026-14336 as known exploited. That is useful context, but it should not be read as proof of safety. Many vulnerabilities are actively tested or exploited before they ever appear in KEV, and some never do.
There is also no confirmed public PoC identified in the available source material. That said, the exploitation concept is explicit in the NVD description: the attacker supplies a crafted issuer string that passes the prefix check, then hosts OIDC discovery and JWKS content on infrastructure they control. Because the vulnerability mechanics are clearly described, defenders should assume reproduction is feasible even without a GitHub proof-of-concept.
Operationally, the absence of a public exploit should not lower priority much. This bug is unauthenticated, network-reachable, and tied to identity trust. If the vulnerable endpoint is internet-exposed and outbound egress is allowed, an attacker may be able to test and exploit the flaw with limited friction.
What to tell stakeholders
For security teams, describe CVE-2026-14336 as an unauthenticated trust-boundary failure in OIDC issuer validation with SSRF behavior. The severity comes from the combination of remote reachability, identity trust subversion, and lack of required credentials. This is not a theoretical parsing edge case; it is a common validation mistake with clear exploitation mechanics.
For operations and leadership, the most important fact is that a public fixed version is not yet verified in the source material. That means remediation work may require compensating controls before an official release can be confirmed. The right near-term plan is exposure reduction, egress restriction, targeted detection, and active monitoring of upstream project updates.
How to detect attempted exploitation
Start by looking for unauthenticated requests to POST /v1/upload/sbom, especially those followed closely by outbound HTTP(S) requests from the PIA application to unexpected hosts. The attack path described in the CVE depends on getting the service to perform OIDC discovery or JWKS retrieval against attacker-supplied infrastructure. That creates a valuable correlation opportunity between inbound application requests and egress connections.
You should also inspect any logs that capture issuer values, OIDC metadata fetches, token verification errors, or remote JWKS retrieval. Even if the application does not log the full issuer by default, reverse proxy logs, WAF logs, egress proxy records, DNS logs, and container network telemetry can still reveal suspicious hostnames containing strings like ci.eclipse.org@ or ci.eclipse.org. followed by an unexpected suffix.
Technical Notes
Concrete patterns worth searching for include issuer values using the userinfo form or deceptive suffixes:
https://ci.eclipse.org@evil.host
https://ci.eclipse.org.evil.host
Example grep patterns for application, proxy, or request logs:
grep -R -E 'POST /v1/upload/sbom|ci\.eclipse\.org@|ci\.eclipse\.org\.[A-Za-z0-9.-]+' /var/log
Example Splunk query to correlate inbound requests and suspicious issuer strings:
(index=app_logs OR index=proxy_logs)
("POST /v1/upload/sbom" OR "issuer=" OR "jwks" OR "openid-configuration")
| regex _raw="ci\.eclipse\.org(@|\.)"
| table _time, host, source, src_ip, dest_ip, uri_path, _raw
Example Sigma-style detection concept for suspicious issuer values in HTTP bodies or logs:
title: Suspicious OIDC Issuer Pattern Targeting PIA
logsource:
product: webserver
detection:
selection1:
request_method: POST
url|contains: "/v1/upload/sbom"
selection2:
request_body|contains:
- "https://ci.eclipse.org@"
- "https://ci.eclipse.org."
condition: selection1 and selection2
level: high
If you have egress monitoring, also flag outbound requests from the PIA host or container to newly observed domains immediately after SBOM upload activity. Unexpected DNS lookups or HTTPS sessions to non-Eclipse-controlled infrastructure are strong hunting leads.
Mitigation and patching
Because no verified fixed version number is available in the supplied primary sources, mitigation has to focus on immediate risk reduction. First, restrict access to POST /v1/upload/sbom if it does not need to be publicly reachable. Put it behind authentication, IP allowlists, VPN access, or an internal ingress boundary if your deployment model allows it. Even if the upstream fix lands later, reducing exposure now cuts off the unauthenticated attack path.
Second, restrict outbound network access from the PIA service. The SSRF component of this vulnerability depends on the application being able to reach attacker-controlled OIDC discovery and JWKS endpoints over HTTP(S). If the service only needs to communicate with a limited set of trusted domains, enforce egress filtering at the container, host, or firewall level. This can significantly blunt exploitation even before a code fix is available.
Third, inspect the code or image you are running. If you maintain the deployment from source, replace any bare prefix validation for OIDC issuers with strict parsing and exact host/origin allowlisting. If you rely on vendor containers or packages, monitor the upstream Eclipse CSI PIA project for a commit, merge request, or release note that names CVE-2026-14336 and confirms the fixed build.
Technical Notes
If you deploy with containers, a temporary network policy approach may help. For Kubernetes, deny broad egress and only permit required destinations:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: pia-restrict-egress
spec:
podSelector:
matchLabels:
app: pia
policyTypes:
- Egress
egress:
- to:
- namespaceSelector: {}
If you operate from source and need an interim code-level workaround, search for the vulnerable function and replace the prefix logic:
grep -R -n "is_issuer_known\|startswith(\"https://ci.eclipse.org" .
If you build and redeploy a Python application image locally after patching code, the exact command depends on your deployment, but a common workflow is:
docker build -t pia:patched .
docker stop pia && docker rm pia
docker run -d --name pia --restart unless-stopped pia:patched
If the service is managed in Kubernetes, redeploy the patched image with:
kubectl set image deployment/pia pia=pia:patched
kubectl rollout status deployment/pia
If you cannot patch immediately, use reverse proxy rules to block the vulnerable endpoint from untrusted sources. Example NGINX approach:
location = /v1/upload/sbom {
allow 10.0.0.0/8;
deny all;
}
References
The following sources support the verified details in this article:
| Source | URL |
|---|---|
| NVD CVE record | https://nvd.nist.gov/vuln/detail/CVE-2026-14336 |
| Eclipse GitLab work item | https://gitlab.eclipse.org/security/cve-assignment/-/work_items/154 |
| CISA KEV catalog | https://www.cisa.gov/known-exploited-vulnerabilities-catalog |
For further reading on related security practices, check out our articles on comparing the best phishing simulation platforms and what is homomorphic encryption.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.