Kotaemon CVE-2026-82281

Requires a multi-user Kotaemon deployment (through 0.12.0) where the attacker has an active session and can invoke the conversation handlers in control.py. The concrete prerequisite is possession of a valid target conversation identifier: the attacker supplies an arbitrary conversation ID to select_conv, delete_conv, rename_conv, or on_set_public_conversation, which perform no ownership check. Limiting factors: exploitation is meaningless on single-user instances; the attacker must know or enumerate valid conversation IDs (reflected in the CVSS AC:H/AT:P metrics), so the difficulty hinges on whether identifiers are sequential/predictable or unguessable UUIDs - a detail not confirmed in the available data.

Signals are mixed and should temper the headline 9.1. The supplied CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N) itself encodes friction - AC:H and AT:P indicate meaningful attack requirements, most plausibly the need to know or enumerate valid conversation identifiers, which contradicts a trivially-exploitable reading. PR:N is also questionable: the vulnerability is fundamentally cross-user, so it only matters in a multi-user/authenticated deployment where the attacker is a logged-in user (see assessed vector, which uses PR:L). No EPSS score was provided, it is not in CISA KEV, and no POC is referenced, so there is no evidence of active or widespread exploitation. Realistic priority is moderate-to-high for organizations running multi-tenant Kotaemon with sensitive documents, and low for single-user or trusted-team deployments. Data gap: identifier format (sequential vs. UUID) is not stated and materially changes exploitability - verify against the deployment.

A registered user on a shared Kotaemon instance opens the chat UI and issues select_conv/rename_conv/delete_conv requests substituting conversation identifiers other than their own. Because ownership is never validated, the server returns or mutates another user's conversation, exposing their chat history or destroying/renaming their threads. No POC is published, and the AC:H/AT:P metrics imply the attacker must first obtain or guess valid conversation IDs.