MaxKB CVE-2026-77519

Exploitation requires the attacker to already possess a valid ApplicationApiKey secret that was created as NON-permanent (is_permanent=false) and has passed its expire_time - the endpoint still accepts it because /chat/api/mcp checks only secret + active status. The target MaxKB instance (version 2.10.2-lts or earlier) must expose the /chat/api/mcp endpoint and have a published application with tools. Limiting factors: the attacker must obtain the key secret (leaked, retained, or previously delegated), the key must still be marked active, and the same key is already rejected by the standard /chat/api/open path - so this is a credential-lifecycle bypass, not unauthenticated access. No user interaction is required.

This is a genuine but bounded access-control weakness, not a top-priority emergency. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N = 5.4 Medium) is internally consistent with the description: network-reachable MCP endpoint, low complexity, but PR:L because the attacker must already possess a previously-issued, still-active ApplicationApiKey secret. No EPSS score, no CISA KEV listing, and no public POC are present in the supplied intelligence, so exploitation status is 'no public exploit identified at time of analysis.' The core issue (CWE-613 insufficient session/credential expiration) means the /chat/api/mcp path authenticates on secret+active only, ignoring the is_permanent and expire_time checks that /chat/api/open enforces - so an expired non-permanent key keeps working on MCP. The impact is real (tool metadata disclosure, tools/call invocation, durable chat state) but self-limited: it requires a leaked/retained valid-but-expired key against a niche self-hosted product. No fixed version was available as of this review, which modestly raises operational risk for deployers, but the low CVSS confidentiality/integrity (C:L/I:L, A:N) and gated preconditions keep real-world urgency moderate.

An attacker who obtained a MaxKB ApplicationApiKey secret that was issued as non-permanent and has since passed its expire_time - a key that would now be rejected by the standard /chat/api/open endpoint - sends it to /chat/api/mcp instead. Because that path checks only the secret and active flag, the endpoint initializes, exposes the published application's tool metadata, and permits tools/call, letting the attacker enumerate tools and create durable application_chat/application_chat_record records. No public exploit code is identified in the supplied data.