Samsung Locksettings CVE-2026-21123

Exploitation requires the attacker to ALREADY possess root privilege on the Samsung device (PR:H) and physical/local access (AV:L) - there is no remote or network path. The device must additionally be in the Before First Unlock (BFU) state (powered on but not yet unlocked by the user since boot), and a tied profile (e.g. a work or secondary profile) must exist whose data is the target. The flaw is limited by the high bar of needing root beforehand, the local-only vector, and the narrow BFU timing window; it does not enable privilege escalation, code execution, or data modification (integrity and availability impact are None).

The input provides a CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N, base 6.7 Medium) but no EPSS score, no CISA KEV listing, and no indication of public exploit code. All signals point to low real-world risk despite the HIGH confidentiality impact: the vector is local only (AV:L) and requires already-held root/high privilege (PR:H), which is a substantial precondition - an attacker who already has root on the device has significant capability regardless of this flaw. There is no scope change (SC/SI/SA all N) and no integrity or availability impact (VI:N/VA:N). Exploitation status is 'no public exploit identified at time of analysis.' This is a defense-in-depth hardening fix (preventing root from reaching tied-profile data in the Before First Unlock state) rather than a widely weaponizable vulnerability. EPSS is missing, so widespread-exploitation probability cannot be quantified; the absence of KEV and the high privilege requirement together argue this is not an urgent priority. Note the CWE is listed as N/A in the input - the described behavior is improper privilege management (CWE-269-class), which should be confirmed with the vendor advisory.

An attacker who has already achieved root privilege on a Samsung device targets a device in the Before First Unlock (BFU) state - for example, a seized or recently powered-on phone that the user has not yet unlocked. Using that root access, the attacker abuses improper privilege management in the Locksettings component to read data belonging to a tied profile (such as a work or secondary profile) that should remain protected prior to first unlock. No public proof-of-concept is identified at the time of analysis.