MaxKB increments the chat share link endpoint to accept any authenticated token and any chat identifier; the implementation verifies that a conversation exists, but it does not confirm ownership of the conversation or administrator scope of the caller. This omission enables an attacker who possesses a valid chat token and knows a victim’s chat identifier to create an unauthenticated public share link for that conversation. Once published, the conversation content becomes accessible to anyone, and the associated file attachments become retrievable via a PublicFileAccess state that offers no revocation path. The vulnerability therefore leads to a breach of confidentiality for private discussions and associated media, and may expose sensitive corporate information to the public. The weakness aligns with access control failure (CWE‑285) and authorization bypass through a user‑controlled key (CWE‑639).

The issue affects the open‑source AI assistant MaxKB, version 2.7.0 through 2.10.4‑lts, released by 1Panel‑dev. All deployments of these releases that expose the chat sharing endpoint are vulnerable.

The CVSS score of 6.5 classifies the vulnerability as medium severity, and the EPSS score is currently unavailable; the lack of a KEV listing suggests no widespread active exploitation is reported. However, the attack vector requires only an authenticated chat token, which can be acquired by legitimate users of the application. With a known victim chat identifier, an attacker can directly issue the request to POST /chat/api/.../share_chat, creating a public link without any further credentials. The exploit is straightforward and does not need privilege escalation or complex setup, so the risk remains significant for organizations that rely on confidential conversation data. Until an official patch is released, the vulnerability persists with no built‑in revocation mechanism for the published links or files.