News, updates, trends and the latest
info you need to know about IT

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
A vulnerability in MLflow’s dspy and statsmodels model flavors allows 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.
Impact
Exploitation of this vulnerability allows 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 this vulnerability; 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.