# GhostMap: Android ZIP-parsing flaw (libziparchive/libandroidfw mismatch) lets a malicious APK trigger a persistent system_server crash loop

> Bitdefender Labs disclosed GhostMap, a parser gap between two Android ZIP libraries that lets a malformed APK declare an oversized entry, causing an out-of-bounds mmap read and SIGBUS in any process that touches it, including system_server. Installing the APK is enough to cause a crash loop that survives reboot and Safe Mode; Google closed the report as 'Won't Fix (Not Reproducible)' and later called it out of scope for a security update. No CVE is assigned and no in-the-wild exploitation was observed.

- **Published:** 2026-11-05T09:43:48Z
- **Last reviewed:** 2026-11-05T09:43:48Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5312
- **Card image:** https://intel.threadlinqs.com/og/threat/TL-2026-5312.png
- **ID:** TL-2026-5312
- **Severity:** MEDIUM
- **Category:** VULNERABILITY
- **Status:** MONITORING
- **Detections:** 9 (1 shown free below) · **IOCs:** 11
- **CVEs:** CVE-2016-6724, CVE-2013-4787, CVE-2017-13156

## Description

GhostMap is a ZIP-structure parsing inconsistency inside Android. Each ZIP entry in an APK declares a 16-bit compression method and an uncompressed length. Android supports two methods, stored and deflated. Per Bitdefender, libziparchive (system/libziparchive/zip_archive.cc) validates the declared uncompressed length only when the method is kCompressStored, while libandroidfw (frameworks/base/libs/androidfw/AssetsProvider.cpp and Asset.cpp) maps the declared uncompressed length whenever the method is anything other than kCompressDeflated. An entry that carries a third, unsupported method value therefore passes both checks. A third library, ZipFileRO, correctly uses the compressed size for non-stored methods, so the libraries disagree about the same entry.

Android uses mmap to map APK entries instead of copying them into memory. When the declared length exceeds the real file contents, the mapping extends beyond the end of the file. Bitdefender's example maps an 8,408-byte file across roughly 16 MB (about 16,781,312 bytes), with the fault occurring about 197,000 bytes past the real end of the file. Reading the excess region makes the CPU raise SIGBUS (signal 7) in whichever process touches the file. Bitdefender confirmed two crash paths: streaming reads that proceed piece by piece, and aligned-copy buffer operations. The published stack trace runs from __memcpy_aarch64_simd (libc.so) through android::_FileAsset::read (libandroidfw.so) and android::NativeAssetReadChar (libandroid_runtime.so) to AssetManager$AssetInputStream.read in the framework. The affected processes include the package installer (crashes while parsing the manifest, so the installation fails), third-party apps that call getPackageArchiveInfo() on an APK, launchers and Settings apps that render a malformed app icon, and system_server, the core service that hosts most Android services. When system_server reads a malformed resource it dies and restarts every 3 to 6 seconds (Bitdefender shows new system_server PIDs such as 14536, 15070 and 15586), reads the same resource again and crashes again.

The crash loop persists across full reboots and Safe Mode does not help, because the crash occurs before Safe Mode takes effect. In Bitdefender's test on a Pixel 10 running Android 17 with the August 5, 2026 security patch, crashes began about one second after installation and the device went through 110 crashes in normal boot mode and 72 in Safe Mode before stabilizing. No app has to be opened and no permission has to be granted, and the user sees nothing that identifies the responsible app. Android's security model does not let a third-party app block an installation or remove another app, so security software cannot clean up after the fact. Recovery options are a factory reset (which erases data) or deleting the malicious file over ADB between crashes, which requires Developer Mode and USB debugging to be enabled beforehand and becomes ineffective after a reboot.

Bitdefender began investigating on August 12, 2026 after a banking dropper found in the wild crashed its analysis emulators during installation. The sample contained no executable code that caused the crash; a packer rewrote the APK structure. Bitdefender states that nothing in the sample suggests its author knew the file would crash anything, and that it has not observed anyone using the technique in the wild. Bitdefender lists four hypothetical abuse scenarios: bricking a device through malformed system-service resources, preventing uninstall by corrupting app icon or launcher resources, evading security scanners whose analysis crashes, and stealth deployment through app updates after store review. Reporting says Android 10 through Android 17 are affected (bug present in the AOSP base). Google received the first report on August 20, 2026 and closed it as 'Won't Fix (Not Reproducible)'. A second report with a working proof-of-concept on August 25, 2026 was judged 'outside the scope of a security update fix' and forwarded to a feature team for possible future consideration; Help Net Security quotes the position as 'Google does not plan a security update'. No CVE or CVSS score has been assigned and no vendor patch exists. Bitdefender Mobile Security detects the malformed files before installation as Android.Riskware.Ghostmap.rA. Bitdefender cites Google's November 2016 fix for CVE-2016-6724 (Input Manager Service denial of service, rated Moderate, factory reset required) as a precedent and argues current guidelines would rate such persistence High.

Related context: GhostMap belongs to a family of APK ZIP-header abuse. Unit 42's BadPack research (July 16, 2024) found about 9,200 samples between June 2023 and June 2024 with tampered compression method, compressed size and uncompressed size fields, used by BianLian, Cerberus and TeaBot banking trojans to defeat analysis tools such as Apktool and Jadx while Android installs them normally. Earlier ZIP-parsing flaws include Master Key (CVE-2013-4787) and Janus (CVE-2017-13156). GhostMap differs in that the malformed structure harms the Android device itself rather than the analysis tooling.

## MITRE ATT&CK

- T1664 Exploitation for Initial Access
- T1406 Obfuscated Files or Information
- T1406.002 Obfuscated Files or Information: Software Packing
- T1633 Virtualization/Sandbox Evasion
- T1629.001 Impair Defenses: Prevent Application Removal
- T1642 Endpoint Denial of Service

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**GhostMap SIGBUS crash in system_server, package installer or APK asset-read path (malformed APK ZIP entry)** (`TL-2026-5312-SPL-001`)

Behaviour-first detection of the GhostMap (TL-2026-5312) crash signature: a fatal signal 7 (SIGBUS) in system_server, the package installer, a getPackageArchiveInfo() caller, or any process whose backtrace runs through __memcpy_aarch64_simd, android::_FileAsset::read, android::NativeAssetReadChar and AssetManager$AssetInputStream.read in libandroidfw. A malformed APK ZIP entry carrying a compression method other than stored (0) or deflated (8) and an oversized declared uncompressed length passes both libziparchive and libandroidfw checks, so mmap extends past the end of the file and the read faults. The search buckets crashes per device in 10-minute windows and flags a suspected loop when system_server crashes five or more times, matching Bitdefender's observed 3 to 6 second restart cadence (110 crashes in normal boot, 72 in Safe Mode). No CVE is assigned, no vendor patch exists and no in-the-wild exploitation is known, so the rule keys on the crash itself. Requires Android logcat or tombstone data forwarded to Splunk.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1664, T1642, T1629.001
- **Data sources:** android_logs:android:logcat, android_tombstones
- **Severity:** high
- **Confidence:** high

### Splunk SPL

```spl
index=android_logs sourcetype="android:logcat" earliest=-24h "Fatal signal 7" ("(system_server)" OR "NativeAssetReadChar" OR "_FileAsset::read" OR "AssetInputStream.read" OR "libandroidfw" OR "__memcpy_aarch64_simd" OR "getPackageArchiveInfo" OR "packageinstaller") | eval crash_target=case(like(_raw,"%(system_server)%"),"system_server",like(_raw,"%ackageinstaller%") OR like(_raw,"%ackageInstaller%"),"package_installer",like(_raw,"%getPackageArchiveInfo%"),"getPackageArchiveInfo_caller",true(),"app_process") | eval asset_frame=if(match(_raw,"NativeAssetReadChar|_FileAsset::read|AssetInputStream.read|libandroidfw"),1,0) | bin span=10m _time AS bucket | stats count AS crashes sum(asset_frame) AS asset_read_frames values(crash_target) AS crash_targets min(_time) AS first_seen max(_time) AS last_seen by host bucket | eval loop_suspected=if(crashes>=5 AND isnotnull(mvfind(crash_targets,"system_server")),"yes","no") | convert ctime(first_seen) ctime(last_seen) ctime(bucket) | sort - crashes
```

### Microsoft KQL

```kql
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has "Fatal signal 7"
| where SyslogMessage has_any ("(system_server)", "NativeAssetReadChar", "_FileAsset::read", "AssetInputStream.read", "libandroidfw", "__memcpy_aarch64_simd", "getPackageArchiveInfo", "packageinstaller")
| extend CrashTarget = case(SyslogMessage has "(system_server)", "system_server", SyslogMessage has_any ("packageinstaller", "PackageInstaller"), "package_installer", SyslogMessage has "getPackageArchiveInfo", "getPackageArchiveInfo_caller", "app_process")
| extend AssetFrame = iff(SyslogMessage has_any ("NativeAssetReadChar", "_FileAsset::read", "AssetInputStream.read", "libandroidfw"), 1, 0)
| summarize Crashes = count(), AssetReadFrames = sum(AssetFrame), Targets = make_set(CrashTarget), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Computer, bin(TimeGenerated, 10m)
| extend LoopSuspected = iff(Crashes >= 5 and Targets has "system_server", "yes", "no")
| order by Crashes desc
```

### Sigma

```yaml
title: GhostMap SIGBUS Crash in system_server or APK Asset Read Path
id: a1e47c20-5b3d-4f8a-9c16-2d7b0e3f5a11
status: experimental
description: Detects a fatal signal 7 (SIGBUS) in system_server, the package installer or with libandroidfw asset-read frames, the crash signature of the GhostMap malformed-APK ZIP entry flaw (TL-2026-5312). No CVE is assigned and no vendor patch exists.
references:
    - https://www.bitdefender.com/en-us/blog/labs/ghostmap-android
    - https://www.bleepingcomputer.com/news/security/ghostmap-android-flaw-lets-malicious-app-trigger-persistent-boot-loop/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-11-05
tags:
    - attack.initial_access
    - attack.t1664
    - attack.impact
    - attack.t1642
    - attack.defense_evasion
    - attack.t1629.001
logsource:
    product: android
    service: logcat
detection:
    selection_signal:
        Message|contains: 'Fatal signal 7'
    selection_target:
        Message|contains:
            - '(system_server)'
            - 'NativeAssetReadChar'
            - '_FileAsset::read'
            - 'AssetInputStream.read'
            - 'libandroidfw'
            - '__memcpy_aarch64_simd'
    condition: selection_signal and selection_target
falsepositives:
    - Genuine memory-mapped file corruption or storage faults on the device
    - Vendor framework bugs unrelated to a malformed APK
level: high

```

**Known false positives:**

- Genuine storage or flash corruption producing SIGBUS in system_server
- Vendor ROM or OEM framework bugs that crash system_server without any malformed APK
- Device test labs or fuzzing rigs that deliberately feed malformed APKs to the parser

**Tuning notes:** The android_logs index and android:logcat sourcetype are deployment-specific; point them at your MDM or logcat forwarder (Android has no official Splunk TA, so map host to the device ID). Exclude lab devices by host. A loop_suspected=yes row means system_server crashed five or more times in 10 minutes and the device is probably stuck: trigger MDM remote wipe or ADB recovery before the data is lost. Correlate with a package install or update event in the preceding 60 seconds to identify the responsible APK. Stack frames only appear when full backtraces or tombstones are forwarded; with only the Fatal signal line the system_server and installer branches still match.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- GhostMap crash within 2 minutes of an app install or update (stealth deployment via app update / sideload) (locked: unlock with TL Creds)
- GhostMap crash loop persisting across reboot and Safe Mode (device never reaches boot completed) (locked: unlock with TL Creds)
- Analysis sandbox or emulator crash on APK install (GhostMap / packer-driven sandbox evasion) (locked: unlock with TL Creds)
- GhostMap [indicator] asset-read SIGBUS backtrace (generic process) (locked: unlock with TL Creds)
- Malformed APK ZIP entry: unsupported compression method or oversized declared length (GhostMap static check) (locked: unlock with TL Creds)
- ADB recovery deletion of APK or package uninstall for a device in a GhostMap crash loop (locked: unlock with TL Creds)
- GhostMap persistent system_server crash loop (restart every 3-6 seconds, new PID each time) (locked: unlock with TL Creds)
- Mobile threat defense alert for GhostMap / BadPack tampered APK structure and related banking trojans (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sources

- [GhostMap Android flaw lets malicious app trigger persistent boot loop (BleepingComputer)](https://www.bleepingcomputer.com/news/security/ghostmap-android-flaw-lets-malicious-app-trigger-persistent-boot-loop/)
- [GhostMap: The Android flaw that crashes your phone before you open the app (Bitdefender Labs)](https://www.bitdefender.com/en-us/blog/labs/ghostmap-android)
- [A banking malware sample led researchers to an Android bug that can loop-crash phones (Help Net Security)](https://www.helpnetsecurity.com/2026/11/05/ghostmap-android-bug-research/)
- [Android GhostMap flaw could leave phones stuck in crash loops (Android Authority)](https://www.androidauthority.com/android-ghostmap-vulnerability-crash-loop-3731355/)
- [BadPack: APK malware with tampered headers (Unit 42, related ZIP-header abuse research)](https://unit42.paloaltonetworks.com/apk-badpack-malware-tampered-headers/)
- [CVE-2016-6724 Input Manager Service denial of service (NVD, precedent cited by Bitdefender)](https://nvd.nist.gov/vuln/detail/CVE-2016-6724)
- [CVE-2013-4787 Android Master Key (NVD, related ZIP parsing flaw)](https://nvd.nist.gov/vuln/detail/CVE-2013-4787)
- [CVE-2017-13156 Android Janus (NVD, related APK/ZIP flaw)](https://nvd.nist.gov/vuln/detail/CVE-2017-13156)
- [Leaving our ZIP undone: how to abuse ZIP to deliver malware apps (Virus Bulletin 2014, Panakkal)](https://virusbulletin.com/uploads/pdf/conference/vb2014/VB2014-Panakkal.pdf)
- [Android malware Konfety evolves with ZIP manipulation and dynamic loading (Security Affairs, related context)](https://securityaffairs.com/179969/malware/android-malware-konfety-evolves-with-zip-manipulation-and-dynamic-loading.html)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-5312