Bitdefender has gone public with GhostMap, an Android flaw that can push a phone into an endless crash loop when a crafted app is merely installed, after Google twice declined to treat it as a security bug. The case raises an awkward question for researchers and defenders alike: when is a persistent denial of service “in scope” for a bug bounty programme?
What happened
On 5 November 2026, Bitdefender Labs published research on a weakness it calls GhostMap. According to the Romanian security firm, an Android app that contains no executable code, requests no permissions and is never launched can still leave a handset unusable. Once installed, it causes a core operating system process to fall over, restart and fall over again, trapping the device on its boot animation. Safe mode does not break the cycle, and Bitdefender says recovery will usually mean a factory reset and the loss of anything stored only on the phone.
The work started on 12 August, when a packed banking malware sample kept crashing Bitdefender’s analysis emulators. The researchers traced the fault to Android itself, then showed it could be aimed at a system service to create the persistent loop.
The disclosure history is the part that matters most for the bug bounty community. Bitdefender submitted the issue through Google’s Android & Devices Vulnerability Reward Program on 20 August. That report was closed as “Won’t Fix (Not Reproducible)” and described as outside the programme’s scope. Five days later the firm sent a fuller report, this time including proof-of-concept material and steps to reproduce it. Google’s answer, as Bitdefender reports it, was that the problem sat “outside the scope of a security update fix”, with the finding passed to a feature team for possible inclusion in a future Android release. There is no patch and, as far as published sources show, no CVE. BleepingComputer said it had asked Google about a fix and was still awaiting a reply at publication.
The technical picture
An Android package is simply a ZIP archive, and several separate components open it at different stages: signature verification, installation, resource loading and security scanning. GhostMap is what researchers call a parser differential. Two Android libraries interpret the same metadata about an archive entry in slightly different ways, and the gap between their rules allows a malformed entry to slip past a sanity check. When the system later reads that entry, it reaches beyond the real end of the file and the process is killed by the kernel.
Which process dies depends on which file inside the package is malformed. Target the manifest and installation fails. Target a resource that system services read routinely and the failure hits system_server, the process hosting most of Android, so the device never finishes booting. Bitdefender stresses that the bug does not run code or steal data, and it has seen no attacks using it.
Bitdefender demonstrated the loop on Google’s own Pixel 10, running Android 17 with the August 2026 security patch, and says every version from Android 10 onwards is affected. It also points out that Google fixed a weaker reboot-loop flaw, CVE-2016-6724, back in 2016 and rated it Moderate. Bitdefender argues that Google’s current severity guidance would treat a condition needing a factory reset as persistent and therefore High.
Why it matters for UK organisations
Android handsets are everywhere in UK workplaces: corporate fleets, rugged devices in logistics, shared tablets in retail and healthcare, and countless personal phones used for email and authenticators. A device that has to be wiped is more than an inconvenience if it holds a passkey, an authenticator seed or locally cached data that was never backed up.
There is also a governance angle. Cyber Essentials expects in-scope devices, including mobiles that access organisational data, to run supported software with security updates applied promptly. That control assumes the vendor ships a fix. When a platform owner decides a flaw is not a security issue, there is nothing to patch, and the burden moves to configuration and user behaviour. For organisations that lean heavily on “keep it updated” as their mobile strategy, GhostMap is a reminder that updates only cover what the vendor chooses to class as a vulnerability.
Expert view
Scoping disputes are as old as bug bounties themselves, and denial of service sits right in the grey zone. Most programmes exclude it for good reason: they do not want hunters hammering production services or submitting trivial crashes. But there is a big difference between an app that briefly crashes and a condition that bricks a device until it is wiped. In my experience, the reports that cause the most friction are exactly these, where the impact is serious but does not fit neatly into code execution, data exposure or privilege escalation.
The first closure is the more worrying one. “Not reproducible” on a bug that Bitdefender says reproduces on a recently patched flagship suggests triage did not get far, and that is a pattern hunters have complained about all year as AI-generated reports swamp programmes. When researchers believe a credible finding has been waved away, the rational move is public disclosure, which is what happened here. To be fair to Google, a platform owner may legitimately decide a fix belongs in a feature release rather than a monthly bulletin, but defenders are now left with a public flaw and no patch.
For anyone running a vulnerability disclosure programme, the lesson is to define severity by real-world consequence, not by bug class. If your own policy would quietly close a report that leaves a customer’s device or account unusable, it is worth revisiting before a researcher does it for you in public.
What to do now
- Restrict sideloading. Use your mobile device management platform to block installs from unknown sources on managed Android devices and limit apps to Google Play or a managed store. This maps to the Cyber Essentials secure configuration and malware protection controls.
- Back up what lives only on phones. Make sure authenticator apps, passkeys and work data can be restored, and that staff know how to re-enrol a wiped device quickly.
- Check your mobile security tooling. Ask your vendor whether it detects GhostMap-style malformed packages. Bitdefender says its product flags them, but a warning still relies on the user acting before the file is read.
- Brief users. Remind staff not to install APKs sent by message, email or third-party sites, and to report any device stuck restarting rather than attempting fixes themselves.
- Review your own VDP. If you run a disclosure or bounty programme, check that persistent denial of service against customers is assessed on impact and not rejected by default.
Bottom line
GhostMap is not a data-stealing or code-running bug, and there is no sign it is being exploited. Its significance lies in the disclosure: a well-documented flaw, reproduced by Bitdefender, that can force a factory reset was ruled out of scope by Google’s reward programme and is now public with no fix. UK organisations should tighten app installation controls on Android now, and anyone running a bounty programme should ask whether their own scope rules would have made the same call.
Sources
- Bitdefender Labs: GhostMap: The Android flaw that crashes your phone before you open the app
- Bitdefender: GhostMap: A single app installation can leave your Android phone needing a factory reset
- BleepingComputer: GhostMap Android flaw lets malicious app trigger persistent boot loop
- Android Authority: Android GhostMap flaw could leave phones stuck in crash loops
- CyberInsider: Unfixed GhostMap Android flaw can trap phones in crash loops
