Hírolvasó
VU#762428: Authlib library contains a signature‑verification bypass vulnerability
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.
DescriptionAuthlib 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)
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.
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.
AcknowledgementsThank you to Tong Hoang Gia (uziii2208) and Nguyen Minh Tuan (nguyenminhtuan28) for reporting this vulnerability. This document was written by Bob Kemerer.
Fizetett Meta hirdetésekkel terjesztett Android kártevőt azonosított a lengyel CERT
VU#699627: Readwise Reader for Android, version 8.7.2, contains multiple XSS vulnerabilities
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.
DescriptionReadwise 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.
ImpactAn 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.
SolutionUnfortunately, 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.
AcknowledgementsThanks to Zampier Zago (FUNFACTOR1) for reporting these vulnerabilities. This document was written by Alex Lewis.
Ausztrál kormányzati rendszerekhez fért hozzá egy OpenAI ügynök
Kihasznált webes sérülékenységektől az AI-vezérelt bűnözői műveletekig – Heti összefoglaló
Frissített OT-biztonsági útmutatót ad ki a NIST
VU#234131: ViewSonic vCast media streaming service allows unauthenticated screen exfiltration and device compromise
ViewSonic vCast software, which is included in ViewBoard smartboard devices, contains multiple vulnerabilities that an attacker can chained to achieve full device compromise.
DescriptionViewSonic 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
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.
SolutionUnfortunately, 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.
AcknowledgementsThank you to Adam Mohammed Zenker for this report. This document was written by Alexander Lewis.
VU#676317: Norwegian Cruise Line door access controller contains an improper authentication vulnerability
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.
DescriptionNorwegian 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.
ImpactAn 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.
SolutionUnfortunately, 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).
Thank you to Mark Linton for reporting this vulnerability. This document was written by Bob Kemerer.
Európai és Kanadai felhasználókat vesz célba az Androidos RemControl
Új eszközzel veszi fel a harcot a LinkedIn a hamis profilokkal szemben
Több mint 460 millió dollárra bírságolták a Google-t a helyadatok kezelése miatt
VU#273940: Enterprise Access Management EAM does not rotate RSA keys
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.
DescriptionCVE-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.
ImpactAn 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.
SolutionUnfortunately, 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.
AcknowledgementsThank you to Frank "5y5tem5" Mileto for reporting this issue. This document was written by Alexander Curtis.
VU#754548: Cinnamon's kotaemon contains improper authorization checks in Kotaemon multi‑user chat handlers
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.
DescriptionCinnamon'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.
ImpactFull 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.
SolutionUnfortunately, 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/
Thank you to Louis Sanchez for reporting this vulnerability. This document was written by Bob Kemerer.
Kibertámadás érte a Müncheni Egyetemet
Egy új nulladik napi sebezhetőség blokkolja a Defender vírusirtójának frissítéseit
Ellopott jelszavak miatt kerültek veszélybe az amerikai víz- és szennyvízkezelő szolgáltatók
VU#738147: Vendor-signed UEFI Shell applications allow Secure Boot bypass
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.
DescriptionThe 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.
SolutionApply 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.
AcknowledgementsThanks 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.
