CVE-2026-90452: Reverse Proxy Auth Bypass Vulnerability

CVE-2026-90452 Overview

CVE-2026-90452 is an improper certificate validation flaw [CWE-295] affecting a reverse proxy component that communicates with an identity provider service. The proxy issues requests for token discovery, token introspection, and credential exchange without verifying the identity provider's server certificate. An attacker positioned on the network path between the proxy and the identity provider can impersonate the identity provider and issue forged authentication tokens that the deployment accepts. The vulnerability was published to the National Vulnerability Database (NVD) on 2026-09-11 and referenced in a CISA CSAF advisory covering operational technology environments.

Critical Impact
An adjacent-network attacker can impersonate the identity provider, forge authentication tokens, and gain unauthorized access to protected resources behind the reverse proxy.

Affected Products

Reverse proxy component performing OAuth/OIDC token operations against an identity provider (specific vendor and product not disclosed in the NVD record)
Deployments referenced in CISA advisory ICSA-26-254-01 (operational technology environment)

Discovery Timeline

2026-09-11 - CVE-2026-90452 published to NVD
2026-09-18 - Last updated in NVD database

Technical Details for CVE-2026-90452

Vulnerability Analysis

The reverse proxy acts as an OAuth 2.0 / OpenID Connect (OIDC) relying party. It contacts the identity provider to fetch discovery documents, introspect bearer tokens, and exchange credentials for access tokens. These requests occur over Transport Layer Security (TLS), but the proxy does not validate the identity provider's server certificate. The client accepts any certificate presented, including self-signed or attacker-controlled certificates. This defect breaks the trust boundary that TLS is intended to enforce during authentication flows.

The consequence is authentication integrity failure. An attacker who terminates the TLS session in place of the identity provider can respond to introspection requests with active: true for tokens they minted, or return arbitrary claims during token exchange. The proxy then trusts these responses and grants access to downstream services.

Root Cause

The underlying weakness is classified as [CWE-295] Improper Certificate Validation. The proxy's HTTP client used for identity-provider communication either disables certificate verification, fails to check the certificate chain against a trusted certificate authority, or does not validate the server hostname against the certificate subject or Subject Alternative Name.

Attack Vector

Exploitation requires network-adjacent positioning between the reverse proxy and the identity provider. Typical scenarios include a compromised device on the same virtual local area network (VLAN), a rogue router, Address Resolution Protocol (ARP) spoofing on a shared segment, or DNS poisoning that redirects the identity provider hostname to an attacker-controlled endpoint. Once traffic is intercepted, the attacker presents a TLS certificate for the identity provider's hostname. The proxy completes the TLS handshake without validation and proceeds to send discovery, introspection, or credential-exchange requests. The attacker replies with forged responses that the proxy treats as authoritative.

No authentication is required to conduct the machine-in-the-middle attack, and no user interaction is needed. Further technical context is available in the CISA CSAF Document 2026.

Detection Methods for CVE-2026-90452

Indicators of Compromise

Unexpected TLS certificates presented by hosts resolving to the identity provider hostname, particularly self-signed or issued by an untrusted certificate authority.
Successful authentication events at the reverse proxy that do not correlate with matching authorization events in the identity provider's audit log.
DNS responses for the identity provider hostname pointing to IP addresses outside the documented provider range.
ARP table entries on proxy hosts showing multiple MAC addresses associated with the identity provider or default gateway.

Detection Strategies

Inspect outbound TLS traffic from the reverse proxy to the identity provider and compare presented certificate fingerprints against a known-good baseline.
Correlate reverse-proxy authentication decisions with identity-provider issuance logs to identify tokens accepted by the proxy that were never issued upstream.
Monitor for changes to certificate authority trust stores or client configuration files on the proxy host that could indicate tampering.

Monitoring Recommendations

Enable network flow logging on the segment carrying proxy-to-identity-provider traffic and alert on unexpected next-hop or IP changes.
Capture packet metadata for TLS handshakes to the identity provider endpoint and retain certificate details for forensic review.
Alert on any process on the proxy host initiating connections to the identity provider hostname over cleartext or with non-standard cipher suites.

How to Mitigate CVE-2026-90452

Immediate Actions Required

Apply the vendor patch or configuration update referenced in the CISA advisory ICSA-26-254-01 as soon as it is available for the affected deployment.
Enable strict server certificate verification on the reverse proxy's HTTP client used for identity-provider communication, including chain validation and hostname checks.
Pin the identity provider's certificate or issuing certificate authority where the proxy configuration supports certificate pinning.
Isolate the network segment between the reverse proxy and the identity provider to reduce the pool of hosts capable of adjacent-network interception.

Patch Information

Refer to the CISA CSAF Document 2026 for authoritative patch and remediation guidance from the affected vendor. The NVD record does not enumerate fixed versions; operators should confirm patched builds directly with the vendor.

Workarounds

Route proxy-to-identity-provider traffic through a mutually authenticated TLS tunnel or IPsec channel to prevent transparent interception.
Deploy DNS Security Extensions (DNSSEC) and static host entries for the identity provider hostname on the proxy host to reduce DNS-based redirection risk.
Restrict the reverse proxy's egress firewall policy so that identity-provider communication is only permitted to a specific, documented set of IP addresses.

bash

# Configuration example: enforce TLS verification for an OIDC relying party
# (generic reference; adapt to the specific reverse proxy product)

oidc_provider:
  issuer: "https://idp.example.internal"
  discovery_url: "https://idp.example.internal/.well-known/openid-configuration"
  tls:
    verify_server_certificate: true
    ca_bundle: "/etc/ssl/certs/idp-ca-bundle.pem"
    verify_hostname: true
    pinned_sha256:
      - "BASE64_SPKI_FINGERPRINT_OF_IDP_CERT"
    minimum_version: "TLSv1.3"