Android Signing Key Leak Exposes 278 Apps to Fake Updates
A digital signature should prove that an Android app truly comes from its original developer. New research shows how a single leaked signing key can turn that trust mechanism into a supply-chain weakness. According to the study, titled A Longitudinal Study of Android Apps Signing Key Protection, the authors scanned public GitHub repositories for exposed keystore files. In doing so, they traced the exposure to real apps used by billions of people.
At a Glance
- Researchers found 56,510 GitHub-hosted keystore files tied to Android app signing.
- Of these, 46,619 sat next to plaintext passwords in the same repository.
- After removing duplicates, the team confirmed 5,673 compromised keystores and 6,602 signing keys.
- Verified certificates trace back to 278 real apps, including 252 preinstalled apps from seven device makers.
- Combined, the affected apps reach an audience of more than 10 billion users.
- A proof-of-concept attack on the Baidu Keyboard app confirmed the flaw is practically exploitable.
How the Signing Keys Leaked
Specifically, the researchers combed public GitHub repositories for keystore files connected to Android app signing. In total, they uncovered 56,510 such files. Alarmingly, 46,619 of these keystores sat right next to their passwords in plain text. After removing duplicate entries, the team confirmed 5,673 compromised keystores. Those keystores held 6,602 distinct signing keys.
Why a Leaked Signing Key Breaks Android’s Trust Model
Android’s update logic makes this leak especially dangerous. Specifically, the operating system only accepts an app update if it carries the same developer signature as the original install. Therefore, an attacker who obtains both the private key and its password can build a fake update. That update carries the correct signature. As a result, the device treats it as a legitimate new version.
Real-World Exposure: 278 Apps and Over 10 Billion Users
Verification linked 26 compromised certificates to 278 real-world apps. Among these, 26 came from public app stores. Meanwhile, the remaining 252 were preinstalled apps from seven device manufacturers. Affected developers include Baidu, Ctrip, Kwai, Xiaomi, and others. Altogether, these apps reach an audience of more than 10 billion users.
The Extra Danger in Preinstalled Apps
Preinstalled and system apps carry an extra risk. In particular, such apps sometimes receive elevated permissions without a separate prompt to the user. Consequently, if a fake update replaces one of these apps, malicious code could reach sensitive data or disrupt the device. The researchers also flagged a risk of persistent denial of service, which conflicting privileged permissions can trigger.
Proof of Concept: A Weaponized Baidu Keyboard
To test real-world feasibility, the team targeted the Baidu Keyboard app. First, they repackaged the app and injected additional DEX code. Then, they signed the tampered package with a leaked key. After installation, the fake version quietly logged keyboard input to a file. The app then sent that file to a companion app. Notably, this demonstration is not evidence of an active mass campaign. Still, it proves the flaw is practically exploitable.
Beyond Smartphones: The Baidu CarLife Risk
The leak reaches beyond handsets, too. Specifically, one exposed key ties directly to Baidu CarLife, a platform for automotive head units. Manufacturers have installed CarLife on more than 1,100 car models. In this scenario, a fake phone app could interfere with the car’s interface. It could also monitor a driver’s behavior undetected.
Disclosure and Uneven Remediation
The researchers reported their findings to the affected parties. In addition, they honored a standard responsible-disclosure window before publication. By the time of publication, some teams had already closed the exposed repositories. However, full remediation moved unevenly across the industry. In fact, only one third-party developer completed a full key rotation.
Mitigation Recommendations for Developers and OEMs
Going forward, developers should avoid storing keystore passwords inside project files. They should also use separate passwords for the keystore and the signing key. In addition, multi-factor authentication adds a useful layer of protection. Where possible, teams should hand signing duties to a managed signing service instead.
Device manufacturers face a parallel set of recommendations. Namely, they should never sign system components with public AOSP keys. They should also avoid embedding third-party apps into the OS image with excessive privileges.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
