GhostMap: Malformed APK Resources Can Trap Android Devices in a Persistent Boot Loop

1. Basic Information

• Article Title: GhostMap: The Android flaw that crashes your phone before you open the app
• Publisher: Bitdefender Labs
• Publication Date: 2026-11-05
• Original Source: Bitdefender Labs
• Related Sources: BleepingComputer: GhostMap
• Related Malware: A banking dropper sample prompted the investigation; intentional use of GhostMap by its author has not been established.
• Related Threat Actor: None identified
• Related CVE: None reported
• Affected Products: Android 10 and later, according to Bitdefender's assessment; testing included Android 17. Relevant components include libziparchive, libandroidfw, and system_server.
• Severity: High

2. Executive Summary

GhostMap is a mismatch between how Android libraries interpret an APK entry's compression method and declared uncompressed size. A crafted APK can install successfully, then cause system_server to crash when a system service reads a malformed resource.

The researchers demonstrated a persistent crash loop without launching the app, executing its code, or granting it permissions. Recovery may require a factory reset, with loss of data that has not been backed up. The persistent variant was demonstrated in research; its use in real attacks has not been observed.

3. Attack Flow

How the Parsers Disagree

An APK is a ZIP archive. The failure involves an entry whose compression method is neither stored (method 0) nor deflated (method 8), combined with an oversized declared uncompressed length.

Creating an oversized mapping does not itself cause the crash. The failure occurs when code reads the part of the mapping beyond the actual file.

Persistent Denial of Service Demonstrated in Research

1. A user or an application-management channel installs the crafted APK. The app does not need to launch or receive permissions.
2. A system service in system_server automatically reads a malformed resource from the installed package. The report does not identify every possible service or resource filename.
3. libandroidfw maps the entry using its oversized declared length. A subsequent read beyond the real file's end triggers SIGBUS.
4. The critical process crashes, causing a system restart.
5. After restarting, Android reads the installed package again and repeats the failure. In the demonstrated persistent variant, safe mode did not provide a way to recover.

The banking dropper that originally prompted the investigation caused an installation failure. The persistent system_server crash loop was a separate demonstration developed by the researchers.

4. Threat Actor Location and Execution Site

• Attacker Position: An attacker would need a way to distribute a crafted APK and have it installed on the target device. No real distribution campaign for the persistent variant has been reported.
• Fault Location: The failure occurs in an Android system service within system_server, rather than through execution of the app's own code.
• Required App Permissions: The demonstrated APK required no permissions.

5. Victim and Administrator Visibility

Victim

• The device may freeze or repeatedly restart after installation or during startup.
• The persistent variant can prevent access to the normal interface and uninstall controls.
• Safe mode did not recover the researchers' affected device.

Administrator

• Available crash records may show repeated SIGBUS failures in system_server.
• Visibility depends on whether logcat, tombstones, bugreports, or management telemetry remain accessible.
• File managers or scanners that use the same affected parser can also crash when reading the malformed entry. This does not mean every tool will fail or that all failures occur simultaneously.

6. Success and Failure Conditions

Conditions, Controls, and Recovery Limits

Success Conditions

• A crafted APK is installed on an affected Android implementation.
• A system service reads the malformed resource.
• The installed resource remains available for repeated parsing after restarts.

USB debugging and recovery timing affect recovery options; they are not prerequisites for the initial parser failure.

Conditions That Prevent or Limit the Impact

• Installation controls prevent the untrusted APK from being installed.
• A pre-installation scanner detects the structural inconsistency without invoking the vulnerable parser, and the file is quarantined before installation.
• If USB debugging was already enabled, ADB-based removal may be possible before the first full kernel reboot. The researchers reported that this recovery route was no longer available after that reboot.

An ordinary third-party app's warning does not, by itself, give it authority to block another app's installation or remove that app.

7. What Happens Upon Success

• Repeated system_server crashes can make the device unusable.
• Recovery may require a factory reset, potentially destroying local data that has not been backed up.
• Scanners and analysis systems may also suffer denial of service if they read the file through an affected parser.

The demonstrated effect is persistent denial of service. It does not establish hardware damage, arbitrary code execution, or data theft.

8. Observable Logs

The following are possible investigation sources, not indicators of an observed GhostMap campaign. Availability depends on collection settings and whether the device remains accessible.

• Email: Messages containing the APK or a download link, if that delivery route was used.
• Proxy / SWG / DNS: The APK download source. No campaign-specific distribution indicators were reported.
• Endpoint / EDR: Package installation events, parser crashes, system_server failures, and repeated restarts.
• Identity / IdP: No specific identity-provider event was identified for this mechanism.
• SaaS / Cloud: MDM installation records, changes in device state, missing check-ins, and later re-enrollment.
• Network: APK download traffic before the failure.
• Device Crash Records: Available logcat output, tombstones, and bugreports containing SIGBUS and the relevant resource-reading stack.

A missing MDM heartbeat alone does not establish exploitation.

9. Determining Attack Success

• Installation Confirmed — Local Assessment Criterion: An installation event or package evidence confirms that the crafted APK reached the device. Launching the app or granting permissions is not required.
• Persistent Failure Demonstrated — Public Research Evidence: Bitdefender reproduced a persistent system_server crash loop in its test environment.
• Persistent Failure Confirmed — Local Assessment Criterion: Correlate repeated crashes with the installed malformed package and the affected resource-reading path.

Separate an installation failure, a single process crash, a persistent system crash loop, and actual data loss. The public demonstration does not establish exploitation against third-party victims.

10. Investigation Playbook

• Trigger: Repeated restarts after an APK installation, system_server SIGBUS crashes, or unexplained APK-scanner failures.
• Initial Checks: Identify the most recently installed package, its source and hash, the Android build, USB-debugging status, and MDM enrollment.
• Device Evidence: Preserve accessible logcat output, tombstones, bugreports, and package-manager records. Do not assume that fastboot or recovery mode provides ordinary Android logcat access.
• Management Review: Check the distribution source, other devices that received the same APK, and changes in management or compliance state.
• Scope Assessment: Search for the same package or hash and check whether analysis systems also failed on it.
• Containment and Recovery: Stop further distribution, assess network isolation, and determine whether the limited ADB recovery option is still available. If recovery is not possible, plan a factory reset and reprovisioning after checking backup availability.
• Classification: Record the confirmed failure stage and any data loss separately.

11. Defense and Detection Ideas

These are defensive proposals based on the mechanism, rather than controls proven effective across all deployments.

• Single-Event Detection: Investigate SIGBUS failures associated with APK or resource parsing.
• Correlation: Link APK acquisition, installation, and repeated system_server restarts.
• Hunting: Statically inspect suspicious APKs for compression methods other than 0 or 8 and inconsistent declared lengths.
• Safer Inspection: Avoid relying exclusively on the affected Android parser to validate potentially malformed packages.
• Installation Controls: Restrict untrusted APK installation through the management controls available for the device's enrollment mode.
• Operational Preparation: Maintain backups, replacement-device procedures, and a recovery plan for devices that cannot receive remote commands.

The report does not establish that Google Play Protect detects or blocks this specific technique.

12. Facts / Inference / Hypothesis

Facts

• Bitdefender reproduced the persistent failure on a Pixel 10 running Android 17 with the August 5, 2026 security patch, and assessed Android 10 and later as affected.
• A banking dropper sample prompted the investigation by crashing the installer. The researchers found no evidence that its author intended to trigger GhostMap.
• The researchers' persistent variant repeatedly crashed system_server, and safe mode did not provide recovery.
• According to Bitdefender, Google considered the report outside the scope of a security-update fix and referred it to a feature team for possible consideration.

Inference

• Mobile security tools and analysis sandboxes using the affected native parser could also crash. Analysis failures should therefore be investigated rather than automatically treated as harmless processing errors.

Hypothesis

No additional hypotheses. Unconfirmed matters are listed under "Open Questions and Further Investigation".

13. MITRE ATT&CK Mapping

14. Open Questions and Further Investigation

• Whether the feature-team referral will lead to a fix, and which release would contain it, remain unknown.
• Differences among device vendors and reproducibility across every device have not been established.
• Use of the persistent variant in real attacks has not been observed.

15. Impact on SOCs and Organizations

Organizations managing Android devices should plan for both service disruption and possible loss of local data if recovery requires a factory reset. Restricting untrusted installations, forwarding APK-analysis failures to the SOC, and maintaining backups and rapid reprovisioning procedures are practical priorities.

The device becoming unusable does not itself prove that data has already been destroyed. Data-loss assessment should consider the recovery action taken and available backups.

16. Summary by Role

• SOC: Correlate APK-scanner failures, repeated system_server SIGBUS events, and restarts following installation.
• Administrators: Restrict untrusted installations, use managed distribution, maintain backups, and prepare factory-reset and reprovisioning procedures.
• Users: Do not install APKs from unknown sources. If a device repeatedly restarts, contact support rather than continuing recovery attempts without guidance.