Which versions of MaxKey are affected by CVE-2026-67345?

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…. A patch is available.

Is there a public PoC exploit available for CVE-2026-67345?

Yes, a public proof-of-concept exploit is available for CVE-2026-67345. Prioritise patching immediately. EPSS: 0.3%.

How to fix or mitigate CVE-2026-67345?

Within 24 hours, conduct an asset inventory to determine whether your organization runs Dromara MaxKey and identify all federated systems and applications that depend on it for authentication. Within 7 days, apply the vendor patch to MaxKey (commit ddbb72f), coordinating the deployment with application owners to execute the update during a scheduled maintenance window to minimize service disruption. Within 30 days, conduct a comprehensive access review of federated user accounts active during the vulnerability exposure window, implement additional OAuth token controls such as shorter token lifespans and audience restrictions, and review authentication logs for evidence of authorization-code theft attempts.

MaxKey CVE-2026-67345

Q: What is the CVSS score of CVE-2026-67345?

CVE-2026-67345 has a CVSS 4.0 base score of 8.5 (High). CVSS vector: 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

EUVD-2026-51148 HIGH

Permissive List of Allowed Inputs (CWE-183)

2026-07-30 VulnCheck

GHSA-7957-wqgw-m3j9

Information Disclosure Maxkey Dromara

8.5

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

8.5 HIGH

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

9.3 CRITICAL

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.

3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 30, 2026 - 15:23 vuln.today

Analysis Generated

Jul 30, 2026 - 15:23 vuln.today

CVE Published

Jul 30, 2026 - 14:39 cve.org

HIGH 8.5

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.

AnalysisAI

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).

Technical ContextAI

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.

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.