GhostMap Android est une faille de déni de service local qui peut bloquer durablement un smartphone dès l’installation d’un fichier APK malformé, sans lancement de l’application ni autorisation accordée. Selon Bitdefender le 5 novembre 2026, la boucle de plantages résiste parfois au redémarrage et au mode sans échec. Une réinitialisation d’usine, avec perte des données locales, peut alors devenir nécessaire.
Qu’est-ce que la faille GhostMap Android ?
GhostMap Android est un déni de service local, c’est-à -dire une attaque qui rend l’appareil indisponible sans nécessairement voler des données. Le problème exploite l’analyse automatique d’une ressource contenue dans un fichier APK. D’après Bitdefender en 2026, l’installation suffit à déclencher les plantages, même si l’application n’est jamais ouverte.
Un fichier APK est le paquet utilisé pour distribuer et installer une application Android. Dans le cas de GhostMap, le paquet de démonstration ne contient aucun code exécutable et ne demande aucune permission. Son apparence technique rassurante ne signifie donc pas qu’il est inoffensif.
Bitdefender décrit une incohérence dans une entrée ZIP, format sur lequel repose l’APK. Les métadonnées de compression et la taille déclarée du contenu décompressé sont spécialement modifiées. Lorsqu’un composant central d’Android tente de lire cette ressource, le lecteur concerné peut s’arrêter avec un signal SIGBUS, puis recommencer après le redémarrage du service.
GhostMap n’est donc pas un malware classique cherchant à espionner l’utilisateur. La nuance compte pour une entreprise : les permissions Android ne constituent pas une protection suffisante face à un fichier conçu pour faire planter le système pendant sa propre analyse.
Comment GhostMap peut-il bloquer un smartphone sans permission ?
Le blocage provoqué par GhostMap intervient pendant le traitement automatique du fichier APK par Android. Le système inspecte certaines ressources dès l’installation, avant toute ouverture de l’application. Selon Bitdefender le 5 novembre 2026, cette analyse peut faire planter un service central en boucle, sans code exécutable et sans permission demandée.
L’utilisateur peut ainsi penser qu’il ne risque rien tant qu’il ne lance pas l’application. C’est précisément le piège. Avec GhostMap, l’action dangereuse est l’installation elle-même, notamment lorsque le fichier vient d’un lien reçu par messagerie, d’un site non contrôlé ou d’une boutique alternative.
Une fois la boucle installée, le service défaillant redémarre et rencontre de nouveau la ressource malformée. Bitdefender indique qu’en 2026 ses essais ont résisté au redémarrage normal et au mode sans échec. Si aucune méthode de suppression ne reste accessible, la réinitialisation d’usine peut être le dernier recours.
Ce scénario rappelle qu’une attaque peut viser la disponibilité plutôt que la confidentialité. Pour un terminal utilisé sur le terrain, le coût réel comprend l’arrêt de travail, la reconfiguration, la restauration des accès et l’éventuelle perte de contenus non synchronisés. Les mêmes arbitrages de continuité apparaissent dans la sécurité des plateformes numériques exposées, où l’indisponibilité constitue déjà un incident métier.
Quels smartphones et quelles versions Android sont concernés ?
Bitdefender a reproduit GhostMap sur des systèmes allant d’Android 10 à Android 17 en 2026. Le test inclut un Pixel 10 équipé d’Android 17, du correctif de sécurité daté du 5 août 2026 et de la version CP2A.260805.005. Cette plage de tests ne prouve toutefois pas que chaque modèle est vulnérable.
La portée exacte dépend notamment des composants Android intégrés par le fabricant et de leurs éventuelles modifications. Il faut distinguer « faille reproduite sur plusieurs versions » et « vulnérabilité confirmée sur tous les téléphones utilisant ces versions ».
| Élément | Constat vérifié | Conséquence pour l’entreprise |
|---|---|---|
| Versions testées | Android 10 à Android 17 selon Bitdefender en 2026 | Un parc récent ne doit pas être considéré comme protégé par défaut |
| Appareil récent testé | Pixel 10 sous Android 17, correctif du 5 août 2026 | La présence d’un correctif récent ne garantit pas l’absence de GhostMap |
| Exploitation observée | Aucune boucle persistante observée chez des victimes par Bitdefender au 5 novembre 2026 | Le risque est démontré, mais aucune campagne active n’est établie |
| Correctif public | Aucun bulletin Google ni correctif trouvé dans les sources examinées au 10 novembre 2026 | Les mesures préventives restent prioritaires |
| Récupération | Réinitialisation d’usine potentiellement nécessaire selon les tests de Bitdefender en 2026 | Les données uniquement stockées sur le terminal peuvent être perdues |
Au 9 novembre 2026, Bitdefender indiquait que Google avait rouvert le signalement et classé sa gravité au niveau High. Cette décision ne valait ni publication d’un correctif ni annonce d’une date de diffusion. Au 10 novembre 2026, les sources examinées ne mentionnaient aucun identifiant CVE public pour GhostMap.
Un précédent distinct existe : le bulletin de sécurité Android de novembre 2016 documentait CVE-2016-6724, un déni de service local dans Input Manager pouvant provoquer des redémarrages continus et imposer une réinitialisation d’usine. Ce n’est pas GhostMap, mais ce précédent confirme que les boucles de redémarrage constituent une catégorie de risque connue sur Android.
GhostMap est-il déjà exploité contre des utilisateurs ?
Aucune exploitation persistante de GhostMap contre des victimes n’avait été observée par Bitdefender au 5 novembre 2026. L’enquête provenait toutefois d’un APK de logiciel bancaire malveillant collecté dans la nature le 12 août 2026, car ce fichier faisait planter les émulateurs d’analyse. Bitdefender n’a pas établi que cet effet était intentionnel.
Cette distinction évite d’annoncer une campagne qui n’est pas démontrée. Un concept technique fonctionnel montre qu’une attaque est possible ; il ne mesure ni sa diffusion ni la probabilité qu’un collaborateur reçoive aujourd’hui un fichier conçu à cette fin.
Le calendrier du signalement mérite aussi d’être conservé. Bitdefender dit avoir informé Google le 20 août 2026, puis transmis une démonstration produisant une boucle persistante le 25 août 2026. La publication publique date du 5 novembre 2026.
Honnêtement, l’absence de campagne connue ne justifie pas un déploiement précipité d’outils coûteux. Elle justifie d’abord des règles d’installation strictes, des sauvegardes testées et une procédure d’effacement maîtrisée. C’est le même principe que pour une mise à jour de sécurité touchant Node.js : partir du périmètre réellement exposé plutôt que de la seule gravité théorique.
Comment protéger une flotte Android contre GhostMap ?
La protection la plus directe contre GhostMap consiste à empêcher l’installation d’APK provenant de sources inconnues et à distribuer les applications approuvées par une politique administrée. La documentation de Google Android Management API prévoit notamment un paramètre untrustedAppsPolicy et l’option DISALLOW_INSTALL, qui bloque ces installations sur les appareils gérés.
Un EMM ou MDM est un outil de gestion centralisée des terminaux mobiles. Avec Android Enterprise et Managed Google Play, l’entreprise peut autoriser un catalogue validé, imposer des règles et préparer l’effacement ou la remise en service d’un appareil. Le contrôle technique doit rester cohérent avec les usages : certains métiers ont besoin d’applications internes distribuées hors du Play Store public.
Les mesures prioritaires peuvent être organisées dans cet ordre :
- inventorier les versions Android, les fabricants et le statut de gestion de chaque terminal en 2026 ;
- désactiver l’installation depuis des sources inconnues lorsque le besoin métier ne la justifie pas ;
- distribuer les applications approuvées avec Managed Google Play ou une méthode interne contrôlée ;
- tester la restauration d’un appareil de travail, y compris les comptes, certificats et applications métier ;
- conserver les données professionnelles dans des services synchronisés plutôt qu’uniquement sur le téléphone ;
- surveiller les bulletins Android et ceux des fabricants jusqu’à la publication d’un correctif identifié.
Google précise dans sa documentation en 2026 que les possibilités de sauvegarde diffèrent entre les profils professionnels et les appareils appartenant à l’entreprise. Il ne faut donc pas supposer que la sauvegarde Android grand public restaurera toutes les données métier. La procédure doit être testée avec l’EMM ou le MDM réellement déployé.
Sur les projets que nous menons, nous voyons souvent une politique mobile correcte sur le papier, mais jamais testée après un effacement complet. Or le bon indicateur n’est pas « la sauvegarde est activée » : c’est le délai nécessaire pour rendre un terminal de remplacement utilisable, avec ses accès et ses applications.
Bitdefender indique que son produit Mobile Security identifie les fichiers concernés sous le nom Android.Riskware.Ghostmap.rA. Un antivirus mobile peut ajouter une détection, mais le modèle Android ne lui permet pas de bloquer de manière autonome l’installation ou la suppression d’une autre application. Le MDM et la politique d’installation restent donc les contrôles structurants.
Que faire si un téléphone Android commence à planter après un APK ?
Après l’installation d’un APK suivie de plantages répétés, l’entreprise doit isoler le terminal, interrompre les tentatives d’installation similaires et appliquer sa procédure de récupération. Pour GhostMap, Bitdefender rapporte en 2026 que le redémarrage et le mode sans échec peuvent échouer, ce qui peut imposer une réinitialisation d’usine.
Ne multipliez pas les manipulations improvisées sur un appareil contenant des données professionnelles. Notez le nom et l’origine du fichier, l’heure d’installation, le modèle, la version Android et le niveau du correctif. Ces informations aident l’équipe informatique à distinguer GhostMap d’une panne classique ou d’un autre logiciel malveillant.
Si le terminal reste administrable à distance, l’équipe chargée de la mobilité peut tenter les actions prévues par sa plateforme de gestion. Si la réinitialisation devient nécessaire, les contenus stockés uniquement en local risquent d’être effacés. Le compte professionnel, les jetons d’authentification et les certificats devront ensuite être révoqués ou réenrôlés selon la politique interne.
Côté agence, le réflexe est de traiter cet épisode comme un test de continuité : combien de temps faut-il pour fournir un autre téléphone, restaurer les applications et sécuriser les accès compromis ou perdus ? Les mécanismes humains comptent également, comme le montrent les mesures de prévention contre les messages et liens frauduleux.
Cadrer la gestion des applications, des sauvegardes et de la reprise évite qu’un fichier malformé devienne plusieurs heures d’arrêt. Un regard extérieur peut aider à tester la politique mobile et son application concrète avant qu’un incident ne l’impose.
FAQ sur GhostMap Android
GhostMap peut-il voler les données du téléphone ?
GhostMap est présenté par Bitdefender en 2026 comme un déni de service local destiné à provoquer des plantages, et non comme un mécanisme documenté de vol de données. Un APK reçu dans une situation réelle peut cependant contenir d’autres fonctions malveillantes.
Le Google Play Store distribue-t-il GhostMap ?
Aucune distribution de GhostMap par Google Play n’est établie dans les sources examinées au 10 novembre 2026. Le risque documenté concerne l’installation d’un APK spécialement construit, notamment en dehors des circuits approuvés.
Un antivirus Android suffit-il contre GhostMap ?
Un antivirus Android peut détecter un fichier GhostMap connu, mais une application tierce ne peut pas nécessairement empêcher seule l’installation d’un autre APK. Une politique MDM bloquant les sources inconnues offre un contrôle plus direct.
Une réinitialisation d’usine supprime-t-elle GhostMap ?
La réinitialisation d’usine est la méthode de récupération extrême mentionnée par Bitdefender en 2026 lorsque la boucle persiste. Elle efface les données locales et impose ensuite la reconfiguration sécurisée du terminal.