An ownership check is missing from four multi-user chat handlers through v0.12.0. Limit account access and review cross-user conversation activity while awaiting a verified fix.2026-09-30T18:53:56.040Z3 min2026AIappsec
3 min read
Read format

Kotaemon Lets Signed-In Users Read and Delete Other Users' Chats

An ownership check is missing from four multi-user chat handlers through v0.12.0. Limit account access and review cross-user conversation activity while awaiting a verified fix.

By Justin Howe
Illustrated document-chat folio with an open clasp and the Kotaemon name.

A signed-in Kotaemon user with another person’s conversation ID can read that person’s chat and retrieval history, or delete the conversation. CERT/CC’s September 23 vulnerability note covers multi-user installations through v0.12.0. In a document Q&A instance with separate access to internal material, the retrieval history can contain verbatim excerpts from uploaded private documents.

Public conversations appear in the global conversation browser, exposing their IDs; changing one to private leaves its ID usable. CERT/CC credits researcher Louis Sanchez with the report. Its note says an official patch was unavailable at publication and the vendor could not be reached for coordination. Keep broad multi-user access restricted until you can verify an owner-checking fix on the version you deploy.

Four handlers trust conversation IDs

In the CVE Program record for CVE-2026-86867, the affected handlers are in libs/ktem/ktem/pages/chat/control.py. CERT/CC names select_conv, delete_conv, rename_conv, and persist_chat_suggestions: each looks up a Conversation by its ID without matching Conversation.user to the signed-in user_id. As CERT/CC puts it, “any authenticated user can operate on conversations they do not own.” The affected deployment mode is multi-user; the attacker needs an account and a conversation UUID, not elevated privilege.

select_conv returns chat transcripts, retrieval history with document excerpts, plot history, and suggestion data. A check inside that handler protects the selected file-picker field, while the other sensitive payloads are returned. The other handlers can permanently delete a conversation, rename it, or overwrite its suggested prompts. CERT/CC describes malicious suggestions as a potential prompt-injection route if a model acts on them; the demonstrated result here is control of the suggestion list.

Scope by account and version

Identify Kotaemon instances in multi-user mode running v0.12.0 or earlier. List the accounts allowed to sign in and the conversations containing sensitive retrieval history. A previously public conversation deserves attention even if its visibility has since changed: its UUID persists. Treat a private setting as a display choice until access is enforced against the owner on every affected handler.

For triage, correlate signed-in account IDs with conversation UUIDs and Conversation.user in any application request telemetry you actually retain. Investigate a cross-owner read, deletion, rename, or suggestion write as unauthorized access. Where that account-to-conversation record is unavailable, scope potential exposure from the account list and affected conversations rather than declaring a clean history. Review recent backups before making changes that could disturb evidence or recovery options.

CERT/CC describes transcript disclosure and permanent deletion. A CISA enrichment attached to the CVE carries a CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N vector, whose confidentiality and availability fields differ from those described outcomes. Use the documented handler behavior to plan the response.

Restrict access until ownership holds

Suspend enrollment of untrusted accounts, remove unneeded accounts from multi-user instances, and allow only mutually trusted users to reach them while an owner-checking release is evaluated. Limit network access to the Kotaemon service for those users. These steps narrow who can invoke the vulnerable handlers; they do not repair authorization for any remaining signed-in user. Preserve conversation backups and investigate suspect cross-owner activity before relying on a new release to secure an affected instance.

After an owner-checking change is installed, verify it on a non-sensitive test instance using two accounts with separate conversations: each account should access its own conversation, while cross-owner reads and changes are denied by the server across all four handlers. Record the deployed version and the observed denial. Until that result is available, a privacy toggle and a hard-to-guess UUID offer no dependable separation between users of the same Kotaemon instance.

Primary sources

Continue reading

Article figurePinch or double-tap to zoom, then drag to pan.