GhostMap: one Android APK, no permissions, an endless reboot loop
Bitdefender's APK parsing flaw survives reboots and safe mode, and Google has not patched it

GhostMap: one Android APK, no permissions, an endless reboot loop

Bitdefender published research on 5 November 2026 describing GhostMap, a flaw in how Android reads application packages. Installing a crafted APK is enough to put a phone into a reboot loop that a restart does not clear, and Google has declined to treat it as a vulnerability worth patching.

What happened

Two Android libraries, libziparchive and libandroidfw, interpret ZIP compression methods differently. A malformed APK can therefore pass the size checks and get mapped beyond the real end of the file. Reading that mapping raises SIGBUS and kills whichever process touched it.

Bitdefender built a proof-of-concept app that contains no executable code, requests no permissions and does not need to be launched. Android's system_server reads a resource from it after installation, crashes, restarts, reads the same resource and crashes again. On a Pixel 10 running Android 17 with the August 2026 patch, the loop began about a second after install and repeated 110 times in normal boot; safe mode still cycled 72 times, because system_server parses the file before safe-mode protections apply.

The recovery paths Bitdefender identified are a factory reset, or in narrow cases ADB scripts racing the crashes to delete the file. The researchers reported it through Google's Android vulnerability reward programme in August 2026; Google closed the report without a security update, and no CVE was assigned.

Who is affected

  • Android devices generally, since the parsing behaviour is in base Android rather than vendor code. Bitdefender tested Pixel hardware and did not test other manufacturers.
  • Staff who install APKs from WhatsApp, email or download links rather than the managed store.
  • Fleets where users still have install-from-unknown-sources enabled, or where MDM does not block side-loading.
  • Any phone that holds the only copy of something, such as an authenticator app or a client conversation, because the fix wipes the device.

What to do now

Treat side-loaded APKs as a device-wipe risk and close install-from-unknown-sources on every managed phone.

  • Push an MDM policy that blocks installation from unknown sources and reports devices that have it enabled.
  • Verify Android Enterprise work profiles are enforced, so a work device can be reset without taking personal data with it.
  • Check that authenticator seeds, photos and chat histories on phones are backed up somewhere you can restore from.
  • If a device is already looping, stop rebooting it: factory reset, restore, then trace how the APK arrived and block that delivery path.

What this means for South African businesses

Android is the default phone in most South African SMEs, and WhatsApp is how staff receive files, which is exactly the delivery path a permission-free APK needs. This is a denial of service rather than data theft, so it will not appear in a breach report, but a wiped phone that held the only copy of a driver's delivery thread or a receptionist's authenticator is a real operational hit. My judgement is that mass exploitation is unlikely because a person still has to install the file, but one convincing APK sent to one busy employee is cheap, and the recovery cost lands on the business rather than the attacker.

Source: Bitdefender Labs: GhostMap.

Also on the blog

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.

Windows Paint CVE-2026-83844: 8.1 RCE and the fix that is not arriving
crafted image remote code execution in Windows 11 Paint, patch stuck behind Store delivery