Android GhostMap flaw can boot-loop devices via malformed APK resources before the app opens

Malformed APK metadata can crash a core Android process

Bitdefender Labs has disclosed an Android vulnerability it calls GhostMap, in which a crafted APK installs without complaint and then pushes the device into a persistent restart loop — before the app is ever opened, its code executed, or any permission granted. According to a dev.to summary of the research (which dates Bitdefender's original write-up to November 5), Bitdefender rates the issue high in severity and assesses Android 10 and later as affected, with testing that extended to Android 17. No CVE was listed in the write-up.

The root cause is not a single bug but a disagreement between three Android components — libziparchive, libandroidfw and system_server — about how to read the same APK entry.

Three components, three interpretations

An APK is a ZIP archive, and each entry in it declares a compression method and an uncompressed size. GhostMap hinges on an entry whose method is neither "stored" (method 0) nor "deflated" (method 8), combined with an uncompressed length far larger than the real data.

Per Bitdefender's findings as relayed by dev.to:

• libziparchive applies its uncompressed-size sanity check only to stored entries. An entry using some other method slips past the check despite its inflated declared length.
• libandroidfw treats every non-deflated entry as stored and maps it into memory using that declared length, so the mapping can extend well beyond the file's actual end.
• A system service inside system_server, which automatically reads resources from installed packages, then touches the mapped bytes. Reading past the file's true end raises SIGBUS and takes down the critical process — and with it, the Android runtime.

Bitdefender notes that the oversized mapping alone is harmless; the crash happens only when code actually reads the region beyond the real file.

How the loop persists

The demonstrated chain is essentially install-and-wait:

1. A user or an application-management channel installs the crafted APK. The app requires no permissions and never launches.
2. A system service in system_server reads the malformed resource as part of normal package processing.
3. The out-of-bounds read triggers SIGBUS; system_server crashes and the device restarts.
4. On boot, Android parses the installed package again and repeats the failure.

In the researchers' persistent variant, safe mode offered no escape and the loop continued across reboots, leaving the device unusable and the normal uninstall controls unreachable.

Notably, the investigation began with a banking-dropper sample — but according to the summary, that sample actually failed to install, and the boot loop was a separate demonstration built by the researchers. Intentional use of GhostMap by the dropper's author has not been established, and no real-world distribution campaign for the persistent variant has been reported.

Recovery options are narrow

The findings sketch a very tight recovery window. If USB debugging was already enabled, the package can be removed via ADB — but only ahead of the first full kernel reboot; after that, the route closes. What remains is a factory reset and device reprovisioning, with any unbacked data lost. A future fix and its release version have not been confirmed, the summary notes.

There is also a second-order concern: file managers and scanners that read entries through the same affected parser can themselves crash on the malformed APK, so security and analysis tooling may suffer denial of service too. Practical defenses are preventive — MDM policies that block untrusted APK installation, and static validation of compression methods and size boundaries that never invokes the vulnerable parser.

The demonstrated impact is persistent denial of service. The research does not establish hardware damage, arbitrary code execution, or data theft.

Why it matters

GhostMap shows how a container-format flaw, amplified by inconsistent validation across libraries, can turn installation itself into an attack: no code execution, no permissions, no user interaction beyond installing the app. For Android fleets it argues for blocking sideloaded, untrusted APKs and for scanners that validate APK structure independently rather than through the same parsers they are meant to protect. It is also a reminder that availability is a security property — a device trapped in a boot loop is as unavailable as one that has been wiped, and depending on backups, potentially as costly.