Currently browsing: Security

Overview
This note covers differences in how TLS libraries interpret X.509 Name Constraints. A certificate that one library accepts may be rejected by another. Some of those differences are defects; others follow from behavior that RFC 5280 does not fully specify.
Description
The observed differences concern DNS name comparison, IP address handling, URI-authority parsing, and wildcard matching. These include both implementation defects and behavior not fully specified by RFC 5280.
DNS-name comparison. RFC 5280 requires case-insensitive matching for DNS names. GnuTLS compared some names’ case-sensitivity at the time of reporting (CVE-2026-3833, later fixed in 3.8.13). A distinct Go report concerns case handling in wildcard parent-constraint lookup, not ordinary hostname comparison.
IP address handling. RFC 5280 defines separate IPv4 and IPv6 encodings and does not say whether IPv4-mapped IPv6 addresses should be treated as IPv4. Some libraries treat the two forms as different, so a constraint written for one form may not apply to the other.
URI-authority parsing. RFC 3986 allows optional userinfo before the host. Implementations differ on which host they extract when @, a colon, or a query or fragment is present. OpenSSL merged PR #30319 for an @ in the path, query, or fragment; a separate userinfo-colon report is not covered by that confirmation. Related differences have been reported in other libraries. A well-formed single @ is handled per RFC 3986 by most implementations.
Wildcard matching. RFC 5280 does not define wildcard SAN semantics. Wildcard-related reports include LibreSSL and wolfSSL. pyca/cryptography checked DNS Name Constraints against certificate SANs but not the requested peer name (CVE-2026-34073, fixed in 46.0.6), as described in the linked vendor advisory.
These differences come from independent design choices. Where the RFC is clear, some reports describe defects; where it is silent, disagreement is expected. No single library should be assumed correct for every deployment.
Impact
An attacker would need a trusted signature over chosen certificate fields, a reachable affected validation path, and an application that uses the accepted identity for authorization. Validator disagreement alone does not establish exploitation. Mixed service-mesh, CDN, or enterprise PKI environments may see different results for the same certificate. Detection is difficult because the certificate can be validly signed.
Solution
CERT/CC is coordinating with the affected projects:
* Go’s crypto/x509
* Apple’s Security.framework
* OpenSSL*
* LibreSSL
* pyca/cryptography
* wolfSSL
Operators who need high-assurance Name Constraints should test the validator they currently run against their deployment requirements, apply available updates, and keep leaf certificates to explicit SANs (Subject Alternative Names). A second validator helps only when it uses the same inputs and fails closed. Issuance policy and application-layer allow-lists remain useful complements where libraries differ.
Acknowledgements
Thanks to Oleh Konko for discovering and reporting these issues. This document was prepared with AI assistance by Timur Snoke.
Supporting materials include test corpus v3.0.1 and VENDOR_MATRIX_2026-09-06.json (available to case participants; public links will follow agreed disclosure arrangements).

Overview
Shopware 6.7 contains a stored cross-site scripting (XSS) vulnerability in its media upload functionality that can lead to administrator credential compromise and remote code execution.
Description
Shopware is an open-source e-commerce platform used to build and manage online stores. It provides merchants with customizable product pages, administrative interfaces, plugin functionality, and a media management system that allows users to upload and serve files.
CVE-2026-104937 In affected versions, Shopware’s media upload API accepts HTML files that are later served as text/html without effective Content-Security-Policy or X-Content-Type-Options security headers. An attacker with access to the media upload capability can therefore upload an HTML file with malicious embedded JavaScript, and if an administrator opens the corresponding media URL, the attacker can exfiltrate the administrator’s authentication token and use it to gain unauthorized access to the Shopware Administration API.
Impact
Successful exploitation of this vulnerability could allow an attacker with media creation/upload access to execute arbitrary JavaScript in the administrator browser context, steal valid administrator authentication tokens, and gain privileged access to the Shopware Administration API. If the affected administrator account possesses extension management privileges, an attacker could upload, install, and activate malicious plugins to achieve arbitrary PHP code execution on the underlying OS with the privileges of the Shopware process.
Solution
Unfortunately, the CERT/CC was unable to reach Shopware to coordinate this vulnerability. Until a patch is available, users can reduce risk by limiting access to the media upload functionality to trusted roles or disabling HTML file uploads entirely, preventing attackers from creating malicious browser-interpretable content.
Acknowledgements
Thanks to Deflask13 for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Overview
Thelia versions 2.6.0 and 2.6.1 contain multiple vulnerabilities relating to file management, Smarty templating, module installation, and administrative workflows. Successful exploitation of these issues could enable remote code execution (RCE), server-side template injection (SSTI), stored and reflected cross-site scripting (XSS), unauthorized URL redirection, and other risks that expose both server-side and client-side attack surfaces.
Description
Thelia is an open-source e-commerce platform designed to provide merchants with customizable online storefronts, product management workflows, and administrative functionalities. It utilizes the Smarty template engine and provides administrators with broad control over templates, content, and modules.
CVE-2026-103521 In Thelia v2.6.0, the document upload endpoint properly blocks the upload of executable file types, but the document update endpoint does not perform the same validation. An attacker with administrative Thelia permissions can exploit this vulnerability to upload arbitrary executable files, such as malicious PHP scripts, to achieve remote code execution on the underlying server.
CVE-2026-103522 In Thelia v2.6.0, the store banner upload feature performs insufficient filetype validation that relies exclusively on client-supplied MIME types. An attacker with administrative access can upload a PHP file disguised as an image to bypass validation and achieve remote code execution on the underlying server.
CVE-2026-103523 Thelia v2.6.0 contains an open redirect vulnerability in its address creation workflow. After a user accesses a crafted URL and successfully submits the “Add New Address” form, the application redirects them to the URL specified in the next parameter. Because the application does not validate whether the destination belongs to the same origin or an approved allowlist, an attacker can supply an arbitrary external URL and redirect users to an attacker-controlled website.
CVE-2026-103524 Thelia v2.6.0 is vulnerable to multiple stored XSS vulnerabilities within the administrative interface. User-supplied input is stored without sufficient output encoding or sanitization and is later rendered in the administrator interface and/or the web store’s product pages, allowing arbitrary JavaScript execution when the affected pages are viewed. The vulnerability affects multiple administrative functions including category creation and product creation.
CVE-2026-103526 In Thelia v2.6.0, both the administrative login and forgotten password endpoints return different responses for invalid usernames and incorrect passwords, allowing unauthenticated attackers to enumerate valid administrator accounts. Because the endpoint also lacks rate limiting or other protections against repeated authentication attempts, username enumeration can be performed efficiently at scale.
CVE-2026-103527 Thelia v2.6.0’s Smarty templates (address.html and address-update.html) fail to properly escape double quotes in the next parameter, enabling reflected XSS when an authenticated user visits the malicious link containing attacker‑controlled JavaScript.
CVE-2026-103528 Thelia 2.6.0 uses Smarty for email templates without properly restricting access to dangerous PHP functions. An authenticated administrator can inject malicious Smarty expressions into email templates via the messages configuration interface, and when the template is previewed or rendered, functions such as system(), exec(), file_put_contents(), and file_get_contents() can be executed with the privileges of the web process. This allows arbitrary OS command execution, file read/write operations, and RCE on the server.
CVE-2026-103529 Thelia v2.6.0 permits authenticated administrators to upload and install modules via the ZIP upload function without validating or sandboxing embedded PHP code. An attacker can include malicious PHP code in a module’s install() method which will then be executed upon installation, enabling remote code execution with the privileges of the web server.
CVE-2026-103535 Thelia v2.6.1 contains path traversal and PHP code injection vulnerabilities in its translation editor that can be chained to achieve remote code execution. The item_name parameter, used to build the translation file’s write path, does not sanitize directory traversal sequences such as ../, allowing an authenticated user with UPDATE-level permission on admin.configuration.language to write files outside templates/, including to web-accessible directories. Separately, the translation-writing logic does not escape in user-supplied values, allowing input to break out of the PHP string literal and inject executable code into the translation file. Chained together, these flaws allow a malicious PHP file to be written to a web-accessible path and executed with the web server’s privileges.
CVE-2026-103537 Thelia v2.6.1 contains an absolute path traversal vulnerability in its Smarty template handling that enables SSTI and remote code execution. The checkTemplate() validation restricts relative directory traversal sequences such as ../ but does not reject absolute paths, allowing an authorized user to supply an arbitrary filesystem path as a template. Smarty then loads and compiles the referenced file without an effective security policy, so, depending on filesystem layout and deployment configuration, template code in that file can be executed with the web server’s privileges.
Impact
Several of these vulnerabilities allow authenticated administrative users to achieve arbitrary code execution on the host server. These include insufficient file validation and unsafe upload/update workflows (CVE-2026-103521 and CVE-2026-103522), unrestricted execution of PHP code during module installation (CVE-2026-103529), unsafe template evaluation for email content (CVE-2026-103528), server side template injection via absolute paths (CVE-2026-103537), and flaws in the translation writing process that permit path traversal and PHP injection (CVE-2026-103535). Exploitation of any of these issues can result in complete compromise of the underlying application environment with the privileges of the web server.
Separately, user-supplied content rendered within administrative templates enables stored and reflected XSS. CVE-2026-103524 allows persistent JavaScript execution within the admin interface, while CVE-2026-103527 enables reflected JavaScript injection via unescaped template parameters. These vulnerabilities allow attackers to hijack administrative sessions and perform privileged actions in the browser context of other authenticated users.
The discrepancies in authentication error-handling identified in CVE-2026-103526 allow unauthenticated attackers to easily enumerate valid administrative usernames, increasing the risk and effectiveness of subsequent brute-forcing or authentication-related attacks.
Finally, the open redirect described in CVE-2026-103523 allows attackers to redirect users to external attacker-controlled websites, increasing the effectiveness of phishing or other downstream attacks.
Together, these vulnerabilities facilitate full server takeover for authenticated administrative attackers, and expose avenues for browser-based compromise or credential attacks to both authenticated and unauthenticated attackers.
Solution
Unfortunately, we were unable to coordinate these vulnerabilities with Thelia, and a patch is not yet available. To reduce risk until these issues are remediated, users and organizations should restrict access to Thelia administrative interfaces, disable or tightly limit file-upload and template-editing features, and remove PHP execution permissions from user-writable directories wherever possible. Applying strict reverse-proxy controls such as rate limiting, MIME filtering, and URL allowlisting can further reduce exposure.
Acknowledgements
Thanks to the reporters K08UK0VU, s-b312, DuanNH, Deflask13, LongNBH, and NNPhong (pnn219) from ETC JSC security team for researching and reporting these vulnerabilities. This document was written by Molly Jaconski.

Overview
An Out-of-bounds Write vulnerability in the InsydeH2O IHISI software used by HP PC BIOS can allow a local attacker with OS kernel privileges to perform arbitrary physical memory writes, including writes to System Management RAM (SMRAM). Because the vulnerable code executes in System Management Mode (SMM), successful exploitation can allow an attacker to modify SMM-protected memory and potentially achieve arbitrary code execution in SMM. Depending on the platform’s memory and firmware configuration, the arbitrary physical memory write primitive may also have implications for UEFI firmware update or flash-related operations.
Description
HP PC BIOS is firmware that initializes and manages hardware components during the boot process and provides runtime services to the operating system and provide the ability to update firmware. The affected system uses InsydeH2O Kernel version 5.5 or earlier. The BIOS includes custom HP SMM handlers that execute in System Management Mode (SMM), a highly privileged CPU execution mode that is isolated from the operating system.
CVE-2026-12855: An Out-of-bounds Write vulnerability in the H19WMIHandlerSmm module (GUID f1946499-571b-44c3-9b9c-cc55210b0c02) allows a local attacker with OS kernel privileges to read or write arbitrary physical memory, including SMRAM, through a Software SMI handler.
An attacker with kernel-level privileges can trigger the vulnerable SMM handler by issuing a Software System Management Interrupt (SMI) through I/O port 0xB2 and supplying specially crafted CPU register values. The vulnerable handler does not adequately validate the supplied parameters before performing memory operations, allowing the attacker to influence the physical address and data involved in the operation.
Because the affected handler executes in SMM, the resulting arbitrary physical memory write can target memory regions that are normally inaccessible to software executing outside SMM, including SMRAM. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution in SMM. The ability to affect firmware or ROM contents is platform-dependent and is not assumed as a direct consequence of this vulnerability.
Impact
An attacker with privileged OS kernel access (ring 0) can exploit the vulnerability by raising Software SMI interrupts through I/O port 0xB2 with crafted CPU register values. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution and persistence via modifying SMRAM.
Solution
Users should check HP’s security bulletins to determine whether their system is affected. Insyde advisory is available at https://www.insyde.com/security-pledge/sa-2026009/
Acknowledgements
Thank you to Zhenyu Liu for reporting these vulnerabilities. This document was written by Vijay Sarvepalli.

Overview
Authlib (versions up to and including 1.7.2) contain a signature‑verification bypass in the JSON Web Signature (JWS) general JSON serialization handling. The JsonWebSignature.deserialize_json() function accepts a JWS object with an empty “signatures” array and treats the payload as successfully verified, allowing attackers to supply arbitrary forged content without possessing any key material.
Description
Authlib is a Python library that provides tools for implementing OAuth, OpenID Connect, JWT/JWS/JWE (JSON Web Token / JSON Web Signature / JSON Web Encryption), and other modern authentication and authorization standards. It’s widely used in web applications and microservices to handle token creation, cryptographic validation, and secure communication.
As discussed in CVE-2026-96760, a security flaw in Authlib’s handling of JSON Web Signatures (JWS) makes it possible for an attacker to skip signature verification completely. Normally, a JWS should include at least one valid signature to prove the data hasn’t been tampered with. However, Authlib’s deserialize_json() function mistakenly accepts JWS objects even when the “signatures” section is an empty list. Because the function starts by assuming the signatures are valid and never performs any checks when the list is empty, it ends up treating unsigned data as if it were properly signed. This means an attacker could provide a JWS with no signatures, and Authlib would still treat it as trusted. Both ways of loading a JWS in Authlib are affected:
jws.deserialize_json(“payload”:”…”, “signatures”:[], key=None)
jws.deserialize(‘”payload”:”…”,”signatures”:[]’, key=None)
Impact
An attacker can forge arbitrary authenticated payloads without any signing key or credentials. Systems that rely on Authlib’s JWS verification for authentication, authorization, inter-service message integrity, or signed configuration data may accept attacker‑supplied content as legitimate. Potential attack scenarios inlcude the following:
* Authentication bypass: forged identity or privilege‑escalation claims (e.g., sub=admin).
* Signed message injection between microservices using JWS.
* Forged authorization claims such as scopes, roles, or permissions.
* Integrity bypass in systems relying on signed JWS data.
Solution
The vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing. Users are advised to monitor the project’s GitHub repository for updates and install the latest version of this library once a fix has been released.
Acknowledgements
Thank you to Tong Hoang Gia (uziii2208) and Nguyen Minh Tuan (nguyenminhtuan28) for reporting this vulnerability. This document was written by Bob Kemerer.

Overview
Three cross-site scripting (XSS) vulnerabilities identified in Readwise Reader for Android version 8.7.2 are disclosed. An attacker with the ability to craft malicious documents or metadata can exploit these vulnerabilities by supplying poisoned content that bypasses sanitization. Successful exploitation could allow the attacker to execute arbitrary JavaScript within the application’s WebView context and compromise the confidentiality and integrity of user data, including access to stored documents, credentials, and session tokens.
Description
Readwise Reader from Readwise is designed to provide a unified read-it-later service that helps individuals collect and organize articles, newsletters, videos, and other content of interest into a single reading interface. It is available on multiple platforms including Android and can synchronize content across devices.
CVE-2026-18311: A stored cross-site scripting (XSS) vulnerability in the header rendering component in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via crafted document metadata fields. The header rendering component is impacted due to insufficient HTML escaping of metadata fields such as ‘doc.author’ and ‘doc.title’, which allows malicious scripts to be stored in the user’s library and synchronized to Android devices where they are executed in the WebView context.
CVE-2026-18312: A stored cross-site scripting (XSS) vulnerability in the WebView URL construction logic in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via malicious URL metadata. The WebView URL construction for X (formerly Twitter) video fallback and iOS paywall messages is impacted due to improper escaping of URL metadata before interpolation into href attributes, which allows user-controlled values to break out of the URL structure and inject script elements that are inserted into the DOM via innerHTML.
CVE-2026-18320: A stored cross-site scripting (XSS) vulnerability in the article body sanitization component in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via malicious SVG markup. The sanitize-html configuration is impacted due to a wildcard attribute rule that permits all attributes on SVG and PATH elements, which allows script-capable attributes such as onload and onerror to bypass sanitization.
Impact
An attacker with the ability to create or modify documents accessible to Readwise Reader can supply documents containing malicious metadata or markup that bypasses sanitization and is subsequently stored in users libraries. Because these documents are synchronized to Android devices and rendered within the Reader WebView, each vulnerability enables stored XSS: CVE-2026-18311 and CVE-2026-18312 through poisoned metadata, and CVE-2026-18320 through malicious SVG markup.
Solution
Unfortunately, the vendor could not be reached to coordinate this issue. Users should apply vendor updates as they become available (check Vendor Information section for updates) and keep Readwise Reader updated through the Google Play Store. As of publication, version 8.10.1 includes a patch that addresses the sanitizer-wildcard issue. Additionally, users should exercise caution when adding content from untrusted sources to their reading library and consider manually reviewing document metadata before saving articles to minimize exposure to malicious content.
Acknowledgements
Thanks to Zampier Zago (FUNFACTOR1) for reporting these vulnerabilities. This document was written by Alex Lewis.

Overview
ViewSonic vCast software, which is included in ViewBoard smartboard devices, contains multiple vulnerabilities that an attacker can chained to achieve full device compromise.
Description
ViewSonic ViewBoards are widely used smart display devices (smartboard), typically deoloyed in enterprise and educational environments. vCast is ViewSonic’s proprietary software suite for wireless connection between smartboards, which are Android-based systems, and devices running a client application. Three distinct vulnerabilities, all invoking unauthenticated endpoints, have been identified within the vCast suite.
CVE-2026-82989
vCast’s media streaming service allows a remote attacker to exfiltrate JPEG images of screen content via GET requests to an unauthenticated /snapshot or /screen API endpoint.
CVE-2026-82988
vCast’s Android Package Kit (APK) delivery mechanism allows a remote attacker to trigger unprivileged file installation by providing a malicious APK URL through an unauthenticated download endpoint.
CVE-2026-82987
vCast’s network services allow a remote attacker to inject arbitrary input into service endpoints via HTTP requests to exposed unauthenticated endpoints
Impact
An unauthenticated attacker can chain these vulnerabilities via a shared network to deliver and execute arbitrary code on a vCast-based device without user interaction. Potential device-level impact includes unauthorized access to displayed content, persistent installation and execution of arbitrary applications, and full compromise of the device. Additionally, an exploited device’s connected network may be prone to lateral movement.
Solution
Unfortunately, ViewSonic could not be reached to coordinate the vulnerability. In the meantime, firmware updates should be applied when available. If possible, segment vCast devices onto an isolated, secure network with strict controls, separate from systems containing sensitive data. Network activity should be monitored for suspicious vCast connections.
Acknowledgements
Thank you to Adam Mohammed Zenker for this report. This document was written by Alexander Lewis.

Overview
Door access controllers used on Norwegian Cruise Line (NCL) ships contain an improper authentication vulnerability that permits a replayed unique identifer (UID) from a radio-frequency identification (RFID) device to grant unauthorized entry to areas secured by these controllers.
Description
Norwegian Cruise Line is a global cruise company that operates a modern fleet sailing to destinations worldwide. As described in CVE-2026-75907, the affected card reader authenticates NFC credentials only by checking their static 7-byte UID. A UID is not a secret and does not support cryptographic challenge‑response operations, so it cannot serve as a reliable authentication factor. Although the keycard’s NTAG212 tag contains a memory block with a printed serial number and a value resembling a signature, the reader does not inspect this data during the access-control process. Validation based solely on UID constitutes identification rather than authentication. Because the credential performs no cryptographic exchange and offers no defense against cloning, any device capable of replaying or emulating UIDs can reproduce a functioning keycard.
Impact
An attacker with brief physical proximity to a valid keycard can use an RFID reader to capture the UID without interacting with or altering the card. Once obtained, this UID can be copied to an inexpensive UID‑writable card to create a permanent duplicate credential. The access control readers will accept these forgeries as genuine, granting entry. Depending on logging configuration, the unauthorized entry may be indistinguishable from legitimate use. Because unauthorized access to restricted areas on a cruise vessel can have direct safety implications, this vulnerability presents a significant security risk to both internal operations and guest safety.
Solution
Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Users are encouraged to employ the following methods to help reduce the risk of RFID cloning:
* RFID‑blocking wallets and shielded card-holder sleeves prevent unauthorized scans.
* Placing aluminum foil on both sides of your RFID card can help limit signal transmission by creating a basic Faraday shield.
* When using or storing your card, try to keep a distance of at least 12 inches from other people or devices. Cards operating at 13.56 MHz are usually read at an approximate distance of 2–5 cm (1–2 inches).
Acknowledgements
Thank you to Mark Linton for reporting this vulnerability. This document was written by Bob Kemerer.

Overview
Imprivata Enterprise Access Management (EAM), an authentication and single sign-on platform for enterprise and clinical environments, contains a vulnerability in versions 26.2.6 and below. The product provides no supported mechanism to rotate its RSA key pair after deployment, meaning the same key pair is used indefinitely to generate the appliance’s X.509 certificate.
Description
CVE-2026-82356
Imprivata EAM uses an RSA key pair to generate the X.509 certificate that identifies the appliance to the clinical workstations, Electronic Health Record (EHR) platforms, and shared-device workflows that rely on it for authentication. After reviewing the product documentation and engaging Imprivata support, it was confirmed that no supported mechanism exists to rotate this RSA key pair after deployment.
Using a single RSA key pair indefinitely for certificate generation violates cryptographic best practices. Because the key cannot be rotated, an attacker who obtains the private key retains a valid, trusted appliance identity for as long as the deployment remains in service, with no supported means to revoke or replace it short of redeploying the product.
Impact
An attacker who obtains the private key, for example through backup exfiltration, a hypervisor snapshot, or privileged access to the appliance filesystem, can impersonate the appliance to any endpoint that trusts its certificate. Because Imprivata EAM sits directly in the authentication path, this allows persistent, difficult-to-detect interception of authentication traffic across every application the appliance brokers, including SSO tokens, session assertions, and credentials for EHR and clinical systems. If perfect forward secrecy is not enforced, previously captured traffic can also be decrypted retroactively. Because the key pair cannot be rotated, this access persists until the appliance is redeployed.
Solution
Unfortunately, Imprivata could not be reached to coordinate this case. The vendor is aware of the issue, which they are tracking internally, and is reported to be working toward a resolution. No fix or timeline has been provided at the time of publication.
Until a fix is available, affected users should protect the appliance’s private key by restricting filesystem and administrative access, securing backups and hypervisor snapshots, and enforcing perfect forward secrecy on upstream connections to limit the impact of any key compromise.
Acknowledgements
Thank you to Frank “5y5tem5” Mileto for reporting this issue. This document was written by Alexander Curtis.

Overview
Cinnamon’s Kotaemon (all versions up to v0.12.0) multi‑user chat interface does not verify conversation ownership when loading a conversation. Any authenticated user can read, delete, rename, or overwrite another user’s conversation data by supplying the correct ID. This results in high‑impact confidentiality, integrity, and availability violations.
Description
Cinnamon’s Kotaemon is an open‑source, retrieval‑augmented generation (RAG) based tool that lets you build a chatbot capable of “chatting with your documents”. As discussed in CVE-2026-86867, all versions up to v0.12.0 fail to verify conversation ownership when loading a conversation. In multi‑user mode, each conversation row includes a user field that identifies its owner. The four affected handlers, select_conv, delete_conv, rename_conv, and persist_chat_suggestions, query conversations using select(Conversation).where(Conversation.id == conversation_id)
No predicate is included to ensure Conversation.user == user_id. As a result, any authenticated user can operate on conversations they do not own.
Impacted operations include:
* select_conv – reads the full chat transcript, RAG retrieval history (verbatim excerpts from uploaded private documents), plot history, and suggestion data belonging to another user.
* delete_conv – permanently deletes a conversation.
* rename_conv – renames a conversation.
* persist_chat_suggestions – overwrites a chat suggestion list.
Although select_conv includes an ownership check for the selected (file‑picker) field, all sensitive payloads (chat history, retrieval history, plot history) are returned unconditionally. The system trusts user‑controlled identifiers for authorization. Attackers require only an authenticated account on the instance and a victim conversation UUID (Universally Unique Identifier). Affected users’ public conversations appear in the global conversation browser, exposing their UUIDs. If a conversation is later set to private, the UUID remains unchanged and still valid. Similar direct calls to delete_conv, rename_conv, and persist_chat_suggestions allow deletion, renaming, or content overwriting. No elevated privileges are required; any authenticated user account is sufficient.
Impact
Full chat transcripts and RAG retrieval history for any conversation are disclosed. For Kotaemon’s primary deployment use case (enterprise document Q&A over proprietary knowledge bases such as legal briefs, financial reports, research papers, and internal strategy documents), the retrieval_history field contains verbatim excerpts from those private documents. A single IDOR (Insecure Direct Object Reference) read may expose more sensitive content than what the affected user intended to share with any other party.
Conversations can be renamed or have their suggestion state overwritten. While the impact of renaming is limited, the persist_chat_suggestions path allows an attacker to inject attacker-controlled prompt suggestions into the victim’s conversation UI, a potential vector for prompt injection if the AI model acts on suggested prompts.
delete_conv permanently destroys any conversation with a single call. An attacker can systematically delete all conversations of a target user or across all users if they have access to the UUIDs. There is no recycle bin or soft-delete in the Kotaemon data model for conversations.
Because retrieval_history contains verbatim document chunks (not just file names), the attacker does not need separate file-read permissions to access the content of documents indexed into the victim’s knowledge base. The chat conversation becomes a side-channel through which document content leaks.
Solution
Unfortunately, the vendor could not be reached to coordinate this vulnerability. While an official patch is not available at this time, please refer to the vendor’s web site and GitHub repository (listed in the references below) for future updates.
https://github.com/Cinnamon/kotaemon
https://cinnamon.github.io/kotaemon/
Acknowledgements
Thank you to Louis Sanchez for reporting this vulnerability. This document was written by Bob Kemerer.