<img src="https://news.lavx.hu/_next/image?url=https%3A%2F%2Fnews.lavx.hu%2Fapi%2Fmedia%2Ffile%2Fghostmap-an-android-flaw-that-can-crash-phones-before-an-app-opens_gen_1794082939626-1200×630.jpg&w=3840&q=75″ alt=”GhostMap: an Android flaw that can crash phones before an app opens” loading=”lazy”>
GhostMap: an Android flaw that can crash phones before an app opens
Nov 7, 2026, 8:22 PM UTC
•Lukas Brandt
•11min read
Bitdefender Labs researchers found a flaw in Android’s parsing of ZIP entries that can leave phones stuck in a crash loop after a crafted app is installed. The app needs no permissions and no launch; recovery may require a factory reset.
A flaw in how Android reads ZIP entries can leave a phone stuck in a crash loop after installing a crafted app, Bitdefender Labs researchers reported.
The phone does not finish starting. The core system process that hosts most of Android crashes, restarts, and crashes again every few seconds. Rebooting does not help. Safe mode does not help either, because the service reads the file before safe mode takes effect. In most cases the only recovery is a factory reset, which erases locally stored data.
Bitdefender began investigating on Aug. 12, 2026, after an APK collected from the wild crashed emulators in its analysis infrastructure. The sample was a banking dropper wrapped by a packer, a tool that rewrites an APK’s internal structure so reverse-engineering tools cannot read it. The dropper did not run and crashed during installation. Bitdefender traced the failure to Android’s handling of ZIP entry compression methods and declared uncompressed length. The problem was not the malware. Android was the problem.
An APK is a ZIP file. Each entry inside it records how its data is stored and how large it is. Android supports two storage methods: stored, where bytes are kept as they are, and deflated, where bytes are compressed and expanded when read. Each entry carries two sizes: the compressed size, the bytes actually stored, and the uncompressed size, the bytes after expansion. For a stored entry the two are equal; for a deflated entry the uncompressed size is larger.
Android opens an APK by reading these records through a library called libziparchive, which sanity-checks them. One check ensures an entry’s uncompressed size does not exceed the space the file actually has. That check runs for stored entries. For deflated entries the uncompressed size only sets the size of a temporary buffer, while the data read from the file is bounded by the compressed size.
The compression method field is a 16-bit number. Android supports two values; the ZIP format allows the rest. A second library, libandroidfw, reads the entry to load it as a resource. It checks for deflated and treats everything else as stored. libziparchive checks the uncompressed size when an entry uses the stored method. libandroidfw maps the file at the uncompressed size whenever an entry is not marked deflated. An entry marked with some other method, neither stored nor deflated, falls between those two rules. libandroidfw maps it at its uncompressed size because it is not deflated, and libziparchive never checks that size because it was not stored.
Android does not copy the entry into memory. It maps the file, asking the kernel to make part of the file appear as memory. A mapping can be larger than the file; the kernel allows it because the extra space has nothing behind it. Nothing fails until something reads from that space. The first read past the real end of the file faults, and the kernel kills the process with SIGBUS, a signal sent when a process accesses invalid memory.
On a Pixel 10 running Android 17 with the Aug. 5, 2026 security patch, the crash record points at that mapped read. A few-kilobyte APK was mapped across about 16 megabytes of memory. The fault address landed about 197,000 bytes past the end of the file. The read walked off the file, and the kernel stopped it.
Two read patterns produce the crash. In the first, a process reads the entry piece by piece. Each read is bounded only by the declared size, so reads continue past the real end of the file until one touches empty space and faults. In the second, a process asks for the whole entry at once, as Android does when loading an XML resource or an app icon. Before handing the block over, Android checks alignment. If the mapped bytes are not aligned the way the processor needs, Android allocates a buffer the size of the declared length and copies that many bytes into it. The copy runs past the end of the file and faults while filling the buffer. The two paths fail in different functions but for the same reason.
Two other parts of Android get this decision right. libziparchive validates the uncompressed size correctly, but only for stored entries. ZipFileRO, a third library that maps ZIP entries, uses the uncompressed size only for stored entries and the compressed size for the rest. libandroidfw is the outlier: it splits on whether an entry is deflated instead of whether it is stored, so it maps the uncompressed size for entries libziparchive never checked. The cleanest fix, Bitdefender argues, is to allow only stored and deflate methods and reject all others as invalid.
The code that faults is not tied to one process. Many parts of Android read an app’s resources: during installation, while the system runs, and when another app inspects it. The process that crashes depends on which file inside the app is malformed and who reads it.
The manifest is the first file Android reads when installing an app. A malformed manifest crashes the installer and the install fails; the app does not land on the phone. That is all the original wild sample did: a failed install with nothing left behind.
An app also includes small resources that core system services parse when they go through the list of installed apps. Malform one of those and the service reading it runs inside system_server, the process that hosts most of Android. It crashes, Android restarts it, and on restart the service reads the same file again and crashes again. The phone does not finish starting. system_server dies and restarts every few seconds, with no app opened and nothing on screen to say which app is responsible. Rebooting does not fix it; it closes the one way out. While the phone still loops, a computer connected over ADB can sometimes delete the file between crashes, but Developer Mode must be on beforehand. After the first full kernel reboot, even that stops working because the crash happens early in the boot order. Safe mode does not help because the service reads the file before safe mode takes effect.
The same code runs in any process that reads an APK. Whichever process reads the one with the malformed entry is the process that crashes. Bitdefender reproduced and measured the persistent crash loop on current hardware. They have not seen it used against anyone.
Bitdefender outlines four ways an attacker could use the flaw.
- Disable the phone. Malform a resource a system service reads and the crash lands in system_server. The phone does not start in any usable form, and only a factory reset clears it, erasing everything on the phone. Such a capability could be misused as leverage for extortion.
- Make a malicious app impossible to remove. A working malicious app malforms its own icon. The phone keeps running, but the launcher, the app list in Settings, and the app’s own info screen all crash when they try to draw that icon. All routes to removing the app crash before they can, so the app stays installed and the malware keeps running.
- Blind security tools. A malicious app can carry the malformation so that anything inspecting it crashes. Security apps scanning a new APK, an analysis sandbox, or an automated pipeline all hand the file to the same Android parsing code and get the same crash. Because it is a native fault and not an ordinary error, the scanner cannot catch it and continue. The app is not flagged and stays on the device.
- Delivery through updates. The malformed file would not need to be present at initial review and could be introduced later through an app update, which could affect many devices at once. Bitdefender did not provide further details on this scenario.
The bug crashes processes. It does not execute code, read data, or gain permissions it did not receive. It is a denial-of-service issue. These are uses the bug enables, not attacks Bitdefender has seen in the wild.
Bitdefender reported the issue twice through the Android and Devices Vulnerability Reward Program. On Aug. 20, 2026, it submitted findings documenting installation-triggered crashes and failures in applications parsing the malformed APK. Google closed the report with a status of Won’t Fix, Not Reproducible, and described the submission as outside the program’s scope. Bitdefender continued testing and found an APK that installed successfully but caused a system service to crash when it automatically read an application resource, producing the persistent crash loop. On Aug. 25, 2026, it submitted expanded findings, including a working proof of concept and reproduction instructions. Google responded that it considered the issue outside the scope of a security update fix and had forwarded the finding to the relevant team for review and possible inclusion in a future version update.
Google has already patched a weaker version of this defect. The November 2016 bulletin, CVE-2016-6724, described a denial of service in the Input Manager Service that could let a local malicious application cause a device to continually reboot. Google rated it Moderate because it was a temporary denial of service requiring a factory reset to fix, and fixed it across Android 4.4.4 to 7.0. In 2016 Google described a condition requiring a factory reset as temporary. Bitdefender notes that Google’s current published severity guidelines describe such a condition as persistent and rate it High.
This type of bug, known as a parser differential vulnerability, has troubled Android for more than a decade. An APK is a ZIP file, and a ZIP file stores the same information, such as sizes, offsets, and compression flags, in multiple places without checking that the copies agree. Android reads an APK many times: to verify its signature, to install it, to load its resources, to run its code, and each time a security tool scans it. These are separate pieces of code, and nothing forces them to read the file the same way. Two of them reach different conclusions about the same bytes, and the result is a security bug.
Three earlier cases show the pattern. Master Key in 2013, CVE-2013-4787, put two files with the same name in an APK; Android checked the signature on the first and installed the second, so malicious code got in under a valid signature. Janus in 2017, CVE-2017-13156, made a single file a valid APK and a valid DEX at the same time; the signature check looked only at the ZIP entries and ignored extra bytes added to the front of the file, and the system then ran those bytes. BadPack in 2024 had malware authors deliberately corrupt ZIP headers so analysis tools failed to open the file while phones installed it without complaint. BadPack targets differences between what Android uses to install an APK and what analysts and security solutions use to screen an APK. Palo Alto’s Unit 42 found about 9,200 such samples in a single year, used by banking trojans including Anatsa, Cerberus, and BianLian. That is the kind of packing the original sample used.
The GhostMap flaw comes from a similar disagreement, but it does not sneak anything through. The disagreement results in a crash for the process trying to read the file.
Because the flaw is in Android itself and no fix is available as of publication, users have limited options on the device. The most practical defense is to recognize the file before the bug is triggered. The malformation is visible in the file’s structure, without installing or running the app. A scanner can distinguish a crafted file from a normal one by inspecting it, not by executing it.
Bitdefender Mobile Security detects apps with this malformation when they reach the device, whether as a downloaded file or an already installed app, and warns the user. Android’s security model does not let a third-party app block an installation or remove another app on its own, so acting on the warning rests on the user. Other security solutions may offer similar protection. Bitdefender detects this threat as Android.Riskware.Ghostmap.rA.
The warning arrives before the crafted file is read: a flagged download can be deleted before it is installed, and a flagged app can be removed while the device is still usable. But it is a race between the user and Android’s parsing speed. Since the app does not need to run, the user has little time to act.
Bitdefender reproduced the flaw on a Pixel 10 running Android 17 with the Aug. 5, 2026 security patch, build google/frankel/frankel:17/CP2A.260805.005/15828068:user/release-keys. They also reproduced it on versions starting with Android 10. From installing the app to the first crash took about a second. In one capture the cycle repeated 110 times, and the screen stayed on the boot animation the whole time. In a safe-mode run the same sequence repeated on 72 crash cycles.
A third-party app with no permissions, calling the standard getPackageArchiveInfo() to read the file, dies inside the call. The app wrapped the call in catch (Throwable). It did not run, because a native SIGBUS is not a Java exception, so the process simply died. Frame #01 is the aligned-copy path, so both crash paths are confirmed in practice.
As of publication, no fix is available. Google has not committed to a security update. Bitdefender’s assessment is that the risk is significant, given that a crafted app can render a phone unusable with no warning and no permission prompt. Users who suspect a problem and still have a usable device can remove flagged apps while the device runs. Anyone whose phone is already looping has limited options: a factory reset, or, if Developer Mode and USB debugging were enabled beforehand, an ADB-based script racing with the system-server crashes.
Bitdefender published its full findings at its Labs blog.
u open the app, by Alecsandru Cătălin DAJ, Bitdefender Labs, Nov 5, 2026
