CVE-2026-67345 in MaxKey
Summary
by MITRE • 07/30/2026
MaxKey through 4.1.12, fixed in commit ddbb72f, contains an insufficient redirect URI validation vulnerability in DefaultRedirectResolver.hostMatches() that allows remote attackers to hijack OAuth 2.0 authorization codes by supplying a crafted redirect_uri whose hostname suffix matches a registered URI without proper dot-boundary anchoring. Attackers who control a domain ending with the registered redirect URI hostname can social-engineer victims into clicking a crafted authorization URL, causing the authorization code to be issued to the attacker-controlled URI and exchanged for an access token granting access to the victim's identity.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/30/2026
The vulnerability exists within MaxKey versions through 4.1.12 in the DefaultRedirectResolver.hostMatches() method where insufficient validation of redirect URIs creates a critical security flaw that enables open redirect attacks. This issue stems from improper dot-boundary anchoring during hostname comparison, allowing attackers to exploit domain suffix matching logic to manipulate OAuth 2.0 authorization flows. The vulnerability specifically affects the authorization code flow where the attacker crafts a malicious redirect_uri parameter that ends with the legitimate registered URI hostname but includes additional subdomain components.
The technical implementation flaw resides in how the hostMatches() function processes hostname validation without enforcing proper boundary checking between domain components. When an attacker registers a domain such as example.com and a legitimate application uses redirect_uri ending with example.com, the vulnerable code will incorrectly validate a crafted URI like evil.example.com as matching the registered pattern due to the absence of strict dot-boundary enforcement. This creates a condition where the authorization server fails to properly verify that the redirect URI represents an exact match or authorized subdomain structure rather than merely sharing a suffix.
This vulnerability enables sophisticated social engineering attacks where threat actors can manipulate victims into clicking carefully crafted authorization URLs that appear legitimate but redirect to attacker-controlled endpoints. The operational impact is severe as it allows attackers to intercept valid OAuth 2.0 authorization codes and exchange them for access tokens that grant full access to victim identities within the compromised application ecosystem. The attack chain typically involves registering a domain that matches the suffix of a legitimate redirect URI, crafting phishing emails or malicious links, and tricking users into initiating authentication flows that ultimately deliver authorization codes to the attacker's controlled endpoint.
The security implications extend beyond simple redirection attacks as this vulnerability can lead to complete identity compromise and unauthorized access to protected resources within applications using MaxKey for authentication. The flaw aligns with CWE-601 Open Redirect vulnerability classification, which specifically addresses cases where applications redirect users to untrusted domains without proper validation. From an attack perspective, this vulnerability maps to ATT&CK technique T1539 Steal Web Session Cookie and T1566 Phishing within the credential access and initial access domains respectively.
Mitigation strategies include implementing strict dot-boundary validation in hostname comparison logic, enforcing exact domain matching rather than suffix matching, and ensuring that redirect URI validation properly considers subdomain boundaries. Organizations should upgrade to MaxKey version containing commit ddbb72f which addresses this specific validation issue. Additional defensive measures include configuring applications to validate redirect URIs against a strict whitelist of approved domains, implementing proper logging and monitoring for suspicious redirect attempts, and conducting regular security assessments of OAuth 2.0 implementations to identify similar boundary validation flaws in custom authentication flows.