CVE-2026-77519: MaxKB: Expired application API keys remain usable on `/chat/api/mcp`
MaxKB is an open-source AI assistant for enterprise. In 2.10.2-lts and earlier, the /chat/api/mcp authentication path looks up an ApplicationApiKey using only its secret and active status, without enforcing the ispermanent and expiretime checks used by the standard chat API. A previously valid, non-permanent application key that remains active after expiration can initialize the MCP endpoint, list the published application's tool metadata, invoke tools/call, and create durable applicationchat and applicationchatrecord state even though /chat/api/open rejects the same key. No fixed version is available as of this review.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Instances running MaxKB 2.10.2-lts or earlier are exposed if a non-permanent application API key has expired but is still marked active. The affected behavior is specific to the /chat/api/mcp authentication path.
What does an attacker need to exploit it?
An attacker needs the secret value of a previously valid, non-permanent application API key that has expired and remains active. No user interaction is required.
What can someone do with an expired key on the affected endpoint?
They can initialize the MCP endpoint, view the published application's tool metadata, invoke tools through tools/call, and create persistent application_chat and application_chat_record state. The same expired key is rejected by /chat/api/open.
What can be done while no fixed version is available?
Identify expired non-permanent application API keys that remain active and deactivate them. Replace or rotate any keys whose secret may have been exposed, and restrict access to /chat/api/mcp where operationally possible.