CVE-2026-18353 in PIA
Summary
by MITRE • 07/30/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/30/2026
The vulnerability in PIA's POST /v1/upload/sbom endpoint represents a critical authorization bypass flaw that stems from improper URL parsing and validation mechanisms within the OpenID Connect (OIDC) discovery process. This issue manifests when the system accepts a Bearer JWT token and performs an unverified check of the token's issuer claim against a predefined allowlist. The implementation relies on Python's urlparse function to parse the issuer URL, which creates a fundamental mismatch between the parsing logic used for validation and the actual network communication that follows. When an attacker crafts an issuer URL containing a backslash character within the authority portion of the URI, such as https://attacker-host\@ci.eclipse.org/, the urlparse function correctly parses this into a hostname that matches the allowlist entries while simultaneously creating a different hostname that gets used by the requests library for actual network operations. This discrepancy creates an authentication bypass vector where malicious actors can pass the initial allowlist validation but ultimately direct the system to establish connections with arbitrary hosts, ports, and schemes. The vulnerability directly relates to CWE-20, which addresses improper input validation, and specifically demonstrates a path traversal or injection weakness in URI parsing that enables unauthorized network access.
The operational impact of this vulnerability extends beyond simple authentication bypass to encompass potential data exfiltration, service disruption, and lateral movement within the target environment. An attacker who successfully exploits this flaw can redirect the OIDC discovery process to connect to malicious servers they control, potentially allowing them to retrieve sensitive information or manipulate the authentication flow. The requests library's handling of backslash characters in URL authority strings creates a condition where network communication bypasses the intended security controls, enabling attackers to perform unauthorized connections that would normally be blocked by the allowlist mechanism. This issue also presents opportunities for man-in-the-middle attacks, as the system may establish connections to attacker-controlled endpoints without proper verification of the target host's authenticity. The vulnerability effectively undermines the security assumptions around the issuer allowlist, rendering it ineffective as a protective control mechanism. From an attack perspective, this flaw aligns with techniques described in the MITRE ATT&CK framework under T1566 (Phishing for Information) and T1071.004 (Application Layer Protocol: DNS) when combined with other exploitation methods, though it primarily functions as a network-level bypass rather than a direct credential theft vector.
Mitigation strategies must address both the immediate parsing inconsistency and establish more robust validation mechanisms for OIDC issuer endpoints. Organizations should implement strict URL parsing validation that ensures consistency between allowlist checking and actual network operations, potentially by normalizing URLs through canonicalization processes before comparison. The system should enforce strict hostname validation using more comprehensive URI parsing libraries or custom validation logic that prevents backslash injection attacks from succeeding. Additionally, implementing certificate pinning or explicit host verification mechanisms during OIDC discovery would prevent attackers from redirecting connections to arbitrary hosts even if they bypass the initial allowlist check. Network segmentation and outbound connection controls should be enforced to limit what external hosts the system can communicate with during authentication processes. Security teams should also consider implementing monitoring for unusual network connections originating from authentication endpoints, as this vulnerability would likely generate network traffic patterns that differ significantly from normal operations. The fix must ensure that all URL components, particularly those used in authentication contexts, undergo consistent parsing and validation to prevent similar issues across other parts of the application. Implementing proper input sanitization and validation at multiple layers of the system architecture would provide defense-in-depth against similar vulnerabilities that could arise from inconsistent URI handling practices. Organizations should also review their OIDC implementation patterns to ensure that all external network communications are properly validated and that allowlist mechanisms function consistently across all stages of authentication processing, preventing attackers from exploiting parsing differences between validation and execution contexts.