Microchip Rn4870 vulnerabilities

9 vulnerabilities

Known vulnerabilities in Microchip Rn4870, newest first, with CVSS severity, EPSS, KEV listings, ransomware use and the affected versions.

5.4CVE-2022-46401microchipbm64_firmware+11
EPSS score
0.68%
The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) accepts PauseEncReqPlainText before pairing is complete.8.6CVE-2022-46403microchipbm70_firmware+8
EPSS score
0.89%
The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) mishandles reject messages.7.5CVE-2022-46399microchipbm64_firmware+13
EPSS score
0.77%
The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) is unresponsive with ConReqTimeoutZero.6.5CVE-2022-46402microchipbm70_firmware+8
EPSS score
0.49%
The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) accepts PairCon_rmSend with incorrect values.5.4CVE-2022-46400microchipbm70_firmware+8
EPSS score
0.64%
The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) allows attackers to bypass passkey entry in legacy pairing.6.5CVE-2022-45192microchiprn4870_firmware
EPSS score
0.19%
An issue was discovered on Microchip RN4870 1.43 devices. An attacker within BLE radio range can cause a denial of service by sending a cleartext encryption pause request.6.5CVE-2022-45191microchiprn4870_firmware
EPSS score
0.20%
An issue was discovered on Microchip RN4870 1.43 devices. An attacker within BLE radio range can cause a denial of service by sending a pair confirm message with wrong values.5.3CVE-2022-45190microchiprn4870_firmware
EPSS score
0.26%
An issue was discovered on Microchip RN4870 1.43 devices. An attacker within BLE radio range can bypass passkey entry in the legacy pairing of the device.4.3CVE-2024-29155microchiprn4870_firmware
EPSS score
0.23%
On Microchip RN4870 devices, when more than one consecutive PairReqNoInputNoOutput request is received, the device becomes incapable of completing the pairing process. A third party can inject a second PairReqNoInputNoOutput request just after a real one, causing the pair request to be blocked.