A newly disclosed Android flaw called GhostMap can leave a phone trapped in a persistent crash loop after the user installs a specially crafted app, even if the app is never opened and requests no permissions, according to Bitdefender researchers.
The company published its findings on November 5, 2026, saying it reproduced the problem on Android 10 and later, including a Pixel 10 running Android 17 with the August 5, 2026 security patch. Recovery may require a factory reset that erases locally stored data.
The distinction between a demonstrated vulnerability and an observed attack matters here. Bitdefender discovered the underlying parsing problem while examining a banking-malware sample, but said it had not seen attackers use the persistent crash-loop technique against victims. Its researchers developed that more disruptive version themselves.
An installation can trigger the crash
In its technical report, Bitdefender explains that GhostMap affects Android’s handling of information inside an APK, the package format used to distribute Android applications.
An APK contains more than executable code. It also stores metadata and resources that Android reads while installing an app, displaying its icon and managing installed applications. A flaw in that processing can therefore trigger before the user taps the app or grants access to contacts, photos or other protected information.
The researchers built a demonstration package with no executable code and no requested permissions. After installation, a system service automatically read a malformed resource and crashed. Restarting the service caused it to read the same resource again, repeating the failure.
On the tested Pixel, the first crash arrived about 1 second after installation. The researchers recorded 110 repeated crashes in 1 capture. That is evidence from their demonstration, not a count of affected users or a measurement that applies to every Android device.
Why 2 Android parsers disagree
The underlying weakness involves inconsistent interpretations of compression and size fields in ZIP entries. APKs use the ZIP format, which records how individual entries are stored and how large their contents should be.
Android normally handles entries that are stored without compression and entries compressed using the deflate method. Bitdefender found that 2 Android libraries treated other compression-method values differently.
The first library, libziparchive, applied a relevant size check to entries explicitly marked as stored. A second library, libandroidfw, treated an entry as stored whenever it was not marked as deflated. An unexpected method value could fall between those rules, leaving a declared length insufficiently checked.
As a result, Android could map a region of memory larger than the actual file contents. The failure occurred when a process tried to read beyond the bytes backed by the file. The operating system terminated that process with a native SIGBUS fault.
This is not a finding that an app can execute arbitrary code, steal data or gain administrator rights. Bitdefender describes a denial-of-service issue: the dangerous effect is repeated process failure and loss of access to the device.
The reader determines the damage
The original banking-malware sample that drew the researchers’ attention did not produce the persistent system loop. Its malformed package caused installation to fail. Bitdefender said nothing in the sample suggested its author understood the crash behavior.
Further testing showed that the outcome depended on which Android component encountered the malformed resource. A failure in the installer could stop installation. A failure in an ordinary app inspecting the package could terminate that app instead.
The more serious demonstration reached system_server, a process that hosts important Android services. When a service in that process restarted and inspected the installed package again, it triggered another failure before the phone could return to a usable interface.
Bitdefender also describes potential consequences for application scanners and analysis infrastructure that rely on the affected Android parsing code. A scanner process can crash while inspecting a package instead of completing its analysis. These possible uses should not be mistaken for a confirmed campaign.
Rebooting and safe mode did not restore access
A normal restart leaves the installed package on the device. Once the same service encounters the same malformed resource during startup, the crash can repeat.
Safe mode did not solve the problem in Bitdefender’s tests. The researchers recorded the relevant service failing before safe mode could provide a usable recovery path, including a run with 72 repeated crash cycles.
Removing the offending file through Android Debug Bridge, or ADB, offered only a narrow recovery opportunity. USB debugging had to be enabled beforehand, and removal had to happen between service crashes. Bitdefender said a full kernel reboot could close even that opportunity because the failure then occurred too early in startup.
That limited laboratory recovery path is not a reason for ordinary users to enable USB debugging broadly. A factory reset may be the practical recovery option, and files that have not been backed up could be lost. Users should seek device-specific guidance before taking a destructive recovery step.
Google’s response is reported by the researchers
Bitdefender dates its initial discovery to August 12, 2026. It submitted a first report to Google on August 20 and an expanded report, including the persistent crash-loop demonstration, on August 25.
According to Bitdefender, Google closed the initial submission as not reproducible and outside the reporting program’s scope. The researchers said Google’s response to the expanded submission treated the issue as outside the scope of a security-update fix and referred it to a feature team for possible consideration in a future version.
Those statements describe Bitdefender’s account of its disclosure correspondence. They do not establish that Google has independently confirmed every tested device or published a universal recovery procedure.
Bitdefender said no fix was available when it published the research. The report does not establish that every device running an affected Android version behaves identically, and installing current security updates should not be described as a verified GhostMap fix.
Reduce exposure before a package is installed
The practical protection starts before installation. Avoid APKs delivered through unsolicited messages, fake support instructions or untrusted download pages. An app’s lack of permission requests does not make its package harmless, because the affected processing happens outside the usual permission prompts.
Organizations that manage Android devices should review installation policies, restrict unnecessary sideloading and keep an inventory of approved apps. Security teams that analyze unfamiliar APKs should use isolated test devices and preserve a known-good recovery path rather than installing samples on everyday phones.
Bitdefender says its mobile product detects the malformed structure in its own tests. That is a vendor claim about detection, not an operating-system patch or a guarantee that a third-party security app can stop installation. Android also limits one app’s ability to remove another.
Regular, verified backups reduce the consequences of a reset. Important photos, documents and account-recovery information should remain accessible without relying on the affected phone. A backup cannot prevent the crash, but it can make recovery less destructive.
GhostMap is distinct from the mobile exploitation described in BreachNews coverage of the Plerdy watering-hole campaign targeting iOS and Android. There is no established connection between that activity and this research. The confirmed finding here is a reproducible availability failure, not an observed data breach or ransomware attack.
