An issue was discovered on Samsung mobile devices with N(7.x), O(8.0) devices (MSM8998 or SDM845 chipsets) software. An attacker can bypass Secure Boot and obtain root access because of a missing Bootloader integrity check. The Samsung ID is SVE-2018-11552 (May 2018).

An issue was discovered on Samsung mobile devices with M(6.0) and N(7.0) (Exynos5433, Exynos7420, or Exynos7870 chipsets) software. An attacker can bypass a ko (aka Kernel Module) signature by modifying the count of kernel modules. The Samsung ID is SVE-2016-7466 (January 2017).

An issue was discovered on Samsung mobile devices with N(7.x) software. An attacker can boot a device with root privileges because the bootloader for the Qualcomm MSM8998 chipset lacks an integrity check of the system image, aka the "SamFAIL" issue. The Samsung ID is SVE-2017-10465 (November 2017).

Improper access control in Sticker Center prior to SMR Apr-2025 Release 1 allows local attackers to access image files with system privilege.

Improper export of android application components vulnerability in ImagePreviewActivity in Call Settings to SMR May-2023 Release 1 allows physical attackers to access some media data stored in sandbox.

Improper validation of integrity check vulnerability in Smart Switch PC prior to version 4.3.23052_1 allows local attackers to delete arbitrary directory using directory junction.

Improper validation of integrity check value in Blockchain Keystore prior to version 1.3.16 allows local attackers to modify transaction. Root privilege is required for triggering this vulnerability.

Improper export of Android application components vulnerability in Samsung Pay (India only) prior to version 4.1.77 allows attacker to access Bill Pay and Recharge menu without authentication.

Intent redirection vulnerability in Samsung Internet prior to version 14.0.1.20 allows attacker to execute privileged action.

Intent redirection vulnerability in Secure Folder prior to SMR MAY-2021 Release 1 allows attackers to execute privileged action.

The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.