Android pourrait restreindre l'ADB local : ce qui menace vos workflows dev

Sur Google IssueTracker, un commentaire laissé par un mainteneur ADB de Google a suffi à faire s'affoler toute la communauté Android : celle des développeurs qui installent Shizuku, qui bricolent avec Termux, ou qui scriptent leurs tests directement depuis leur téléphone. L'information vient d'un billet du développeur Kitsumed, auteur de ShizuCallRecorder (une application basée sur Shizuku), qui documente un fil de discussion en cours sur le suivi de bugs public de Google.

Précision qui compte avant d'aller plus loin : ce n'est pas une annonce officielle de Google. C'est une feature request ouverte sur l'IssueTracker, à laquelle un employé Google travaillant sur ADB a répondu avec une proposition qui va plus loin que prévu. Rien n'est acté. Mais si une partie de votre workflow de debug ou d'automatisation mobile repose sur une connexion ADB locale, le sujet mérite votre attention, et surtout votre vigilance sur la suite des événements.

Rappel express : ADB et « ADB on-device », c'est quoi ?

ADB, pour Android Debug Bridge, est le protocole créé par Google pour donner aux développeurs un accès privilégié à un appareil Android : tester le comportement d'une application, exécuter des commandes système, activer des permissions normalement inaccessibles. Il fonctionne selon trois modes :

• USB : le mode historique, câble entre l'ordinateur et le téléphone.
• TCP/IP : ADB fonctionne sur le réseau via une adresse IP et un port (généralement 5555), en clair, avec une simple validation OUI/NON. Il faut déjà avoir une connexion ADB active pour l'activer.
• Wireless Debugging (Wifi 1.0/2.0), introduit avec Android 11 : un appairage par code ou QR code établit ensuite une connexion authentifiée et chiffrée, sans besoin d'une connexion ADB préalable.

L'« ADB on-device » (terme non officiel) désigne une pratique différente : au lieu d'utiliser un ordinateur séparé, le développeur fait tourner le client ADB directement sur son téléphone, via un émulateur de terminal comme Termux, et se connecte à son propre serveur ADBD via l'adresse de bouclage 127.0.0.1. Cette astuce, née du besoin de développeurs sans accès à un second appareil, a donné naissance à tout un écosystème open source : libadb-android de MuntashirAkon, et surtout Shizuku de RikkaApps, qui permet à de nombreuses applications d'obtenir des permissions élevées sans root.

Le déclencheur : une faille de sécurité bien réelle

Le fil de discussion part d'une bonne intention. Une feature request propose de laisser les développeurs choisir sur quelle interface réseau ADBD (le démon serveur d'ADB) doit s'exposer, plutôt que de s'exposer par défaut sur toutes les interfaces réseau du téléphone. Cette proposition fait suite à une faille identifiée sous la référence CVE-2026-0073, qui permettait de contourner entièrement le processus d'authentification du Wireless ADB. Réduire la surface d'exposition d'ADBD est, sur le principe, une excellente idée.

Le problème : une piste qui va plus loin qu'un simple correctif

Ce qui inquiète la communauté ne vient pas de la feature request elle-même, mais de la réponse apportée par un mainteneur ADB de Google sur le fil. Il y évoque la possibilité de restreindre ADBD à ne se lier qu'à l'interface wlan0 (le Wifi), en expliquant que les connexions vers localhost ont aussi servi de point d'entrée à des exploits d'élévation de privilèges. Concrètement, une telle restriction casserait d'un coup l'ADB on-device, l'ADB via VPN, l'ADB via Ethernet, et une bonne partie des configurations de développement un peu atypiques.

L'autre point qui interroge, c'est la façon dont l'ADB on-device semble perçu en interne : comme un vecteur d'exploitation avant tout, alors qu'il sert une quantité d'usages parfaitement légitimes. Les développeurs qui n'ont pas d'ordinateur sous la main l'utilisent au quotidien. Kitsumed lui-même explique avoir construit ShizuCallRecorder pour compenser un handicap, un cas d'usage aussi légitime qu'inattendu.

Pourquoi l'ADB local n'est pas vraiment l'outil des attaquants

Le raisonnement mérite d'être détaillé, parce qu'il désamorce l'argument sécuritaire brut. Une application malveillante ne peut pas établir seule une connexion ADB on-device : il lui faut plusieurs actions humaines délibérées en amont.

Scénario 1, l'utilisateur Android classique : il installe une application malveillante. ADB est désactivé par défaut, ADBD ne tourne pas, et l'application n'a pas la permission WRITE_SECURE_SETTINGS, qui ne peut être accordée que manuellement via ADB. Aucune tentative d'exploitation n'est possible.

Scénario 2, le développeur sous Android 11+ utilisant le Wireless ADB : il faut d'abord installer l'application malveillante, puis activer manuellement le débogage USB (ce qui démarre ADBD), puis activer manuellement le Wireless ADB. Trois actions volontaires et distinctes avant qu'une quelconque surface d'attaque existe.

Dans les deux cas, la présence d'un être humain qui active consciemment ces fonctionnalités change complètement le calcul de risque, comparé à une faille exploitable à distance sans interaction.

Ce qui est concrètement en jeu pour vous

Si la piste « wlan0 uniquement » se concrétisait telle quelle, plusieurs usages développeur en pâtiraient directement :

• Les applications basées sur Shizuku, qui reposent sur une connexion ADB en boucle locale pour obtenir des permissions élevées sans root.
• Les projets construits sur libadb-android et les clients ADB tournant dans Termux.
• L'automatisation de tests directement sur l'appareil, sans ordinateur compagnon, pour les développeurs qui travaillent uniquement depuis leur téléphone.
• Les configurations ADB via VPN ou Ethernet, qui n'utilisent tout simplement pas l'interface wlan0.
• Sur un appareil connecté uniquement en données mobiles, sans Wifi actif, la restriction reviendrait à désactiver purement et simplement toute connexion ADB locale.

Comment réagir dès maintenant

Rien n'est décidé, donc pas de panique ni de migration en urgence. Trois réflexes utiles :

• Si vous avez un cas d'usage précis et documenté, partagez-le en commentaire sur l'IssueTracker avec des détails techniques concrets : workflow, liens, éventuelles pistes de compromis. C'est ce type de retour qui pèse dans ces discussions.
• Si votre cas d'usage a déjà été évoqué par quelqu'un d'autre, inutile de le répéter : un simple +1 sur l'issue et l'activation des notifications suffisent à faire remonter le signal sans noyer le fil.
• Si vous développez un outil ou un produit qui dépend uniquement de l'ADB en boucle locale, gardez un plan B viable : un poste de travail compagnon capable de piloter l'appareil en USB ou en Wireless Debugging classique reste la solution la plus robuste à long terme.

Notre lecture chez CZSyn

On voit régulièrement, chez des équipes qui développent des applications Android ou qui intègrent de l'automatisation mobile dans leurs outils internes, une dépendance croissante à ce type de bricolage on-device : pratique, gratuit, mais construit sur une brique que Google ne considère visiblement pas comme un cas d'usage de première classe. Ce que révèle cette discussion, au-delà du sujet ADB lui-même, c'est un déséquilibre classique entre sécurité par construction et écosystème open source qui s'est construit par-dessus une faille de conception. Google a raison de vouloir corriger la CVE-2026-0073. La question est de savoir si le correctif passera par une option de configuration fine, comme le propose la feature request initiale, ou par un verrouillage brutal d'une interface réseau, comme l'a suggéré un seul mainteneur dans un commentaire.

Pour une PME ou une équipe de développement qui construit des outils internes reposant sur Shizuku ou sur un client ADB en local, notre conseil est simple : ne bâtissez rien de critique sur cette seule brique. Gardez toujours un chemin de secours via un poste compagnon en USB. Et si votre usage est légitime et bien identifié, prenez cinq minutes pour l'expliquer sur l'IssueTracker plutôt que de découvrir la restriction le jour où elle atterrit dans une mise à jour de sécurité.

Sources primaires

• Kitsumed, « Android May Soon Restrict On-Device ADB, Affecting Shizuku, libadb and Developers ».
• Documentation officielle Android, « Android Debug Bridge (adb) ».
• Projet officiel Shizuku sur GitHub.