A newly disclosed Android vulnerability, dubbed GhostMap, can push a handset into a persistent boot loop using a specially crafted app that requests no permissions at all — leaving it effectively invisible to the runtime permission reviews that users and mobile administrators have come to depend on, BleepingComputer reports.
The attack targets availability rather than data. A boot-looping device is unreachable by the owner and, in practice, by most mobile device management tooling, so a single install becomes hands-on recovery work instead of a remote fix.
The boundary is important: this is an install-time flaw. There is no drive-by payload, no link-triggered infection, and no zero-click vector, and the report describes no in-the-wild exploitation carried out without user action. Social engineering, sideloading, or an unofficial store are the realistic routes.
For BYOD and MDM administrators, the control point is therefore the install gate, not the permission dashboard — enforce app-allowlisting, restrict approved sources, disable sideloading on managed endpoints, and keep tested recovery procedures (recovery mode, reflash, factory reset) ready before they are needed.
據 BleepingComputer 報道，一項新披露、代號 GhostMap 的 Android 漏洞，可透過一個完全不索取任何權限的特製應用程式，令手機陷入持續的 boot loop（開機循環），從而令該應用在用戶及流動裝置管理員所依賴的執行期權限審查中形同隱形。
該攻擊針對的是系統可用性（availability），而非資料外洩。陷入開機循環的裝置，機主無法使用，實際上亦無法由大部分流動裝置管理（MDM）工具遙距存取，因此一次安裝便會演變成需要親身處理的復原工作，而非可遙距修正的問題。
攻擊邊界相當重要：這是一項安裝時（install-time）缺陷，不存在 drive-by 載荷、連結觸發感染或 zero-click 攻擊途徑，報告亦未提及任何無需用戶互動的野外實際利用案例。社交工程、側載（sideloading）或非官方商店，才是現實可行的攻擊路徑。
對於 BYOD 及 MDM 管理員而言，控制點因此是安裝關卡，而非權限儀表板——應強制執行應用程式允許清單（app-allowlisting）、限制已核准的安裝來源、在受管理終端上停用側載，並在實際需要之前預先準備好經測試的復原程序（recovery mode、重新刷寫韌體、出廠重設）。