CVE-2026-77519: MaxKB AI Assistant Auth Bypass Vulnerability

CVE-2026-77519 Overview

CVE-2026-77519 affects MaxKB, an open-source AI assistant for enterprise use. The vulnerability exists in versions 2.10.2-lts and earlier, where the /chat/api/mcp authentication path validates ApplicationApiKey records using only the secret and active status. The endpoint fails to enforce the is_permanent and expire_time checks applied by the standard chat API. An attacker holding a previously valid but expired non-permanent application key can still initialize the Model Context Protocol (MCP) endpoint, enumerate tool metadata, invoke tools/call, and create persistent application_chat and application_chat_record state.

Critical Impact

Expired application API keys retain functional access to MCP tooling and can create durable chat records, bypassing intended lifecycle controls. [CWE-613]

Affected Products

• MaxKB 2.10.2-lts
• MaxKB versions prior to 2.10.2-lts
• Vendor: 1Panel-dev (MaxKB project)

Discovery Timeline

• 2026-09-21 - CVE CVE-2026-77519 published to the National Vulnerability Database
• 2026-09-21 - Last updated in NVD database

Technical Details for CVE-2026-77519

Vulnerability Analysis

The flaw is an insufficient session expiration issue [CWE-613] in the MCP authentication path of MaxKB. When a client authenticates against /chat/api/mcp, the server resolves the presented secret to an ApplicationApiKey row and checks only that the key is marked active. The parallel /chat/api/open endpoint enforces additional lifecycle controls, including the is_permanent boolean and the expire_time timestamp. Because the MCP handler omits those checks, keys that operators believe are no longer valid remain usable.

An authenticated caller can invoke MCP methods to enumerate the application's published tool metadata and execute tools/call operations. Each interaction persists application_chat and application_chat_record entries, creating durable state under an expired credential. This undermines revocation-by-expiration workflows and leaves audit trails attributed to keys that should no longer be trusted.

Root Cause

The root cause is inconsistent authentication logic across two endpoints that share the same credential type. The MCP entry point queries only secret and active fields on ApplicationApiKey, while the standard chat entry point additionally evaluates is_permanent and expire_time. The divergence permits expired keys to authenticate against MCP while being rejected elsewhere.

Attack Vector

Exploitation requires network access to the MaxKB MCP endpoint and possession of a previously issued, non-permanent application API key. The attacker submits the expired secret to /chat/api/mcp, initializes the MCP session, and issues tool invocations. No user interaction is required, and the privileges required correspond to a low-privileged application-scoped key rather than an administrator account.

No verified public exploit code is available. See the GitHub Security Advisory GHSA-r6g6-69fh-c39q for the maintainer's technical description.

Detection Methods for CVE-2026-77519

Indicators of Compromise

• MCP session initialization events on /chat/api/mcp correlated with ApplicationApiKey records whose expire_time has passed.
• New rows in application_chat and application_chat_record tables tied to non-permanent keys past their configured expiration.
• Successful tools/call invocations from keys that receive rejection responses on /chat/api/open.

Detection Strategies

• Query the MaxKB database to identify ApplicationApiKey entries where is_permanent = false and expire_time < now() that still show recent activity in chat record tables.
• Compare access logs between /chat/api/mcp and /chat/api/open for the same API key identifier; a valid-versus-rejected split indicates the bypass.
• Alert on MCP initialize, tools/list, and tools/call requests originating from keys flagged as expired in the key management inventory.

Monitoring Recommendations

• Forward MaxKB application logs and database audit events to a central SIEM for correlation across endpoints.
• Track creation rates of application_chat_record rows per API key and alert on activity from keys past their expiration timestamp.
• Review MCP endpoint access weekly against the authoritative list of active, non-expired application keys.

How to Mitigate CVE-2026-77519

Immediate Actions Required

• Revoke or deactivate all non-permanent ApplicationApiKey entries whose expire_time has passed by setting active = false in the database.
• Restrict network access to /chat/api/mcp using an upstream reverse proxy or firewall until a patched release is available.
• Rotate application API keys and audit all application_chat_record entries created after the earliest key expiration date.

Patch Information

No fixed version is available as of this review. Monitor the MaxKB GitHub Security Advisory GHSA-r6g6-69fh-c39q for release notes announcing a corrected version and apply the update as soon as it is published.

Workarounds

• Configure all application API keys as permanent only when they are intended for long-term use, and delete rather than expire keys that must be retired.
• Place the MaxKB MCP endpoint behind an authenticating reverse proxy that enforces an independent allowlist of active key identifiers.
• Schedule an automated job that flips active to false for any ApplicationApiKey row past its expire_time, closing the gap between the two endpoints' logic.

# Example: deactivate expired non-permanent MaxKB application API keys
# Run against the MaxKB PostgreSQL database
psql -U maxkb -d maxkb -c "UPDATE application_api_key SET active = false WHERE is_permanent = false AND expire_time < NOW() AND active = true;"