Rakuten Mobile Smartphones CVE-2026-107153

Exploitation requires physical possession of the device and the ability to enter its flashing/fastboot mode, and succeeds specifically because these handsets ship with AOSP default test keys for Android Verified Boot - meaning a system image signed with those publicly known test keys passes integrity verification instead of being rejected. Limiting factors: the attack cannot be performed remotely or over any network (AV:P), requires some device access/privilege to initiate flashing (PR:L), and is confined to the four named Rakuten models; there is no user-interaction-based or default remote exposure.

The CVSS 4.0 base score of 7.0 (HIGH) is dominated by the full-compromise impact triad (VC:H/VI:H/VA:H) but gated hard by AV:P - physical access to the handset is mandatory. No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active or automatable exploitation. These signals are consistent rather than conflicting: a physical-only, non-automatable attack requiring possession of the device is the profile of a targeted 'evil-maid'/lost-or-stolen-device threat, not mass exploitation. In practical terms this is a lower real-world priority than its HIGH score suggests - the physical-access precondition makes widespread exploitation infeasible - but it is a genuine integrity/anti-tampering failure for anyone handling these specific devices in untrusted custody (forensics, resale, lost/stolen scenarios). EPSS data is absent, so probabilistic exploitation likelihood could not be weighed; that should be verified if available.

An attacker who gains physical possession of a Rakuten handset (lost, stolen, or temporarily unattended) boots it into flashing/fastboot mode and installs a crafted system image signed with the publicly known AOSP test keys. Because Android Verified Boot trusts those test keys, the tampered image passes verification and boots, giving the attacker a persistently compromised device. No public exploit code was identified in the provided data, though the underlying technique (flashing test-key-signed images) is well documented.