Unpatched GhostMap Android Flaw Traps Phones in Endless Boot Loops After App Installation
Do Son 
TL;DR
Bitdefender Labs uncovered a parser bug named the GhostMap Android flaw that traps smartphones in an endless boot loop as soon as a crafted app is installed. Even though the app holds zero executable code and asks for no permissions, this unpatched GhostMap Android flaw crashes a core operating system service even in Safe Mode. Because Google declined to issue a security patch for the defect, victims hit by such an app must perform a factory reset. This wipes all local data.
Delivery and Attribution
The investigation began on August 12, 2026, when an Android banking dropper collected from the wild crashed Bitdefender’s analysis emulators during installation. Upon closer inspection, analysts realized the crash was not an intentional feature of the malware. Instead, the malware author had wrapped the APK with a BadPack-style packer. This packer rewrites internal ZIP headers to break reverse-engineering tools. Previously, Palo Alto Networks Unit 42 documented around 9,200 BadPack samples in a single year. These samples carried banking trojans such as Anatsa, Cerberus, and BianLian.
Confirmed Versus Suspected Attribution
Confirmed attribution does not link the wild banking sample to a named threat group. In fact, technical evidence shows the malware author accidentally broke the Android package installer. This happened while trying to hide the dropper from static scanners. Meanwhile, confirmed attribution for the persistent boot-loop proof of concept belongs to Bitdefender Labs. The lab demonstrated how an attacker could aim the same parsing mistake at a core system service. While zero persistent boot-loop attacks have been observed in the wild, researchers warn that cybercriminals could deliver the malformation through a routine app update. This could happen after passing initial store reviews.
Infection Chain
The bug stems from a parser disagreement between two native Android libraries that handle APK archives: libziparchive and libandroidfw. Every entry inside a ZIP archive contains a 16-bit compression method field and two size fields: compressed length and uncompressed length. Normally, Android uses only two methods: stored (uncompressed) and deflated (compressed).
When Android opens an APK, libziparchive checks that an entry’s declared uncompressed size does not exceed the physical file space. However, it runs this check only when the compression method is explicitly set to stored. Later, when libandroidfw loads the entry as an application resource, it checks only whether the method is set to deflated. Then, it treats every other 16-bit number as stored.
Out-of-Bounds Memory Mapping and SIGBUS
By setting the compression method to any number other than stored or deflated and declaring a massive uncompressed length, an attacker slips past the initial size check. Next, libandroidfw asks the Linux kernel to memory-map the tiny file across the huge declared length. According to the Bitdefender Labs research report, “We call it GhostMap: the malformed entry causes Android to map the file across memory that was never allocated, and the crash occurs when a process reads from that empty space.”
On a Google Pixel 10 running Android 17 with the August 5, 2026 security patch, a kilobyte-sized APK was mapped across 16 megabytes of unallocated memory. Whether a process streams the entry piece by piece or copies the whole block at once to align an icon or XML resource, the read walks past the real end of the file. Immediately, the processor faults. The kernel then kills the reading process with a SIGBUS signal.
System Impact and Extortion Scenarios
Which process dies depends entirely on which file inside the APK carries the malformed header. In the original wild banking sample, the packer malformed the Android manifest file. This only crashed the package installer and aborted the installation. However, when researchers malformed a small post-install resource that Android parses automatically, the GhostMap Android flaw killed system_server. This is the core process that hosts most of the operating system.
As the researchers explained, “It crashes, Android restarts it, and on restart the service goes through the installed apps again, reads the same file again, and crashes again. The phone never finishes starting.” In one test capture, the crash happened roughly one second after installation. The process repeated 110 times while the screen stayed frozen on the boot animation. Worse still, Safe Mode offers no relief because system_server reads the malformed resource before Safe Mode initializes.
Beyond bricking a phone to demand an extortion ransom, attackers can use the bug in two stealthier ways. First, a working trojan can malform its own application icon. Whenever the victim opens the home launcher, the Settings app list, or the app info screen to uninstall the malware, that screen crashes immediately. This makes the app impossible to remove through the user interface. Second, malware authors can include a malformed entry so that any mobile antivirus scanner or automated sandbox that parses the APK crashes with a native fault before flagging the threat.
Defense and Detection Guidance
Bitdefender reported the vulnerability to Google on August 20 and August 25, 2026, providing a working proof of concept. Although Google patched a similar reboot loop flaw in 2016 under CVE-2016-6724, the company closed the first GhostMap ticket as not reproducible. They ruled the second report outside the scope of a security update. The issue was referred to a feature team for a possible future OS release. As Brandefense and Android Authority noted, this leaves all phones running Android 10 through Android 17 exposed without an official patch.
If a device enters the crash loop, a full kernel reboot closes almost every recovery path. This leaves a data-wiping factory reset as the only fix for regular users. Only users who enabled USB debugging beforehand have a narrow window to run an Android Debug Bridge script from a computer to delete the offending APK between system_server restarts. To stay safe from the unpatched GhostMap Android flaw, users should avoid sideloading unverified APKs. Additionally, users should maintain regular cloud backups, and use a mobile security scanner that inspects raw ZIP header structures for Android.Riskware.Ghostmap.rA before installation.
Support Our Threat Intelligence
Find our threat intelligence and malware analysis helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
