ARM mbed TLS before 1.3.22, before 2.1.10, and before 2.7.0, when the truncated HMAC extension and CBC are used, allows remote attackers to execute arbitrary code or cause a denial of service (heap corruption) via a crafted application packet within a TLS or DTLS session.

Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache.

Encryption key exposure in firmware in iSmartAlarm CubeOne version 2.2.4.8 and earlier allows attackers to decrypt log files via an exposed key.

Password file exposure in firmware in iSmartAlarm CubeOne version 2.2.4.8 and earlier allows attackers to execute arbitrary commands with administrative privileges by retrieving credentials from this file.

The BL1 FWU SMC handling code in ARM Trusted Firmware before 1.4 might allow attackers to write arbitrary data to secure memory, bypass the bl1_plat_mem_check protection mechanism, cause a denial of service, or possibly have unspecified other impact via a crafted AArch32 image, which triggers an integer overflow.

ARM mbed TLS before 1.3.21 and 2.x before 2.1.9, if optional authentication is configured, allows remote attackers to bypass peer authentication via an X.509 certificate chain with many intermediates. NOTE: although mbed TLS was formerly known as PolarSSL, the releases shipped with the PolarSSL name are not affected.

iSmartAlarm cube devices have an SSL Certificate Validation Vulnerability.

On iSmartAlarm cube devices, there is Incorrect Access Control because a "new key" is transmitted in cleartext.

On iSmartAlarm cube devices, there is authentication bypass leading to remote execution of commands (e.g., setting the alarm on/off), related to incorrect cryptography.

iSmartAlarm cube devices allow Denial of Service. Sending a SYN flood on port 12345 will freeze the "cube" and it will stop responding.