CVE-2026-90452 in Malcolm
Summary
by MITRE • 09/12/2026
Requests from the reverse proxy to the identity-provider service for token discovery, introspection, and credential exchange do not verify the identity provider's server certificate. An attacker positioned on the network path between the proxy and the identity provider could impersonate the identity provider and issue forged authentication tokens accepted by the deployment.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability described constitutes a critical failure in transport layer security validation within an OAuth 2.0 or OpenID Connect implementation, specifically affecting the communication channel between a reverse proxy and an upstream Identity Provider service. This flaw manifests as a lack of server certificate verification during TLS handshakes for sensitive operations such as token discovery via well-known endpoints, introspection of access tokens to determine their validity and scope, and credential exchange processes like client authentication or authorization code exchanges. By omitting the validation of the X.509 certificate presented by the identity provider, the reverse proxy fails to establish a trusted binding between the network address it connects to and the cryptographic identity claimed by that server. This omission effectively neutralizes one of the primary defenses against man-in-the-middle attacks in public or semi-public networks, allowing any entity capable of intercepting traffic on this path to inject themselves into the communication stream without triggering security alerts or connection failures.
From a technical perspective, this defect aligns with CWE-295 Improper Certificate Validation and CWE-319 Cleartext Transmission of Sensitive Information in an Unprotected Channel. The reverse proxy acts as a client initiating outbound connections to the identity provider but neglects to verify that the certificate presented matches expected trust anchors or domain names. In standard TLS implementations, clients must validate that the server's certificate is signed by a trusted Certificate Authority and that the subject name or Subject Alternative Name fields match the intended hostname of the identity provider. Without this verification step, the proxy accepts any validly signed certificate from any host, regardless of whether it belongs to the legitimate identity provider infrastructure. This creates a scenario where an attacker can present a self-signed certificate or a certificate for a different domain that they control, and the reverse proxy will proceed with establishing an encrypted session under the false assumption that it is communicating securely with the authentic service.
The operational impact of this vulnerability is severe, as it enables a sophisticated Man-in-the-Middle attack where the attacker can intercept, decrypt, modify, or forge authentication artifacts. Since the proxy does not verify the identity provider's certificate, an attacker positioned on the network path can impersonate the identity provider during token discovery requests to redirect subsequent flows to malicious endpoints. During credential exchange and introspection operations, the attacker can capture sensitive tokens such as access tokens, refresh tokens, or ID tokens transmitted in cleartext within the TLS session because they control the endpoint receiving these credentials. Furthermore, the attacker can forge valid authentication tokens that are accepted by the deployment due to the lack of downstream validation against the true identity provider's public keys or signing certificates if those checks also rely on the compromised channel context. This allows the attacker to gain unauthorized access to protected resources and applications relying on this authentication flow, potentially leading to full account compromise, data exfiltration, or lateral movement within the internal network depending on the privileges associated with the forged tokens.
This vulnerability maps directly to MITRE ATT&CK technique T1557 Adversary-in-the-Middle, specifically sub-techniques involving session hijacking and credential interception such as LLMNR/NBT-NS Poisoning if applicable in local networks or more generally SSL/TLS Session Hijacking. It also relates to T1078 Valid Accounts, as the forged tokens allow attackers to operate with legitimate user credentials. The exploitation typically requires network-level access between the reverse proxy and the identity provider, which may be achievable through ARP spoofing on a shared LAN, DNS hijacking if internal resolution is compromised, or BGP route manipulation in cloud environments where routing paths can be influenced by an adversary controlling adjacent infrastructure segments.
Mitigation strategies must prioritize strict enforcement of certificate validation at every step of the TLS handshake initiated by the reverse proxy toward the identity provider. Administrators should configure the proxy software to require valid certificates signed by trusted Certificate Authorities and ensure that hostname verification is enabled so that the presented certificate matches the expected domain name of the identity provider service. Implementing Certificate Pinning, where the application explicitly trusts only specific public keys or certificates associated with the identity provider, provides an additional layer of defense against compromised CA issues or rogue certificates issued to other domains. Additionally, deploying mutual TLS (mTLS) can strengthen authentication by requiring both parties to present and validate certificates, ensuring bidirectional trust. Regular auditing of proxy configurations for missing security headers and validation flags is essential, along with monitoring network traffic for anomalies that might indicate active exploitation attempts such as unexpected certificate changes or connection failures during token exchange processes.