Bitdefender says a crafted Android app can trap a phone in a crash loop the moment it is installed, with a factory reset as the usual way out. Google has declined to treat it as a security fix. Its own severity rules and its own source code make that decision hard to explain.
A malformed Android app that never runs, holds no code and asks for no permissions can leave a phone stuck on its boot animation until the owner wipes it. That is the finding Bitdefender Labs published on 5 November under the name GhostMap. The security firm says it reproduced the problem on a Pixel 10 running Android 17 with the 5 August 2026 security patch, and on every Android release back to Android 10.
The flaw itself is a denial-of-service bug. It does not steal data or let an attacker take over a device. What makes GhostMap worth more than a passing headline is how it was handled. According to Bitdefender, Google first closed its report as not reproducible, then told the researchers the issue was outside the scope of a security update and passed it to a feature team for a possible future Android release. That leaves a publicly documented way to brick phones with no patch, no CVE identifier and no stated timeline.
What GhostMap does to a phone
Bitdefender says its investigation began on 12 August, when a packed banking-malware dropper collected in the wild crashed the company's analysis emulators during installation. That sample only caused failed installs. The researchers then built a version that installs successfully and targets a small resource file that core system services read automatically as they scan installed apps.
Those services run inside system_server, the process that hosts most of Android's framework. When it reads the malformed file, it crashes. Android restarts it, the service scans installed apps again, reads the same file, and crashes again. Bitdefender's logs show a new system_server process dying every few seconds; in one capture the cycle repeated 110 times while the screen stayed on the boot animation.
Restarting does not help, and neither does safe mode, which Bitdefender says is enabled too late in the cycle to stop the crash. The researchers found two ways out. One is a factory reset, which erases anything stored only on the phone. The other is deleting the file over ADB (Android Debug Bridge) from a computer between crashes. That works only if USB debugging was already switched on, and according to Bitdefender it stops working after the first full kernel reboot because the crash then happens too early in startup.
How a ZIP header becomes a crash loop
An APK, Android's app package format, is a ZIP archive. Each file inside it carries metadata, including a compression method and two sizes: how many bytes are actually stored, and how many bytes the entry should expand to. Android supports two methods: stored (no compression) and deflated (compressed). The method field, however, is a 16-bit number and can hold other values.
GhostMap is what security researchers call a parser differential: two pieces of code read the same bytes and reach different conclusions. Here the two pieces are system libraries that handle APKs.
- libziparchive, which opens archives, rejects an entry whose declared uncompressed size is larger than the space it occupies in the file, but it applies that check only when the method is stored.
- libandroidfw, which loads app resources, asks a different question. If the method is deflated, it maps the compressed bytes and decompresses them. Anything else it treats as uncompressed and memory-maps the file using the declared uncompressed size.
An entry marked with a third method falls between those rules. The archive library never checks its declared size because it is not stored; the resource loader trusts that size because it is not deflated. Bitdefender's crash record shows an 8,408-byte APK mapped across roughly 16 MB of memory. The Linux kernel allows a memory mapping larger than the file behind it, but the first read beyond the real end of the file triggers a bus error (SIGBUS), and the reading process is killed. Because the fault is native, an app wrapping the call in a Java exception handler cannot catch it.
VibeCodAI checked the current Android Open Source Project code on 8 November. On the main branch, libziparchive's zip_archive.cc still applies the uncompressed-length check only when data->method == kCompressStored. In libandroidfw, AssetsProvider.cpp still branches on kCompressDeflated and, for every other method, maps entry.uncompressed_length. A third library in the same directory, ZipFileRO.cpp, uses the uncompressed length only for stored entries and the compressed length otherwise, which is the safer choice Bitdefender describes. Public source does not reveal private fixes in progress, so this confirms only that the published code still has the gap Bitdefender documented.
Google's own rules call this High severity
Google publishes a severity matrix for Android vulnerabilities in its security updates and resources documentation. Under the High rating it lists "local persistent denial of service (permanent, requiring reflashing the entire operating system, or factory reset)." Bitdefender's description of GhostMap matches that wording: a locally installed app causes a condition that, in most cases, only a factory reset clears.
There is also precedent. In November 2016 Google patched CVE-2016-6724, a flaw in Android's Input Manager Service that let a malicious app make a device reboot continually. Google rated it Moderate at the time, calling it a temporary denial of service that required a factory reset to fix. The current matrix treats factory-reset conditions as persistent, which is the point Bitdefender makes.
Google may have reasons it has not shared. The attack needs a victim to install a crafted app, and Google may weigh that user action, existing Play Store review or Google Play Protect scanning differently from the published matrix. But those reasons are not public. We found no public statement from Google explaining the decision, and BleepingComputer reported that it had asked Google about a fix without receiving a reply at publication. As things stand, the only account of Google's reasoning is Bitdefender's summary of two bug-bounty responses.
Why a "mere" crash matters
Denial-of-service bugs are routinely ranked below code execution and data theft, often for good reason. GhostMap is different because the damage persists and the remedy destroys data. A phone holding unsynced photos, authenticator app secrets, or messages that were never backed up loses them in a factory reset. Bitdefender raises extortion as a theoretical use: an app that disables a phone and threatens the owner with data loss. It stresses that it has not seen the crash-loop technique used against anyone.
The researchers describe two other scenarios that may matter more in practice than bricking. A malicious app could malform its own icon so that the launcher, the app list in Settings and the app's own info screen crash when they try to draw it. Those are the screens a user would open to uninstall the app. And because security scanners call the same Android parsing routines, an APK carrying the malformation can crash the scanner inspecting it. That second use is not hypothetical in spirit: the 2024 BadPack technique, which Palo Alto Networks' Unit 42 found in almost 9,200 samples collected between June 2023 and June 2024, already corrupted APK headers to defeat analysis tools while phones installed the apps without complaint.
This class of bug has a long history on Android. The 2013 "Master Key" flaw (CVE-2013-4787) and the 2017 Janus flaw (CVE-2017-13156) both came from Android components disagreeing about what an APK contained. Those bugs allowed code to get past signature checks; GhostMap only crashes processes. The underlying weakness is the same: one file format read by several independent parsers, with no single authority deciding what a valid entry looks like.
Who is exposed, and what to do
The realistic risk comes from apps installed outside well-policed channels: APKs sent by message or email, downloaded from third-party sites, or pushed through unofficial stores. Bitdefender also raises the theoretical possibility that a malformed file could arrive in an update to an app that was clean when reviewed. It has not published details of that scenario, and it is unclear whether Google Play's server-side checks would reject such a file; Google has not said.
Until Google fixes the code, users and IT teams can do the following:
- Do not sideload unknown APKs. Keep "install unknown apps" permissions switched off for browsers, messaging apps and file managers. Organisations can block unknown sources through mobile device management.
- Back up before you need to. Make sure photos, messages, passkeys and authenticator accounts can be restored, because a factory reset is the most likely recovery.
- Understand the ADB trade-off. Leaving USB debugging on keeps a narrow recovery route open, but it also widens physical-access risk. Most people should rely on backups instead.
- Ask about detection. Bitdefender says its Mobile Security app flags the malformation as Android.Riskware.Ghostmap.rA. Android does not let third-party apps block installations, though, so a warning only helps if the user deletes the file before Android reads it.
The fix itself looks small. Bitdefender argues that Android should simply reject compression methods other than stored and deflated, or make libandroidfw follow the stored-only rule ZipFileRO already uses. Either change would close the gap without touching how legitimate apps are built. Phone makers would then have to ship it, which brings the familiar problem of slow Android updates. That is the same fragmentation problem that shapes the "SMS of Death" bug. GhostMap is worse on one count: no patch is even scheduled.
The unresolved question is not whether GhostMap is the most dangerous Android bug of the year. It is not. The question is why a flaw that fits Google's published description of a High-severity vulnerability is being handled as a feature request. Until Google explains that, or ships a fix through a security bulletin, the details needed to build a phone-wiping app will stay public while affected devices go unpatched.