MaxKB EUVD-2026-84158

Exploitation requires (1) possession of any valid chat token for the MaxKB instance - trivially obtainable when the target application is exposed as a public chat endpoint, harder if the application requires authentication; and (2) knowledge of a specific victim's chat_id, which is the main limiting factor and drives the CVSS AC:H rating since chat_ids are not enumerable in the general case. The vulnerable operation is the POST /chat/api/{application_id}/chat/{chat_id}/share_chat endpoint on MaxKB versions 2.7.0 through 2.10.4-lts; no non-default configuration toggle is needed - the missing ownership check is present in the default code path. There is no user interaction from the victim and no fixed release to upgrade to, and because there is no revoke path, once a malicious ChatShareLink/PublicFileAccess is created the exposure cannot be undone through the product.

This is a broken-authorization (CWE-285) / IDOR flaw where the share_chat endpoint confirms a conversation exists but never checks that it belongs to the caller's chat_user_id or the application bound to the caller's token. The vendor CVSS 6.5 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) is internally consistent: network vector, high complexity (attacker must already know a valid victim chat_id, which is non-guessable/non-enumerable in the general case), and a confidentiality-dominant impact since the primary result is disclosure of a victim's private conversation and associated files. Note a tension in PR:N: the description requires the attacker to hold 'any chat token,' but because MaxKB applications can be exposed as public chat endpoints, such a token is often a low/zero-cost prerequisite - PR:N is defensible on that basis but should be verified against the specific deployment (public vs. authenticated application). No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided intelligence, so exploitation status is 'no public exploit identified at time of analysis' - the 6.5 rating reflects a genuine confidentiality/data-exposure issue rather than a mass-exploitable RCE. Two factors elevate real-world concern beyond the moderate score: there is NO fixed version available as of this review, and there is NO revoke path for the malicious ChatShareLink/PublicFileAccess state once created, making the exposure persistent. Aggravating this, the created share link and file access are themselves unauthenticated, so downstream consumption of the leaked data requires no credentials at all.

An attacker who has obtained a valid chat token (e.g., by interacting with a publicly exposed MaxKB application) and who has learned or captured a victim's chat_id issues a POST to /chat/api/{application_id}/chat/{chat_id}/share_chat for a conversation they do not own. The server creates a public, unauthenticated ChatShareLink and PublicFileAccess state, letting the attacker (and anyone with the link) read the victim's private conversation and download associated files without credentials - with no way for defenders to revoke the link. No public proof-of-concept is identified; the high attack complexity comes from needing a known victim chat_id.