Currently browsing: Technology

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.

Overview
An incorrect permissions assignment vulnerability in the amwrtdrv.sys kernel driver, included with AOMEI Backupper 8.4.0, allows an unprivileged local user to perform arbitrary writes to the physical disk. When Secure Boot is disabled, this can be leveraged to execute arbitrary UEFI-level code before the operating system loads. This allows an attacker to bypass OS-level security controls, including HVCI, EDR solutions, and Microsoft Defender. The attack may also enable capture of BitLocker Volume Master Key (VMK) material, depending on the system’s BitLocker configuration.
Description
AOMEI Backupper from AOMEI International Network Limited is designed to provide backup and disaster recovery services. It also helps individuals and businesses to create system images, disk clones, and file backups. AOMEI Backupper is available as a Windows application and can be integrated into enterprise backup workflows or directly used by end users.
CVE-2026-12780: An Incorrect Permission Assignment for Critical Resource (CWE-732) vulnerability in the amwrtdrv.sys kernel driver used by AOMEI Backupper 8.4.0 allows an unprivileged local attacker to achieve UEFI-level arbitrary code execution by directly writing to physical disk devices. The driver creates a world-accessible device object without a security descriptor, therefore allowing any user-mode process to open the device and issue unrestricted write requests. Hence, an attacker can modify disk sectors in the pre-partition gap (LBA 34–2047), inject a malicious UEFI payload, and alter the GPT to reference the payload as an EFI System Partition. The payload can then execute during the UEFI Boot Device Selection (BDS) phase, before operating system security mechanisms are loaded.
Impact
An attacker with unprivileged local access to a system running AOMEI Backupper 8.4.0 can exploit this vulnerability by opening the world-accessible \.mwrtdrvDISK0 device object and sending specially crafted write commands to an arbitrary physical disk. When Secure Boot is disabled, a successful exploitation allows the attacker to inject UEFI code that executes before the Windows kernel loads, completely bypassing kernel-mode security features including Hyper-V Code Integrity (HVCI), Endpoint Detection and Response (EDR) solutions, Windows Defender, and Hyper-V isolation. On systems using BitLocker with TPM-only protection, this attack vector enables evil maid attacks whereby VMK credentials can be captured during the pre-boot phase Boot Device Selection (BDS) phase.
Solution
Please see the Vendor Information section for patches provided by AOMEI International Network Limited to address this issue. CERT/CC recommends that AOMEI Backupper users update to a version that includes the corrected amwrtdrv.sys driver and implements appropriate access controls.
Users who cannot immediately apply the available update should consider uninstalling AOMEI Backupper. Alternatively, users may disable the amwrtdrv.sys service by changing its start type from AUTO_START to disabled. Enabling Secure Boot in UEFI firmware settings provides additional defense in depth by requiring signed bootloaders, but it does not address the underlying driver vulnerability.
Acknowledgements
Thank you to SiCk / afflicted.sh for reporting this vulnerability. This document was written by Vijay Sarvepalli.

Overview
The UEFI Shell program may expose raw memory access capabilities that, if present in platform firmware for debugging or advanced support use cases, could be abused to undermine UEFI Secure Boot protections. When the UEFI Shell is included in SPI flash, an attacker with the ability to modify UEFI boot configuration may be able to create multiple boot option entries and bypass controls intended to prevent the UEFI Shell from launching while Secure Boot is enabled. This could allow an attacker to modify the pre-boot environment and execute unauthorized software during system startup.
Description
The Unified Extensible Firmware Interface (UEFI) is a firmware specification that defines the interface between a computing platform’s hardware and operating system (OS) during the early boot process before the operating system is loaded. UEFI Secure Boot helps ensure that only trusted and digitally signed software is executed during these early stages of platform initialization.
The TianoCore EDK II project provides an open-source reference implementation of the UEFI and Platform Initialization (PI) specifications. The project includes the UEFI Shell, which provides command-line utilities for debugging, diagnostics, and advanced platform management. Many OEM and Independent BIOS Vendor (IBV) firmware implementations include the UEFI Shell in SPI flash for service and support purposes. Because the shell executes in the pre-boot environment, it provides powerful commands such as dmem (display memory) and mm (memory modify) that can access physical memory. Many implementations include a boot entry for the UEFI Shell but remove or suppress it when Secure Boot is enabled to reduce the risk of misuse.
A vulnerability disclosed by Eclypsium researcher Stas Lyakhov details a technique in which an attacker with the ability to create additional UEFI boot entries can reference the UEFI Shell even when standard controls are implemented to prevent its execution. An attacker could then exploit the UEFI Shell and its startup scripting capabilities to modify the pre-boot environment, including overwriting Secure Boot-related memory values, and execute unauthorized code during the early boot process.
Impact
An attacker capable of modifying UEFI boot entries may be able to circumvent intended Secure Boot protections and execute arbitrary code before the operating system loads. Code executed during the pre-boot phase may establish persistent access, including the ability to load malicious boot components or kernel-level software that can survive both system reboots and, in some cases, reinstallation of the operating system. Such activity may also reduce the effectiveness of OS-based security controls and endpoint detection and response (EDR) solutions.
Solution
Apply a Patch
Please see the Vendor Information section for responses from vendors that have released updates addressing this issue. Updating UEFI firmware may require OEM-specific tools and deployment processes, as firmware updates are often managed separately from operating system patch management. Follow the guidance provided by your platform vendor when applying firmware updates.
Recommendations for Enterprises
Organizations should review Secure Boot configuration and platform security policies to help prevent or detect unauthorized modifications to UEFI boot entries. Changes to boot configuration should be monitored and audited where possible. Enterprises that use independent endpoint management solutions should consult their OEM vendors for guidance on integrating UEFI firmware updates into their existing firmware lifecycle and patch management processes.
Acknowledgements
Thanks to Stas Lyakhov from Eclypsium for reporting this vulnerability. This document was written by Vijay Sarvepalli.