Currently browsing: Technology

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.

Overview
Vendor-signed UEFI Shell applications may allow an attacker to bypass Secure Boot protections by abusing commands such as mm (Memory Modify). On systems that trust the affected vendor’s certificate or include the application’s Authenticode hash in the UEFI Authorized Signature Database (DB), an attacker with sufficient access could use the application’s direct memory-access capabilities to disable or circumvent Secure Boot enforcement and execute untrusted UEFI code. To mitigate this risk, system administrators should apply available firmware and software updates from affected hardware vendors.
Description
The Unified Extensible Firmware Interface (UEFI) standard defines the firmware architecture used to initialize hardware and transfer control to modern operating systems during system startup. On systems with Secure Boot enabled, UEFI applications and drivers must be cryptographically signed and verified before their execution. Trust for these signatures is managed through several databases, including the Authorized Signature Database (DB), which commonly contains certificates from original equipment manufacturer (OEM) vendors, operating system authorities, and other supply-chain partners in the UEFI ecosystem.
There are multiple implementations of the UEFI Shell, and OEM vendors typically sign the implementation that they distribute. Some UEFI Shell implementations expose built-in capabilities for directly manipulating system memory and interacting with the UEFI environment. Because the Shell is vendor-signed and therefore permitted to execute with Secure Boot enabled, an attacker who can launch a vulnerable Shell can use these capabilities to modify the protected pre-boot state and potentially load or execute untrusted UEFI code. This creates a security boundary violation: Secure Boot permits execution of the signed Shell, while the Shell itself provides the primitives necessary to circumvent the integrity protections Secure Boot is intended to enforce. As a result, an attacker can potentially compromise the pre-boot environment despite Secure Boot being enabled.
Researchers from Binarly identified multiple UEFI Shell applications vulnerable to this type of abuse. Note that Eclypsium has also identified and reported some such signed UEFI shell binaries that expose high-privileged capabilities that can be used to bypass Secure Boot. To neutralize the risk, the affected binaries will need to be added to vendor-specific DBX revocation lists to prevent them from executing on the target systems.

Impacted UEFI Applications
[Vendor, Application and vulnerable function
Authenticode SHA hash
SHA256 file hash]

Acer `UEFI shell` mm,dmpstore
805f72afd179fe67ceee14c76f92c8f76cad23130fa075d1d5678e242a0d3d52
f52b8dbffaa9b57910b3c369c384f7ccfe8d696e05e7a8a7f0da0db5540949c2
Acer `UEFI shell` mm,dmpstore
b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
b3a999b7fad3c8cfeff88ab8b29d261b241689c857e13414a9ae0e9f84a10a5f
Acer `UEFI shell` mm,dmpstore
a249bd3044e9aa5d4e2dfa9f94b0ffa437f4ebf3f39d57c9f276b3b9988b2b0b
77a36a8f035dfb1fdf5170f396e29a8b3e4b93558317a51eafd5be9c5ead5ef9
Acer `UEFI shell` mm,dmpstore
6ce33e23b21bfa1ce143fdadf55d00340a9fa3215dd73e31fa6307d5733b8841
77019c81bdc1accbd0c99b20b12edcd578dabc4cac4fa66934465f20c1c0aa2c
Acer `UEFI shell` mm,dmpstore
ad30615c1ad7da2e47dcf28a571dc62b9c034c6ade434de8daa35965062f3a7f
c0194c555db9f5f7080c3344db028f44af522bac63c13d764ff416ac244e3c08
Acer `UEFI shell` mm,dmpstore
b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
b2e0afb2844241479db7d19398c837049fb4c7f08560963d616b3c95b1d382e2
Dell `UEFI shell` mm,dmpstore
3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7
2bfbec41b536b248a3e0a28dddfbcd57f774f03b72028cec91def28b2dcffc2f
Dell `UEFI shell` mm,dmpstore
3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7
5cdf3d75c0ec0800b9692aedef19527f06eb4a16fdda586f5527350e2f6a40ad
Dell `UEFI shell` mm,dmpstore
3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7
6ccd1ee8b067d02c083e73a0c2e18712d55b78bd99fec392daf702a147ce6d41
Dell `UEFI shell` mm,dmpstore
3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7
a632de93bfd10d89326db2171673bd246cd6533dcdf8e5f6de85949855695e78
Dell `UEFI shell` mm,dmpstore
113a80eac88190d96832cd50c9ea8de3bd6e08d8bcae2e6cea738eb73f64c5d7
d2ed7a747c5b3e5c83319e5d186ec602918fbf0651d059699a3c68f609d25cf2
Dell `UEFI shell` mm,dmpstore
3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7
ec23a874c3c0e852becc8fa4010c60e5f8922fe671f5351cf8a976da59a01f86
Dell `UEFI shell` mm,dmpstore
3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7
f75456cd23e492a078b3a81ffbbe262a1511ac9480c4f397e3d4be3b4ce5a455
Dell `UEFI shell` mm,dmpstore
113a80eac88190d96832cd50c9ea8de3bd6e08d8bcae2e6cea738eb73f64c5d7
f89cdf53d55d70fea31723f52d6b816937aebe2a2212ddcde7e3732e39c1fbfe
Dell `UEFI shell` mm,dmpstore
3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7
fb68dfe907b99c23e97f98518d5e1079312d3981df036bb64d4682fe6fff83b5
Dell `UEFI shell` mm,dmpstore
b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
20cca70af9e3b4e5640d52840c84a1968d5be6ca881b393bc236f8d349c225ce
Dell `UEFI shell` mm,dmpstore
b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
d4e7b11a30edd1f89c4fa1664eff98907202f15bc59c2cdfddf345a09ffbb1d4
Eurosoft `UEFI shell` mm,dmpstore
e9d873cbcede3634e0a4b3644b51e1c8a0a048272992c738513ebc96cd3e3360
1e918f170a796b4b0b1400bb9bdae75be1cf86705c2d0fc8fb9dd0c5016b933b
Framework `UEFI shell` mm,dmpstore
2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416
51401e93b940dec1a4391303fb6e390194b90113a8f7da6e711253c82a02b8e4
Framework `UEFI shell` mm,dmpstore
2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416
7e1dbf3e72b8c3c4967364f49da0cd5e3c09d921086d60ac2a493b55818cd7cf
Framework `UEFI shell` mm,dmpstore
665b26ad26c1d739720a2793acaefbd8b6c16a599b48dcdbf594640522744483
0e03ff927005c70636273a4b9287683a821082f952dc7c9beda1a4fc911dddce
Getac `UEFI shell` mm,dmpstore
09d895bb03bdac3188ef61b09ab72b99492cfd0b785cbc3eb2eb75657a2f9fa0
380a387b53a0ca586fe32eb1459b036f5dc178b26b2b0ec618c598eb4714d1fe
Lenovo `UEFI shell` mm,dmpstore
b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
1f2c450bbf287e35747561723079c166aed3eddfc509b26c18dd8e19417f1838
MinisForum `UEFI shell` mm,dmpstore
5e7b3650103fb1c15e610e2381351d9b36546f260284535ed5774adf7532f633
9de8a0194052063ce541b34fbd451071ea3051914fc234b6d691d006f0a0f994
Msi `UEFI shell` mm,dmpstore
61ee9a23c366a102ceb34c78af7816413769791658cdb668b02cb81ec94f7c70
da5f4aa2008e6e26c3553b3dee4cf835ceac88820658693704cea35f62733ce3
Seagate `UEFI shell` mm,dmpstore
665b26ad26c1d739720a2793acaefbd8b6c16a599b48dcdbf594640522744483
53d87f3b7729fe82b47606a85e606c30d2bb61d3da3f01caef17eb7164bca261
Uniwill `UEFI shell` mm,dmpstore
55682bec887134a2ccaa2cd5458cd3fe6395ea93bb88c9dc541806428b14fc66
d4f05110f4bb55677426067db88f61595dc1831659ba43a5770268b73d4eb479
Unknown `UEFI shell` mm,dmpstore
044f80d53ecea7dc108bbf54a89f431d22aa4ebd9b43da3a2abba75bede8b431
67bf47b637bff078e6eae9afbae26b82c701739ae7fcd8e7d282b1f2901f9634
Unknown `UEFI shell` mm,dmpstore
81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d669087
8e61f24a72c3138bde4b63766ceee1ce1a70a00046cc6867c61520084d884346
Unknown `UEFI shell` mm,dmpstore
81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d669087
88fbb6425f43eb54194dbb607141e65adc2d1e7e0d33b6bfe762504547024942

Impact
This vulnerability impacts systems that trust the compromised vendor certificate within their UEFI Authorized Signature Database (DB) or those that include the affected application’s Authenticode hash in the DB. An attacker with physical access or administrative privileges can leverage these trusted components to bypass Secure Boot and execute arbitrary code during the pre-boot phase. Because this execution occurs before the operating system and endpoint security products initialize, the malicious code can achieve persistent platform compromise, including the loading of unsigned kernel components, while remaining entirely invisible to standard security controls and Endpoint Detection and Response (EDR) solutions.
Solution
Apply the latest firmware and software updates from your hardware vendor. These updates are expected to replace vulnerable UEFI applications with secure versions. Update and verify the UEFI DBX on the affected systems to revoke trust in vulnerable binaries or, where necessary, the certificates used to sign them, preventing the affected binaries from executing during boot.
Acknowledgements
Thanks to Binarly for researching and reporting this vulnerability. Thanks to Eclypsium researchers continued work on UEFI risks from such signed applications. This document was written by Vijay Sarvepalli.

Overview
Dokploy versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch, are vulnerable to OS command injection during the backup creation and restoration processes. The vulnerability stems from unsanitized shell command construction that can allow an attacker to escalate privileges and lead to full compromise of the target device.
Description
Dokploy is an open-source Platform as a Service solution for deploying applications and databases on self-hosted servers. Dokploy allows authenticated users to create and schedule database backups and restore previously created backups. These backup operations are executed by the Dokploy process, which runs with root privileges by default.
Dokploy is vulnerable to OS command injection in its database backup creation and restoration functionality due to insufficient sanitization of user-controlled input before it is incorporated into shell commands. The vulnerable backup functionality constructs database-specific shell commands that directly interpolate a user-supplied database name, while the restore functionality incorporates a user-supplied backupFile value into a shell command. Both operations ultimately pass the resulting command to a shell execution helper that invokes /bin/bash as a child of the Dokploy process, without shell escaping or restrictions on shell metacharacters.
The affected parameters are exposed through tRPC procedures that only validate that the supplied values are non-empty strings. Consequently, authenticated users with permission to perform database backups can supply shell metacharacters that are interpreted by /bin/bash, resulting in arbitrary command execution on the Dokploy host with the root privileges of the Dokploy server process.
Impact
An attacker with authenticated Dokploy account with backup permission (granted by default for database services) can execute arbitrary commands as root (default configuration) on the Dokploy host. Successful exploitation provides full control of the host, including persistent read/write access to the target server’s filesystem and the ability to steal private credentials stored for other tenants managed by the same Dokploy instance.
The vulnerability affects all five database types supported by Dokploy: PostgreSQL, MySQL, MariaDB, MongoDB, and LibSQL. Exploitation was confirmed against versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch available on GitHub.
Solution
Unfortunately, Dokploy could not be reached to coordinate this vulnerability; however, the issue has been patched in Dokploy versions 0.29.13 and beyond. The CERT/CC recommends users update immediately. Database administrators or general operators unable to update should mitigate potential attacks by turning off default backup permissions, and restricting these permissions only to necessary users and roles.
Acknowledgements
Thanks to Muhammadjon Ahmadjonov for reporting this vulnerability. This document was written by Alex Lewis.

Overview
Two vulnerabilities in MLflow’s dspy and statsmodels model flavors allow unauthorized pickle deserialization executions despite a safety control. Specifically, the dspy flavor conditionally applies the control based on the model path’s file extension, and the statsmodels flavor does not apply the control.
Description
MLflow is an open-source platform for managing machine learning lifecycles, including model packaging, versioning, and deployment. “Flavors” refer to the specialized frameworks through which supported models are stored and loaded. In response to previous vulnerability concerns, MLflow implemented the MLFLOW_ALLOW_PICKLE_DESERIALIZATION safety control to block and disable executing any pickle deserialization and subsequent loads per the user’s choice.
When loading models through mlflow.pyfunc.load_model(model), users must specify a model flavor and path in an MLmodel file. With the dspy flavor, MLflow checks the value of MLFLOW_ALLOW_PICKLE_DESERIALIZATION, and whether the specified model path ends in .pkl. A model path that does not end in .pkl (even if the file is actually a pickle file), will route to a separate branch for pickle deserialization, bypassing the safety control. However, when loading through the statsmodels flavor, there is no check for MLFLOW_ALLOW_PICKLE_DESERIALIZATION at all.
These vulnerabilities are tracked as CVE-2026-96804 and CVE-2026-96775, respectively.
Impact
Exploitation of these vulnerabilities allow for arbitrary remote code execution through a malicious pickle-loaded payload, regardless of a user explicitly disallowing pickle serialization, through vulnerable flavor specifications in the MLmodel configuration file. The attack path requires write access to any location from which a user obtains MLflow models. This vulnerability was confirmed against MLflow 3.12.0.
Solution
MLFlow could not be reached to coordinate these vulnerabilities; however, the statsmodels flavor was patched in versions >= 3.15.0. Users should upgrade immediately. Until a further fix remedying the dspy flavor vulnerability is available, MLflow users who wish to block pickle deserialization and loads should avoid loading any models via the dspy flavor.
Acknowledgements
Thanks to Prasanna Dabi for reporting this vulnerability. This document was written by Alex Lewis.

Overview
A vulnerability exists in Sentry Seer when the system is configured to automatically hand issues to a coding agent for remediation. Successful exploitation results in arbitrary code execution within the coding‑agent environment and access to connected source repositories. This vulnerability is tracked as CVE-2026-90999.
Description
Sentry is a software error‑monitoring and performance‑tracking platform used by developers to detect, diagnose, and understand issues in their applications. It collects telemetry such as exceptions, stack traces, logs, and performance data from applications. Built into Sentry, Seer acts as an automated debugging assistant that converts telemetry into actionable remediation steps and can hand off issues to an integrated coding agent to propose code fixes.
Because Sentry front-end projects commonly expose a public DSN (Data Source Name) to allow browsers to submit this telemetry, an attacker can craft and submit malicious events through this public endpoint. When Seer is enabled to automatically pass issues to a coding agent, these attacker-supplied events can traverse multiple trust boundaries. Ultimately, malicious event fields propagate through Seer’s analysis pipeline, transforming into untrusted instructions that the privileged coding agent may execute.
The vulnerable workflow is as follows:
* Sentry ingests attacker‑generated exception events submitted through the public DSN.
* Seer evaluates whether the event represents an issue eligible for automated remediation.
* Seer generates a root‑cause analysis that uses attacker-controlled event fields, including exception messages, stack traces, source context, and breadcrumbs.
* The generated analysis is embedded directly into the initial prompt provided to the coding agent.
* The coding agent interprets the fabricated analysis as a legitimate description of the victim’s codebase.
* During its investigation, the coding agent downloads and executes a package controlled by the attacker.
* The package executes within the coding‑agent environment prior to any human review of a pull request.
Impact
Successful exploitation may allow arbitrary code execution in the coding‑agent environment that processes the affected repository.
Solution
At the time of this writing, no vendor‑supplied patch information has been provided. Mitigations may include disabling automated remediation flows, restricting coding‑agent package installation, or disabling Seer handoff until a fix is available. Additional defensive filtering of telemetry content before Seer analysis may also reduce risk.
Acknowledgements
Thank you to Nikita Benkovich and Vitalii Valkov, agyn for reporting this vulnerability. This document was written by Bob Kemerer.

Overview
An out-of-bounds (OOB) memory access vulnerability involving unchecked array indexing has been identified in the exllamav3_ext compute unified device architecture (CUDA) extension. Successful exploitation can lead to an immediate denial of service or application instability. This vulnerability is tracked as CVE-2026-84286.
Description
An OOB memory access vulnerability exists in the exllamav3_ext module due to insufficient input validation.
When the kernel parameter K is set to 0 in a crafted input, the extension generates a negative array index, resulting in a CUDA illegal memory access.s. The root cause is a missing bounds check in the kernel-table dispatch process. The checkpoint-derived block index (cbi) is used to access a fixed 24-entry array without confirming that either K or cbi fall within safe limits.
Impact
Primary impacts include Denial of Service (DoS) through process crashes and potential unstable execution states within applications utilizing the library.
Solution
The vendor has addressed this vulnerability in the main repository. Users are advised to update their installations or apply the fix from the merged pull request: https://github.com/turboderp-org/exllamav3/pull/310.
Supply chain
Downstream projects utilizing this library are indirectly exposed to this vulnerability. According to the ExLlamaV3 Dependency Graph, there are 49 total dependencies currently tracking this repository. Notable downstream projects directly affected by this supply chain link include: UnstableLlama / ezexl3 and Ednaordinary / MawDiscord
Developers and maintainers of these dependent repositories are strongly encouraged to rebuild their packages against the patched version of exllamav3_ext.
Acknowledgements
The CERT Coordination Center (CERT/CC) thanks Nathan Keys (professor-moody) for discovering and responsibly reporting this vulnerability.
This AI-assisted vulnerability note was prepared by Laurie Tyzenhaus.