A newly disclosed series of vulnerabilities in Realtek’s Bluetooth Low Energy implementation jeopardises the stability and security of connected devices, with one issue rated medium and another deemed high severity. The exposed flaws, affecting the RTL8762E BLE SDK version 1.4.0 and its EKF‑EVB derivative, allow attackers to trigger denial‑of‑service conditions during the pairing process by injecting crafted packets at precise stages.
The first flaw, identified as CVE‑2024‑48290, emerges from inadequate validation in the BLE protocol’s termination routine. An attacker positioned within Bluetooth range can send a maliciously formed llterminateind packet, causing the target device’s Bluetooth stack to crash and interrupt communications. Assigned a CVSS 3.1 base score of 4.3, the vulnerability affects devices using Realtek’s standard RTL8762E BLE SDK v1.4.0. It requires no privileged access or user interaction, making it easily exploitable over adjacent networks.
A second, more severe vulnerability—CVE‑2025‑44531—was added to the National Vulnerability Database on 24 June 2025. This flaw occurs earlier in the pairing exchange, when a crafted payload is delivered before the public key is received. The Bluetooth stack fails to manage the premature input, resulting in uncontrolled resource consumption and forcing a system crash. With a CVSS 3.1 score of 7.5, this vulnerability poses a high risk by enabling attackers with zero privileges and only network proximity to disrupt device functionality.
Both issues affect the same SDK version and stem from fundamental flaws in protocol resilience. The latter vulnerability, categorized under CWE‑400, highlights a broader weakness in resource management during handshake procedures.
Security analysts warn that the practical impact of these flaws depends on device deployment. The RTL8762E chip is used extensively in IoT devices such as fitness trackers, smart locks, wireless earbuds, and automation hubs. Disruption of Bluetooth services in such devices can compromise availability and user trust, particularly in environments where Bluetooth is integral to operation or security.
Realtek has reportedly issued patches on its official communication channels, though timelines and distribution mechanisms remain unclear due to the closed‑source nature of firmware updates. Enterprises integrating devices with the affected SDK are strongly advised to consult their vendors for firmware updates or consider disabling BLE pairing until mitigation is confirmed.
Independent researchers have recommended several interim safeguards. These include enabling rate limiting during pairing, enforcing stringent validation of early‑stage packets, and monitoring for abnormal pairing attempts. However, only confirmed vendor patches can fully rectify protocol loopholes at source.
The fact that both vulnerabilities resurface around the same SDK version amplifies concern over code audit practices. Bluetooth protocol stacks are notoriously complex, and previous studies—such as the BLURtooth and Secure Connections Only research—have underlined long‑standing industry challenges in robust implementation. Even established chip vendors have struggled to prevent pairing or transport‑layer manipulation.
In the context of BLE’s expanding role, particularly in the Internet of Things and proximity‑based systems, exploitation of such low‑level vulnerabilities could become a vector for broader disruption. A stabilised BLE stack is foundational to ensure not only connectivity but also higher‑layer security features that rely on pairing integrity.
The coordinated disclosure of these vulnerabilities underscores the need for continued scrutiny of common embedded SDKs. It also emphasises the importance of rapid patching by device manufacturers—especially when source code control is limited or obfuscated. Organisations managing fleets of BLE‑enabled hardware are urged to audit device firmware, liaise with vendors, and monitor for updates.
While no evidence currently indicates active wide‑scale exploitation of CVE‑2024‑48290 or CVE‑2025‑44531, the low complexity and zero‑interaction requirements mean that trending threat actors could weaponise them quickly. Consequently, the window for mitigation before operational disruption is narrowing.
Ahead of final vendor fixes, network administrators and system integrators may consider segmenting BLE traffic, deploying anomaly detection systems to flag improbable pairing behaviour, and applying stricter access controls on wireless interfaces. Such steps can reduce exposure while awaiting comprehensive SDK updates.