Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
ReconRegister domain suffix-matching a registered redirect host
-
DeliveryCraft malicious OAuth authorization URL
-
ExploitPhish victim into clicking link
-
InstallMaxKey validates redirect via endsWith()
-
C2Authorization code issued to attacker host
-
ExecuteExchange code for access token
-
ImpactImpersonate victim identity
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Strict input allowlisting
|
| Exploitation Conditions | Requires that MaxKey is used as an OAuth 2.0 authorization-code (or implicit) provider with subdomain matching effectively enabled - DefaultRedirectResolver.matchSubdomains defaults to true, so this is the default behavior - and that at least one OAuth client is registered with a redirect URI whose hostname the attacker can suffix-match by registering/controlling a domain ending in that registered hostname (e.g. registered 'example.com' abused via 'attacker-example.com'). Exploitation is limited by UI:A: a victim with an active MaxKey session must be social-engineered into clicking the attacker's crafted authorization URL; no attacker authentication is needed (PR:N), but success depends on that user interaction and on a registered client whose redirect host is suffix-collidable. |
| Impact | The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:N, base 8.5 High) indicates a network-reachable, low-complexity, unauthenticated attack with high confidentiality and integrity impact, but it explicitly requires active user interaction (UI:A) - the victim must click a crafted authorization URL. That user-interaction requirement is the main brake on real-world risk: this is a social-engineering-dependent account-takeover primitive, not a wormable server-side RCE. Publicly available exploit code raises practical risk, but there is no CISA KEV listing and no EPSS score was provided, so there is no evidence of active or widespread exploitation at this time - treat exploit availability and active exploitation as distinct signals. Net: a patch-now issue for any internet-facing MaxKey deployment used as an SSO broker (a successful attack yields full identity/session takeover), tempered by the product's relatively niche footprint and the phishing prerequisite. |
| Exploit ScenarioDerived | An attacker registers a domain whose hostname ends with a victim tenant's registered redirect URI host (e.g. controlling 'goodexample.com' to abuse a registered 'example.com'), then crafts an OAuth authorization URL pointing MaxKey to that attacker-controlled redirect_uri and phishes a logged-in victim into clicking it. Because DefaultRedirectResolver accepts the suffix match, MaxKey issues the authorization code to the attacker's host, which exchanges it for an access token to impersonate the victim. Publicly available exploit code lowers the bar to reproduce this. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 30, 2026
OAuth 2.0 authorization-code theft in Dromara MaxKey through 4.1.12 lets remote attackers hijack a victim's authorization code and exchange it for an access token, taking over the victim's federated identity. The flaw lives in DefaultRedirectResolver.hostMatches(), where a naive endsWith() suffix comparison lets an attacker-controlled domain that ends with a registered redirect URI hostname pass validation. Publicly available exploit code exists and a vendor patch (commit ddbb72f) is available; no active exploitation has been confirmed (not in CISA KEV).
RemediationAI
Upstream fix available (commit ddbb72f); a released, tagged patched version is not independently confirmed from the provided data, so upgrade MaxKey to a build that includes commit ddbb72fb24ab8e66aa422fb14b1177330bcffb45 (or apply that patch, which removes the permissive matchSubdomains/endsWith suffix matching and drops the implicit grant type). If you cannot upgrade immediately, the most effective compensating control is to register only exact, fully-qualified redirect URIs and avoid wildcard/subdomain matching, and - if configurable in your build - set matchSubdomains to false to disable suffix matching (side effect: legitimate clients relying on subdomain redirect matching will break and must be re-registered with explicit URIs). Additionally disable the implicit grant type if unused and restrict/monitor the authorization endpoint. Track details via the fix commit, the VulnCheck advisory (https://www.vulncheck.com/advisories/maxkey-defaultredirectresolver-oauth-authorization-code-theft), and GitHub issue #269.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MaxKey is an open-source enterprise Identity and Access Management (IAM)/single-sign-on server that implements OAuth 2.0 and OpenID Connect. The affected component is the OAuth authorization-code endpoint's redirect_uri validation in the maxkey-protocol-oauth-2.0 module's DefaultRedirectResolver. Per CWE-183 (Permissive List of Allowed Inputs), the root cause is that subdomain matching relied on Java String.endsWith(registered) with matchSubdomains defaulting to true, so a requested hostname was accepted whenever it merely ended with the registered hostname string, without anchoring on a dot ('.') boundary. This means 'attackerexample.com' satisfies a registered 'example.com', letting an unregistered attacker host masquerade as an approved redirect target. The patch (commit ddbb72fb24ab8e66aa422fb14b1177330bcffb45) removes the matchSubdomains flag and its endsWith() suffix branch entirely and drops 'implicit' from the accepted grant types. The affected package is identified by CPE cpe:2.3:a:dromara:maxkey.
Know when Maxkey gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Unauthenticated network attack (PR:N/AV:N) but needs a victim click (UI:R); the stolen token grants identity takeover on downstream resources (S:C, C:H/I:H) with no availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Latest POC
1 PoC candidate from github (unverified)
Sign in to open the public PoC links collected for this CVE.
Executive ViewAI
Dromara MaxKey versions through 4.1.12 contain an OAuth 2.0 authorization-code theft vulnerability that allows remote attackers to hijack federated user identities without requiring credentials, with publicly available exploit code creating immediate risk for any organization using MaxKey for single sign-on. Attackers can steal authorization codes via a hostname suffix-matching bypass in the redirect URI validator, then exchange those codes for access tokens and take over user accounts across all federated applications. This directly threatens access control integrity and creates material risk of unauthorized system access and data exfiltration.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Server-side request forgery (SSRF) in Dromara MaxKey up to 4.1.7 allows authenticated attackers to make internal network
SQL injection in Dromara MaxKey up to version 3.5.13 allows authenticated remote attackers to execute arbitrary SQL quer
EUVD-2026-51148
GHSA-7957-wqgw-m3j9
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB