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

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.

Overview
Skullcandy Dime 3 wireless earbuds, running firmware version 1.0.0.28, accept a new Bluetooth Classic (BR/EDR) pairing request from an unpaired device without requiring the earbuds to be placed into pairing mode or requiring any physical confirmation or interaction from the owner.
Description
The Skullcandy Dime 3 (Model S2DCW) wireless earbuds, running firmware version 1.0.0.28, accept a new Bluetooth Classic (BR/EDR) pairing request from a previously unpaired device without the device being placed into pairing mode by the owner and without physical confirmation on the earbuds. The device’s Bluetooth PnP modalias identifies the chipset vendor as Airoha Technology Corp. (Bluetooth SIG company ID 0x0094). This vulnerability was previously disclosed in CVE-2025-20701 and is described as: In the Airoha Bluetooth audio SDK, there is a possible way to pair Bluetooth audio device without user consent. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
An attacker is required to be within Bluetooth radio range to the target earbuds, but no prior pairing, physical access, or interaction with the earbuds’ buttons or case is required to exploit the vulnerability. A direct pairing request to the earbuds’ known or discovered Bluetooth Classic address can be sent without a PIN, passkey, or physical confirmation. The pairing/bonding completes without owner action due to the device’s NoInputNoOutput I/O capability. The firmware version displayed on the affected Skullcandy Dime 3 wireless earbuds is 1.0.0.28.
Impact
Once bonded, the attacker’s device is added as a trusted device and can reconnect automatically whenever in range. This allows an attacker to establish an A2DP audio transport, which interrupts the legitimate user’s active connection to their own device. The only indication to the legitimate user is an audible “New device paired” notification, given after the unauthorized pairing has already succeeded, providing no opportunity to block it in advance. This could allow an attacker to hijack the audio session or, depending on device capabilities, potentially access other services exposed over the same Bluetooth Classic connection. An attacker can also access the Dime 3’s Hands-Free/Headset profile and capture live microphone audio.
Solution
The vendor considers the CVE-2025-20701 patch in version 1.0.0.30 to be effective. However, Skullcandy confirmed that the Dime 3 does not support firmware updates through the Skullcandy application. Existing units running the vulnerable firmware cannot currently be updated by customers through the app. As of this writing, there are no known consumer-accessible methods to update an existing unit from the affected firmware version 1.0.0.28 to version 1.0.0.30.
Acknowledgements
Thank you to Jacob Nowak for reporting this vulnerability. This document was written by Bob Kemerer.

Overview
A Server-Side Request Forgery (SSRF) vulnerability exists in Ascensio System SIA’s ONLYOFFICE ownCloud integration plugin (version 9.12). The plugin’s backend endpoint does not adequately validate the user‑supplied document server URL before initiating outbound connections. An authenticated administrator can exploit this flaw to coerce the ownCloud server into issuing arbitrary network requests to attacker‑controlled destinations.
Description
The ownCloud ecosystem delivers a platform for enterprise file collaboration, providing capabilities for storing, syncing, and sharing data across devices. Ascensio System SIA’s ONLYOFFICE provides a connector that integrates with ownCloud, enabling users to open and edit files directly within the cloud storage environment.
When configuring the ONLYOFFICE document server within ownCloud, the plugin accepts a document server parameter and attempts to verify the supplied URL by initiating a connection directly from the ownCloud server. As detailed in CVE-2026-84282, the application does not restrict or sanitize this parameter, allowing an authenticated administrator to provide arbitrary URLs, including internal network hosts or localhost addresses. By submitting crafted configuration requests to the /apps/onlyoffice/ajax/settings/address endpoint, an attacker can instruct the server to make outbound requests to internal systems that are otherwise inaccessible externally. Differences in returned error messages (such as connection failures versus SSL/TLS negotiation errors) enable the attacker to distinguish between open and closed TCP ports, facilitating internal network reconnaissance and port enumeration. The outbound requests originate from the ownCloud server, demonstrating server‑side request execution consistent with an SSRF vulnerability. This vulnerability could allow an attacker to abuse the ownCloud server infrastructure as a proxy to send malicious content to targeted systems.
Impact
Successful exploitation allows an authenticated administrator to:
* Trigger arbitrary outbound network requests from the ownCloud server (SSRF).
* Access and probe localhost services (127.0.0.1) not reachable externally.
* Perform internal network reconnaissance and port scanning.
* Identify open and closed TCP ports through response‑based side channels.
* Increase the attack surface for potential follow‑on exploitation of internal services.
Solution
Unfortunately, the vendor could not be reached to coordinate this vulnerability. While an official patch is not available at this time, there are a few general recommendations that may help mitigate this vulnerability. Disable or remove the plugin until a patched version is released. Network‑level egress controls should be applied to limit outbound connections from the ownCloud server to authorized destinations only.
Acknowledgements
Thank you to Nguyen Huy Hoang, Nguyen Vu Long and Nguyen Tien Dat of ETC JSC for reporting this vulnerability. This document was written by Bob Kemerer.