CVE-2026-69102: MaxKey Auth Bypass Vulnerability

CVE-2026-69102 Overview

MaxKey contains an unauthorized access vulnerability caused by a hard-coded JSON Web Token (JWT) signing secret in application-maxkey.properties. Unauthenticated attackers can forge valid JWT tokens using the publicly known default secret and authenticate as any user through the password-skipped login endpoint. Submitting the forged token to /sign/login/jwt/trust returns a fully authenticated administrative session. That session grants access to Single Sign-On (SSO) application configuration and downstream application secrets, enabling lateral compromise of every service federated through MaxKey. The weakness is classified under [CWE-798: Use of Hard-coded Credentials].

Critical Impact
Remote, unauthenticated attackers can impersonate any MaxKey user, including administrators, and pivot to every downstream SSO-integrated application.

Affected Products

MaxKey Single Sign-On (SSO) platform maintained by the Dromara community
Deployments using the default application-maxkey.properties JWT signing configuration
Instances exposing the /sign/login/jwt/trust endpoint to untrusted networks

Discovery Timeline

2026-08-11 - CVE-2026-69102 published to the National Vulnerability Database (NVD)
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-69102

Vulnerability Analysis

MaxKey ships with a JWT signing secret embedded in application-maxkey.properties. Because the secret is distributed with the source repository, any attacker inspecting the project can reproduce it. The server accepts JWTs signed with this key at the /sign/login/jwt/trust endpoint, which is designed to trust externally provided tokens without password verification. An attacker crafts a JWT whose sub claim references an administrator account, signs it with the disclosed secret, and posts it to the endpoint. MaxKey validates the signature, treats the token as authoritative, and issues a session bound to the impersonated account. The attacker inherits full administrative privileges over SSO application definitions, client secrets, and federated authentication policies.

Root Cause

The root cause is a static credential compiled into the shipped configuration file. The HttpJwtEntryPoint handler processes JWTs on the trust endpoint even when the JWT login feature was never intentionally enabled by the operator. There was no runtime toggle to disable JWT trust login, and no warning when the default secret remained unchanged.

Attack Vector

The attack requires only network reachability to the MaxKey web interface. No credentials, user interaction, or prior access are needed. The attacker builds a token offline, submits it in a single HTTP POST request, and receives an authenticated session cookie in response.

java

// Patch: introduces a maxkey.login.jwt toggle so operators must
// explicitly enable JWT trust login instead of it being always-on
@Value("${maxkey.login.wsfederation:false}")
boolean wsFederation;

@Value("${maxkey.login.jwt:false}")
boolean jwt;

@Value("${maxkey.login.cas.serverUrlPrefix:http://sso.maxkey.top/sign/authz/cas}")
String casServerUrlPrefix;

Source: GitHub commit 6cda394

Detection Methods for CVE-2026-69102

Indicators of Compromise

HTTP POST requests to /sign/login/jwt/trust from external or unexpected source addresses
Successful authentication events with no preceding password submission or multi-factor challenge
JWTs presented to MaxKey signed with the default secret value shipped in application-maxkey.properties
New or modified SSO application entries, client secrets, or user roles created immediately after a /sign/login/jwt/trust request

Detection Strategies

Alert on any request to the /sign/login/jwt/trust path, since legitimate use is limited to explicitly configured trust integrations
Correlate MaxKey authentication logs against reverse-proxy access logs to flag session issuance without a corresponding login form submission
Inspect archived MaxKey configuration files for the shipped default jwt.secret value and treat unchanged deployments as high risk

Monitoring Recommendations

Forward MaxKey application, access, and audit logs to a centralized SIEM with retention sufficient for post-incident review
Monitor administrator role assignments and OAuth or SAML client secret exports for anomalous frequency
Track outbound authentication flows from downstream SSO-integrated applications for sessions traceable to compromised MaxKey tokens

How to Mitigate CVE-2026-69102

Immediate Actions Required

Upgrade MaxKey to a build that includes commit 6cda394, which adds the maxkey.login.jwt toggle and hardens HttpJwtEntryPoint
Rotate the JWT signing secret in application-maxkey.properties to a cryptographically random value unique to the deployment
Rotate all downstream SSO client secrets and administrator credentials because they may have been exfiltrated
Review audit logs for prior requests to /sign/login/jwt/trust and treat any successful ones as potential compromise

Patch Information

The fix is available in the upstream Dromara MaxKey repository at commit 6cda394ec111f03a06fb2eed0de74f787d68bd97. The patch introduces an explicit maxkey.login.jwt property defaulting to false, so the JWT trust login path is disabled unless an operator opts in. Additional details are tracked in MaxKey issue #270 and the VulnCheck advisory.

Workarounds

Block the /sign/login/jwt/trust endpoint at the reverse proxy or web application firewall until patching is complete
Restrict network access to MaxKey administrative interfaces to a management VLAN or VPN
If the JWT trust login feature is not required, remove or comment out the JWT entry point registration and redeploy

bash

# Example NGINX rule to block the vulnerable endpoint until patched
location = /sign/login/jwt/trust {
    return 403;
}

# After patching, set an explicit random secret and disable JWT login by default
# application-maxkey.properties
maxkey.login.jwt=false
maxkey.jwt.secret=$(openssl rand -base64 48)