GhostMap: the Android flaw that needs no code to crash a phone, and a vendor that closed it as out of scope

An app with zero code, and a crash loop that survives Safe Mode

An Android package file requiring zero permissions, containing zero lines of executable bytecode, and never launched by the user can plunge an Android smartphone into an unrecoverable crash loop.

Bitdefender disclosed the vulnerability on 5 November 2026, naming it GhostMap. The security research firm discovered the flaw after an APK collected from the wild crashed automated analysis emulators during installation. The issue stems not from malicious code inside the package, but from an architectural parser differential deep within Android's native runtime libraries.

When Android parses an APK, two core operating system libraries disagree on how to validate ZIP compression methods. The mismatch causes Android to establish a memory mapping that extends millions of bytes beyond the physical boundaries of the file on disk. The moment any process attempts to read data from this unallocated phantom space, the Linux kernel terminates the process with an unhandled SIGBUS CPU fault.

On modern hardware, including a Pixel 10 running Android 17 with the August 2026 security patch level, the crash traps the device in a persistent boot loop. Safe Mode fails to prevent the failure because core system daemons parse package resources before Safe Mode restrictions take effect. The only working recovery paths identified are a complete factory reset, which erases all user data, or an automated Android Debug Bridge script racing against sub-second daemon crashes on devices where Developer Mode was already active.

Bitdefender reported the vulnerability to Google through the Android and Devices Vulnerability Reward Program on 20 August 2026. Google closed the submission shortly afterwards with the disposition Won't Fix (Not Reproducible) and marked it out of scope. Following expanded laboratory verification showing persistent denial of service, Bitdefender submitted a second detailed report with working proof of concept reproduction steps on 25 August 2026. Google maintained that the issue was outside the scope of a security patch and referred the ticket to a feature team for possible consideration in a future Android release.

Eighty-five days from wild sample to public disclosure

The timeline from the initial discovery of the wild sample to public disclosure spans 85 days, with 77 days elapsing between the first formal report to Google and Bitdefender's research publication.

The 77-day interval between report and public disclosure represents a period where the vulnerability remained unpatched across all supported Android branches, including the newly released Android 17 operating system.

Zoom

The parser differential: libziparchive versus libandroidfw

Every Android package (APK) is structured as a standard ZIP archive. ZIP archives store metadata in multiple decentralized headers, including local file headers and the central directory record. Android inspects these structures repeatedly across an application's lifecycle: during signature verification, package installation, runtime asset loading, and antivirus scanning.

The vulnerability arises from an asymmetric assumption between two fundamental native libraries: libziparchive and libandroidfw.

Inside system/libziparchive/zip_archive.cc, the parser enforces an explicit sanity check to verify that an entry's declared uncompressed size does not exceed the remaining file bounds. However, the source code restricts this bounds check exclusively to entries explicitly marked with compression method kCompressStored (method 0). For any other compression method value, libziparchive skips the validation check entirely, assuming downstream decompression routines will allocate safe intermediary buffers.

The failure occurs when frameworks/base/libs/androidfw/AssetsProvider.cpp reads the resulting entry. Instead of validating whether the entry is stored, libandroidfw tests whether the compression method equals kCompressDeflated (method 8). If the method is anything other than deflated, the code enters an else branch that treats the data as an uncompressed stored asset, directly invoking the memory mapping subsystem with entry.uncompressed_length.

Because the ZIP specification uses a 16-bit integer for the compression method, an attacker can specify arbitrary values. A non-standard method value bypasses libziparchive's sanity check (because it is not stored) and bypasses libandroidfw's decompression path (because it is not deflated). libandroidfw maps the file using the attacker-controlled uncompressed length, which was never validated against the physical file boundaries.

Zoom

The memory map: sixteen megabytes mapped for an eight-kilobyte file

The memory mapping established by the operating system relies on the Linux kernel mmap system call. The kernel allows a process to map an address range that exceeds the backing file size; unbacked virtual address pages remain demand-paged and empty until accessed.

In Bitdefender's proof of concept test, the APK file stored on disk measured exactly 8,408 bytes. However, the crafted ZIP entry declared an uncompressed size of approximately 16,781,312 bytes (16 megabytes). The operating system mapped an address space 1,995 times larger than the physical file (derived).

When an Android service attempts to read through the mapped asset, the read pointer advances beyond the real 8,408 bytes. The moment the CPU encounters an address lacking physical storage backing, the hardware memory management unit faults. Because user-space asset loaders contain no signal handlers for memory bus errors, the Linux kernel dispatches signal 7 (SIGBUS) with subcode BUS_ADRERR, instantly terminating the process.

Bitdefender recorded the fault address at approximately 197,000 bytes past the end of the file. This confirms the vulnerability represents an unhandled kernel over-read rather than memory corruption or heap spraying. The process terminates before any arbitrary code execution can occur, producing a pure, unrecoverable denial of service condition.

Three targeting vectors: installer, system_server, and the application icon

The impact of GhostMap depends on which component parses the malformed asset and when the read occurs. Bitdefender demonstrated three distinct operational vectors:

Vector 1: The Package Installer. If the malformed entry is placed in the AndroidManifest.xml file, the package installer crashes during the initial intake phase. The installation aborts immediately and no files remain on the device. This was the exact behavior observed in the original wild banking sample, which had been corrupted by an automated packer tool.

Vector 2: Core System Services (The Crash Loop). If the malformed asset is embedded as an application resource that core framework services inspect after installation, the failure shifts to system_server. system_server hosts core operating system functions. When it dies, Android restarts the runtime environment. Upon restart, system_server scans installed packages, re-reads the crafted resource, crashes again, and triggers an infinite boot loop. On tested Pixel 10 hardware, the system crashed 110 times in normal mode and 72 times in Safe Mode, proving Safe Mode provides zero mitigation.

Vector 3: Application Icon (Uninstallation Denial). If an attacker embeds the malformed asset within the application's icon, the device continues booting normally. However, whenever the user attempts to view the app in the Android Launcher, the Settings Application List, or the App Info page, the system attempts to draw the icon and crashes immediately with SIGBUS. Every interface path required to uninstall the software crashes before the user can tap delete, locking the application onto the device.

Zoom

A ten-year pattern of Android archive parser disagreements

GhostMap belongs to a long-standing lineage of Android parser differential vulnerabilities. Because the Android operating system verifies, installs, loads, and executes applications through disparate codebases, parser disagreements have repeatedly created security exposures over the past decade.

In 2013, the Master Key vulnerability (CVE-2013-4787) exploited differences between signature verification and package installation when ZIP archives contained duplicate filename entries. In 2017, the Janus vulnerability (CVE-2017-13156) exploited disagreements over file header start offsets, allowing a file to function simultaneously as a valid APK and a valid DEX binary. In 2024, Unit 42 documented the BadPack campaign, where banking malware families including Anatsa and Cerberus deliberately corrupted ZIP headers so that analysis sandboxes failed while consumer phones installed the payloads.

Notably, Google previously recognized a similar persistent reboot loop as a security vulnerability. In the November 2016 Android Security Bulletin, Google patched CVE-2016-6724, an Input Manager Service defect rated Moderate that enabled a local malicious app to cause continuous reboots requiring a factory reset. Under Google's current published severity guidelines, a condition causing permanent loss of device functionality or requiring a factory reset qualifies as a High severity denial of service flaw.

What the record establishes and what it leaves open

The distinction between what Bitdefender engineered in laboratory conditions and what was seen in the wild is critical: the wild banking sample only triggered Vector 1 (installer failure), whereas Vector 2 (reboot loop) and Vector 3 (uninstall block) were developed during research testing.

Ranked actions for mobile fleets and enterprise administrators

Technical details: source excerpts and crash tombstones

Technical details: The following verbatim code excerpts and crash tombstone artifacts document the parser differential and CPU fault mechanism. Captions attribute each artifact to primary sources.

// system/libziparchive/zip_archive.cc
if (data->method == kCompressStored && data->uncompressed_length > cd_offset - data_offset) {
    return kInvalidOffset; // reject
}

// frameworks/base/libs/androidfw/AssetsProvider.cpp
if (entry.method == kCompressDeflated) {
    // map compressed_length, then decompress
} else {
    // map entry.uncompressed_length directly <-- never bounds-checked
}

// frameworks/base/libs/androidfw/Asset.cpp (_FileAsset::ensureAlignment)
unsigned char* buf = new unsigned char[mLength]; // mLength = declared size
memcpy(buf, data.unsafe_ptr(), mLength); // copy runs past physical end of file

Build fingerprint: google/frankel/frankel:17/CP2A.260805.005/15828068:user/release-keys
pid: 1420, tid: 1420, name: system_server  >>> system_server <<<
signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 0x7b39a42000 (read)
#00 pc 000000000004e120  /apex/com.android.runtime/lib64/bionic/libc.so (__memcpy_aarch64_simd+160)
#01 pc 0000000000028a44  /system/lib64/libandroidfw.so (android::_FileAsset::read+116)
#02 pc 00000000001048bc  /system/lib64/libandroid_runtime.so (android::NativeAssetReadChar+28)
#03 pc 000000000021a340  /system/framework/arm64/boot-framework.oat (art_jni_trampoline+128)
#04 pc 00000000004f2110  /system/framework/framework.jar (android.content.res.AssetManager$AssetInputStream.read+48)

The unallocated boundary

Bitdefender sells commercial endpoint and mobile security suites and conducted this investigation within its proprietary research laboratories. Google operates the Android platform and administers the Android and Devices Vulnerability Reward Program.

When a file carrying zero lines of executable code and requesting zero permissions can bypass Safe Mode and force a total device wipe, how does your organization's security baseline verify that an app is benign before installation?

Key facts at a glance