Skip to navigation

Threat reportVulnerabilityTL-2026-5312

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

mediumMONITORING

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.

Key facts for GhostMap Android crash loop

IdentifiersTL-2026-5312, CVE-2016-6724, CVE-2013-4787, CVE-2017-13156
Also known asGhostMap
SeverityMEDIUM
First disclosed
Exploitation statusPublic proof-of-concept exploit
EPSSCVE-2017-13156: 20.4% (97.5th percentile); CVE-2013-4787: 13.5% (96.4th percentile); CVE-2016-6724: 0.3% (34.0th percentile)
Affected productsGoogle Android (libziparchive, libandroidfw)
Weaknesses (CWE)CWE-125, CWE-20
MalwareAnatsa, Android banking dropper (unnamed), Android.Riskware.Ghostmap.rA, Bianlian, Cerberus - S0480
Toolsadb
MITRE ATT&CK techniquesT1406 Obfuscated Files or Information, T1406.002 Obfuscated Files or Information: Software Packing, T1629.001 Impair Defenses: Prevent Application Removal, T1633 Virtualization/Sandbox Evasion, T1642 Endpoint Denial of Service, T1664 Exploitation for Initial Access
MotivationUNKNOWN
Target sectorsconsumer, finance, enterprise mobility
Target regionsGlobal
Detection rules9 (1 shown free)
Sources10 cited sources

Detection coverage for GhostMap Android crash loop

As of 2026-11-05, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5312 across Splunk SPL, Microsoft KQL and Sigma, covering 11 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: GhostMap SIGBUS crash in system_server, package installer or APK asset-read path (malformed APK ZIP entry)

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

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

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

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. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)
  • GhostMap crash within 2 minutes of an app install or update (stealth deployment via app update / sideload) · unlock with TL Creds
  • GhostMap crash loop persisting across reboot and Safe Mode (device never reaches boot completed) · unlock with TL Creds
  • Analysis sandbox or emulator crash on APK install (GhostMap / packer-driven sandbox evasion) · unlock with TL Creds
  • GhostMap [indicator] asset-read SIGBUS backtrace (generic process) · unlock with TL Creds
  • Malformed APK ZIP entry: unsupported compression method or oversized declared length (GhostMap static check) · unlock with TL Creds
  • ADB recovery deletion of APK or package uninstall for a device in a GhostMap crash loop · unlock with TL Creds
  • GhostMap persistent system_server crash loop (restart every 3-6 seconds, new PID each time) · unlock with TL Creds
  • Mobile threat defense alert for GhostMap / BadPack tampered APK structure and related banking trojans · unlock with TL Creds

Indicators of compromise for GhostMap Android crash loop

As of 2026-11-05, Threadlinqs Intelligence tracks 11 indicators of compromise for TL-2026-5312.

11 indicators of compromise · unlock with TL Creds. Compare plans

How GhostMap Android crash loop works

No CVE is assigned and no in-the-wild exploitation was observed.

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 techniques by tactic:

Defense Evasion

T1406 Obfuscated Files or Information; T1406.002 Obfuscated Files or Information: Software Packing; T1629.001 Impair Defenses: Prevent Application Removal; T1633 Virtualization/Sandbox Evasion

Impact

T1642 Endpoint Denial of Service

Initial Access

T1664 Exploitation for Initial Access

Remediation for GhostMap Android crash loop

Patches

  • No vendor patch available; Google classified the report as Won't Fix (Not Reproducible) and out of scope for a security update

Immediate actions

  • Install apps only from Google Play and other trusted stores; avoid sideloading APKs from unknown sources
  • Enable Developer Mode and USB debugging on devices where an ADB recovery path is acceptable, since ADB deletion of the malicious file is only possible if debugging was enabled beforehand
  • Use mobile security software that inspects APK structure before installation (Bitdefender Mobile Security detects it as Android.Riskware.Ghostmap.rA)

Workarounds

  • Factory reset the device to clear a persistent crash loop (erases all data)
  • Delete the malicious APK over ADB between crashes (requires Developer Mode enabled before the loop; ineffective after reboot)

Longer-term hardening

  • Have MDM and mobile threat defense products reject APKs whose ZIP entries declare a compression method other than stored (0) or deflated (8)
  • Track Google's response; Bitdefender reports the issue was referred to a feature team for possible future consideration
  • Keep device backups current because factory reset is the primary recovery path

Affected and fixed versions

  • Google — Android (libziparchive, libandroidfw)
    Vulnerable versions: Android 10 through Android 17, including Pixel 10 on Android 17 at the August 5, 2026 security patch level (tested)

Timeline of GhostMap Android crash loop

  • Android Master Key (CVE-2013-4787) ZIP-parsing flaw disclosed; Bitdefender cites it, with Janus (CVE-2017-13156), as earlier APK/ZIP parsing abuse
  • Google's November 2016 Android bulletin fixes CVE-2016-6724 (Input Manager Service DoS, rated Moderate, factory reset required), cited by Bitdefender as precedent for a persistent-DoS class defect
  • Unit 42 publishes BadPack research: about 9,200 APKs with tampered ZIP headers (compression method and size fields) seen June 2023 to June 2024, used by locked-ioc-8, locked-ioc-9 and locked-ioc-10 banking trojans against analysis tools
  • Android security patch level (August 5, 2026) on the Pixel 10 / Android 17 device on which Bitdefender reproduced the crash loop
  • Bitdefender begins investigating after a banking dropper found in the wild crashes its analysis emulators during installation; packer-rewritten APK structure identified as the cause
  • Bitdefender submits the first report to Google; it is closed as Won't Fix (Not Reproducible)
  • Bitdefender resubmits with a working proof-of-concept and reproduction steps; Google deems it outside the scope of a security update fix and refers it to a feature team for possible future consideration
  • As of publication Google does not plan a security update; no CVE or CVSS assigned and recovery remains factory reset or locked-ioc-11 file deletion between crashes
  • Bitdefender Labs publishes the GhostMap research; BleepingComputer, Help Net Security and Android Authority report no fix has been released and no in-the-wild exploitation has been observed

Sources cited for GhostMap Android crash loop

Drafted by the Threadlinqs research pipeline from 10 sources; published ; last updated —.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level

Latest Threats