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

Eclipse CSI PIA contains a server-side request forgery vulnerability in the SBOM upload endpoint that allows unauthenticated attackers to coerce the server into connecting to arbitrary hosts,…. A patch is available.

How to fix or mitigate CVE-2026-18353?

Within 24 hours: Inventory all Eclipse CSI PIA deployments and restrict network access to the `/v1/upload/sbom` endpoint using firewall rules or WAF-permit only known SBOM sources. Within 7 days: Implement egress filtering to restrict outbound connections from the PIA server to only required OIDC/JWKS hosts, and apply URL parsing hardening via a proxy layer that validates against both urllib and Python urlparse semantics. Within 30 days: Monitor the Eclipse Foundation's advisory for patch availability (current patch status: no vendor-released patch identified at time of analysis); consider evaluating alternative SBOM processing tools if the patch timeline extends beyond your risk tolerance.

Eclipse CSI PIA CVE-2026-18353

Q: What is the CVSS score of CVE-2026-18353?

CVE-2026-18353 has a CVSS 4.0 base score of 8.8 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

EUVD-2026-51066 HIGH

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

2026-07-30 eclipse

Python SSRF Red Hat Eclipse Csi Pia Eclipse Foundation

8.8

CVSS 4.0 · Vendor: eclipse

Severity by source

Vendor (eclipse) PRIMARY

8.8 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.2 HIGH

Unauthenticated network endpoint with an unverified iss check (PR:N/AC:L); SSRF yields high integrity control over outbound requests (I:H) and limited data exposure (C:L), 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

Red Hat

8.2 HIGH

qualitative

Primary rating from Vendor (eclipse).

CVSS VectorVendor: eclipse

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jul 30, 2026 - 09:03 EUVD

Analysis Generated

Jul 30, 2026 - 08:39 vuln.today

CVE Published

Jul 30, 2026 - 07:23 cve.org

HIGH 8.8

DescriptionCVE.org

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 (e.g. https://attacker-host\@ci.eclipse.org/) into *different* hostnames, an attacker can craft an issuer that passes the allowlist check yet drives requests - and subsequently urllib.request.urlopen for JWKS retrieval - to connect to an arbitrary attacker-chosen host, port, and scheme.

Articles & Coverage 1

News 3 New Python Vulnerabilities - 3 High Severity Jul 31, 2026

AnalysisAI

Server-side request forgery in the Eclipse CSI PIA POST /v1/upload/sbom endpoint lets remote attackers coerce the server into connecting to an arbitrary host, port, and scheme of their choosing. By exploiting a parser-differential between Python's urlparse (used for the issuer allowlist check) and requests/urllib3/urllib (used for OIDC discovery and JWKS retrieval), an attacker crafts a JWT iss claim containing a backslash that passes validation but resolves to a different host during the actual fetch. The iss claim is only checked in its unverified form, so no legitimate token is needed; no public exploit has been identified at time of analysis and the issue is not listed in CISA KEV.

Technical ContextAI

The vulnerability is a classic OIDC issuer/JWKS SSRF rooted in inconsistent URL authority parsing (CWE-918, Server-Side Request Forgery). PIA validates the JWT iss claim against an issuer allowlist using urllib.parse.urlparse, then performs OIDC discovery with the requests library and fetches JWKS via urllib.request.urlopen. RFC 3986 treats a backslash as an invalid authority character, but implementations disagree on how to normalize it: given https://attacker-host\@ci.eclipse.org/, urlparse may interpret the host one way (matching the allowlisted ci.eclipse.org) while requests/urllib3 and the WHATWG-influenced browsers/clients treat the backslash as a delimiter, resolving the authority to attacker-host. This differential means the string that satisfies the security check is not the string that governs the network connection. The affected component is identified by CPE cpe:2.3:a:eclipse_foundation:eclipse_csi_-_pia:* and the flaw sits in the trust boundary between allowlist enforcement and outbound HTTP execution.

RemediationAI

Apply the fix from the Eclipse CSI PIA GitHub Security Advisory GHSA-v249-9xjm-qhgf (https://github.com/eclipse-csi/pia/security/advisories/GHSA-v249-9xjm-qhgf); an exact patched version is not stated in the provided data, so confirm and pin the fixed release from that advisory. The correct code-level fix is to parse the issuer once and reuse the identical, fully-normalized URL for both the allowlist check and the outbound request, and to reject any authority containing backslashes, embedded credentials (@), or other RFC 3986-invalid characters before comparison. As compensating controls until patched: enforce strict egress filtering so the PIA host can only reach the known OIDC issuer domains (e.g. ci.eclipse.org) rather than arbitrary hosts/ports - this blocks the SSRF pivot but requires maintaining an allowlist of legitimate issuers; restrict network access to the /v1/upload/sbom endpoint to trusted CI networks via reverse-proxy ACLs, at the cost of breaking any legitimate external callers; and validate the iss claim against an exact-match string allowlist (not a URL-parse comparison) to remove the parser-differential entirely.