Description

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 is_permanent and expire_time 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 application_chat and application_chat_record state even though /chat/api/open rejects the same key. No fixed version is available as of this review.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-21T21:17:10.633Z",
  "pubdate": "2026-09-21T21:17:10.633Z",
  "executiveSummary": "MaxKB versions 2.10.2-lts and earlier are susceptible to an authentication bypass vulnerability within the /chat/api/mcp endpoint. This vulnerability arises from inconsistent validation logic regarding ApplicationApiKey objects. While standard chat API endpoints enforce strict expiration and permanency constraints, the MCP API path fails to validate these parameters, relying solely on the secret value and active status. Consequently, an adversary possessing a previously valid but expired non-permanent API key can circumvent access controls.\nThe impact includes unauthorized access to sensitive tool metadata, the ability to invoke arbitrary tools, and the creation of durable chat states within the application. This bypass effectively ignores the security policies intended to terminate access for non-permanent keys, leading to potential data exposure and unauthorized system interaction. The vulnerability poses a significant risk to enterprises relying on these keys for controlled AI assistant integration, as it allows persistent access beyond the intended lifecycle of the credential. No patch is currently available, necessitating immediate compensatory controls to restrict access to the affected endpoint.",
  "technicalDetails": "The vulnerability resides in the authentication logic governing the /chat/api/mcp endpoint in MaxKB versions 2.10.2-lts and earlier. The root cause is an inconsistent implementation of the ApplicationApiKey validation process across different API modules. Whereas the standard /chat/api/open endpoint correctly verifies the full set of constraints—specifically checking the is_permanent boolean and the expire_time timestamp—the /chat/api/mcp implementation performs a truncated validation. This faulty implementation only verifies that the provided key exists in the database and is marked as active.\nThis logic flaw enables an attacker to leverage expired credentials that have not been manually toggled to an inactive state. The exploitation flow is as follows: first, the attacker identifies a non-permanent ApplicationApiKey that was previously authorized but has passed its expiration window. Second, the attacker submits this key in the header/authentication context of a request directed to /chat/api/mcp. Third, the application's MCP handler skips the logic responsible for checking the expiration time and the permanent status flag, treating the key as valid based solely on its status field.\nOnce authenticated, the attacker gains the ability to interact with the Model Context Protocol (MCP) interface. This grants the attacker several capabilities, including: enumerating published application tool metadata, invoking tools/call methods, and initiating persistent interactions. These actions result in the creation of durable application_chat and application_chat_record state entries within the MaxKB backend. Effectively, the attacker can manipulate the assistant's context and trigger backend operations that should be inaccessible to expired credentials.\nThe attack is highly effective because it leverages legitimate but expired keys, allowing for stealthy persistence. Because the MCP endpoint does not share the same rigid validation constraints as the standard chat API, the exposure is significant for any environment that relies on time-bound access for external AI agents or third-party integrations. The lack of validation against expiration parameters essentially creates a 'zombie' access state where revoked or expired keys remain functional for specific, highly privileged API paths. There is no requirement for high-level administrative privileges to exploit this; only a valid, albeit expired, key is required to bypass the security middleware."
}