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

MaxKey identity and access management server (versions 0-4.1.11) contains a critical authentication bypass permitting unauthenticated attackers to mint valid administrator credentials and seize…

How to fix or mitigate CVE-2026-69102?

Within 24 hours: Verify deployment status of MaxKey versions 0 through 4.1.11 across all environments and immediately disable the JWT login feature by setting LOGIN_JWT=false in application-maxkey.properties; simultaneously audit all administrative session logs for signs of unauthorized access and impersonation. Within 7 days: Deploy network-level access restrictions to MaxKey endpoints using firewall rules and VPN requirements, rotate all credentials and secrets currently managed through MaxKey, enable comprehensive logging on the /sign/login/jwt/trust endpoint, and establish 24/7 security monitoring for authentication anomalies and privilege escalation attempts. Within 30 days: Monitor MaxKey vendor advisories and CISA notifications for a security patch; immediately apply any released patch to all affected instances; if no patch becomes available by end of Q3, evaluate and plan migration to alternative SSO solutions.

MaxKey CVE-2026-69102

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

CVE-2026-69102 has a CVSS 4.0 base score of 9.3 (Critical). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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.4%.

EUVD-2026-56852 CRITICAL

Use of Hard-coded Credentials (CWE-798)

2026-08-11 disclosure@vulncheck.com

GHSA-xhfc-44v3-4rhf

Authentication Bypass

9.3

CVSS 4.0 · Vendor: vulncheck

Severity by source

Vendor (vulncheck) PRIMARY

9.3 CRITICAL

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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.8 CRITICAL

Remote unauthenticated forgery of admin tokens via a known secret gives AV:N/AC:L/PR:N/UI:N; full admin control over the IdP yields C:H/I:H/A:H, though a scope change (S:C) is arguable given downstream-app impact.

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

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Aug 11, 2026 - 19:35 vuln.today

Analysis Generated

Aug 11, 2026 - 19:35 vuln.today

CVE Published

Aug 11, 2026 - 18:18 cve.org

CRITICAL 9.3

DescriptionCVE.org

MaxKey contains an unauthorized access vulnerability due to a hard-coded JWT signing secret in application-maxkey.properties that allows unauthenticated attackers to forge valid JWT tokens and authenticate as any user by exploiting the password-skipped login endpoint. Attackers can craft a JWT token signed with the publicly known default secret, submit it to the /sign/login/jwt/trust endpoint, and obtain a fully authenticated admin session with access to SSO application configuration and downstream application secrets.

AnalysisAI

Authentication bypass in MaxKey identity/SSO server (versions 0 through 4.1.11) lets unauthenticated attackers mint valid JWTs using a hard-coded, publicly known signing secret shipped in application-maxkey.properties and present them to the /sign/login/jwt/trust endpoint to obtain a fully authenticated admin session. Because affected builds ship with JWT login enabled by default (LOGIN_JWT defaulting to true), an attacker can set an arbitrary subject claim to impersonate any user, including administrators, gaining control of SSO application configuration and downstream application secrets. No public exploit identified at time of analysis and no CISA KEV listing, but the trivial exploitation path and VulnCheck advisory make this high priority.

Technical ContextAI

MaxKey is an open-source Java/Spring Boot Identity and Access Management (IAM) and single sign-on server maintained under the Dromara community. The flaw is CWE-798 (Use of Hard-coded Credentials): the HS512 JWT signing secret used to validate trust tokens is embedded in the distributed application-maxkey.properties, so anyone reading the public source tree knows the key. The vulnerable HttpJwtEntryPoint exposed a /jwt/trust route (reachable as /sign/login/jwt/trust) that called authTokenService.validateJwtToken()/resolve() and then authenticated whatever subject the token carried, with no per-deployment secret and no gate on whether JWT login was intended. The fixing commit (6cda394) removes the /jwt/trust handler entirely, gates the remaining JWT login path behind a new maxkey.login.jwt config flag, and flips that flag's default from true to false in both the core and management webapps.

RemediationAI

Upstream fix available (commit 6cda394ec111f03a06fb2eed0de74f787d68bd97); a released patched version is not independently confirmed from the provided data, so upgrade to the first tagged MaxKey release built after 4.1.11 that incorporates this commit, verifying against the repository. The fix removes the /jwt/trust endpoint and disables JWT login by default (maxkey.login.jwt=false). As an immediate compensating control on unpatched instances, set maxkey.login.jwt / LOGIN_JWT to false in application-maxkey.properties and application-maxkey-mgt.properties to disable the JWT login path - the trade-off is that any legitimate JWT-based SSO login integration you rely on will stop working. Additionally, block or restrict network access to the /sign/login/jwt/trust endpoint at a reverse proxy or WAF, and if you must keep JWT login, override the shipped signing secret with a strong per-deployment value so forged tokens fail validation. Track remediation via issue https://github.com/dromara/MaxKey/issues/270 and the VulnCheck advisory.