OEMpocalypse donne root sur Android à une application sans aucune permission

31 août 2026. Le chercheur Lukas Maar publie OEMpocalypse, première partie d’une série qui élève n’importe quelle application Android sans permission jusqu’à root. Juillet 2026. Le firmware d’usine testé, bootloader verrouillé et Verified Boot activé, est celui que portent vos utilisateurs aujourd’hui. Deux semaines. C’est le délai avant que des outils d’exploitation publics apparaissent sur GitHub. Pourquoi c’est important : l’attaque ne touche pas le noyau Linux principal, mais le code que Samsung, Xiaomi et Oppo ajoutent par-dessus — une surface que Google ne revoit pas.

Le bug vit dans le code que les constructeurs ajoutent

La faille centrale est un use-after-free de page dans des pilotes noyau spécifiques aux OEM — le code que Samsung, Xiaomi et Oppo écrivent pour leurs fonctionnalités maison : traitement caméra, calibration d’écran, gestion thermique, IPC propriétaire. Ces pilotes vivent dans One UI, HyperOS et ColorOS, en dehors de l’AOSP et de la revue de sécurité de Google.

Un use-after-free signifie que le noyau conserve un pointeur vers une page de mémoire physique déjà libérée, ce qui autorise une écriture dans de la mémoire que l’application n’a aucun droit de toucher. L’attaque se déroule en deux étapes. D’abord, l’application exploite un défaut de logique dans les points d’entrée IPC des OEM — appels Binder, intents, content providers — pour s’échapper du domaine SELinux untrusted_app vers un processus OEM privilégié. Ensuite, elle déclenche le use-after-free de page pour obtenir une lecture/écriture arbitraire au niveau de la mémoire physique, ce qui se traduit directement par root.

Le détail qui dérange : l’exploit ne fuit pas le KASLR et ne détourne pas le flux de contrôle. Les durcissements noyau classiques — protections de slab, CFI — sont sans effet sur cette chaîne. Pire, le code de récupération de page vulnérable tourne à l’identique des noyaux 5.15 à 6.12, et chaque surcouche OEM porte sa propre instance du même bug.

Ce qui tombe, ce qui tient

L’impact est précis, et il faut le lire sans exagération.

Ce qui tombe. Le modèle de permissions Android est hors jeu : zéro permission requise. Les fenêtres FLAG_SECURE et les EncryptedSharedPreferences ne protègent rien contre une application malveillante co-installée qui lit la mémoire directement. Et la détection de root elle-même est aveugle : les outils publics GhostLock et Root-My-Galaxy, qui arment CVE-2026-43499, passent par KernelSU, conçu précisément pour tromper les contrôles Play Integrity et SafetyNet. Votre sonde de détection de root ne voit rien.

Ce qui tient. Les clés KeyStore adossées au matériel et StrongBox. Parce qu’elles vivent dans un élément sécurisé dédié que le noyau ne peut pas lire — même avec root — l’attestation adossée au matériel devient la dernière ligne de défense sur les appareils touchés. Toute application qui stocke des identifiants ou des données de santé doit vérifier qu’elle utilise du stockage de clés matériel, pas logiciel.

Le point le plus déroutant est ailleurs : Verified Boot reste au vert tout au long de l’attaque. Les contrôles d’intégrité d’appareil sur lesquels s’appuient les politiques MDM attestent de la chaîne de démarrage, pas du noyau en cours d’exécution. Un téléphone compromis après démarrage continue de présenter une attestation « saine ».

L’angle mort des correctifs

Samsung a publié son correctif de sécurité de septembre 2026 le 8 septembre, corrigeant 90 vulnérabilités. Mais les notes ne citent explicitement ni OEMpocalypse ni CVE-2026-43499. Les signalements communautaires suggèrent que les outils GhostLock ne fonctionnent que sur le firmware de juin 2026 ou antérieur — or la recherche de Maar a tourné avec succès sur le firmware de juillet 2026. Cet écart n’a pas été expliqué publiquement.

Xiaomi et Oppo n’ont émis aucune déclaration. Et il ne s’agit que de la première partie d’une série : les publications suivantes nommeront les pilotes OEM précis. « Keeping the set alive is real ongoing work », note Maar — une phrase qui se lit moins comme une réserve de chercheur que comme un avertissement : des correctifs au coup par coup ne fermeront pas la porte.

Pourquoi c’est structurel, pas conjoncturel

Ce n’est pas un bug Qualcomm, ni un bug du noyau Linux. C’est un bug dans le code que Samsung, Xiaomi et Oppo ont écrit pour livrer leurs fonctionnalités produit. Chaque personnalisation OEM qui touche au noyau est une surface d’attaque qui contourne entièrement la revue de Google. C’est le coût du modèle « constructeur qui différencie par le logiciel » : plus de fonctionnalités maison, plus de code noyau non audité.

Android Sandbox 3.0, prévu avec Android 17 via des namespaces Linux par application, pourrait resserrer le vecteur d’échappement SELinux sur les futurs appareils. Il ne fait rien pour les centaines de millions de Galaxy S23–S26 et de flagships Xiaomi déjà en circulation.

Ce que ça change pour votre politique de flotte

Pour un RSSI qui gère un parc mobile, la conclusion est opérationnelle, pas théorique :

• Ne faites pas confiance à la détection de root. Elle est contournée par KernelSU, et ne détecte ni OEMpocalypse ni ses outils publics. Un contrôle « appareil non rooté » ne prouve plus rien.
• Exigez l’attestation matérielle. La seule chose qui résiste est une clé StrongBox/KeyStore matérielle. Vérifiez que vos applications critiques utilisent le stockage de clés adossé au matériel, et poussez les fournisseurs qui ne le font pas.
• Traitez les correctifs constructeur comme incomplets. Le correctif de septembre de Samsung ne confirme pas couvrir la chaîne. Sans confirmation explicite, considérez les Galaxy S23–S26 sous firmware de juillet ou antérieur comme exposés.
• Surveillez la suite de la série. La première partie ne nomme pas les pilotes ; les suivantes le feront, et élargiront probablement la liste des vendeurs touchés.

Pourquoi les durcissements classiques ne suffisent pas

La chaîne OEMpocalypse a une propriété rare : elle ne dépend d’aucune des primitives que les durcissements modernes cherchent à casser. Pas de fuite KASLR à obturer, pas de ROP à déjouer, pas de CFI à contourner. L’attaquant lit et écrit directement en mémoire physique, ce qui court-circuite les défenses de la pile, du slab et du flux de contrôle d’un seul coup.

C’est ce qui explique pourquoi les correctifs au coup par coup ne suffiront pas. Tant que les pilotes OEM exécuteront du code noyau non audité, la classe de bug — un use-after-free de page dans un pilote propriétaire — se reproduira, parce que les constructeurs réécrivent le même type de code pour chaque génération d’appareils. Le correctif de septembre de Samsung peut boucher un pilote précis ; il ne bouche pas le modèle qui a produit ce pilote.

Pour un RSSI, la conséquence est un changement de paradigme : sur un appareil Android, la frontière de confiance n’est plus « l’application est dans son bac à sable », mais « la clé est dans l’élément sécurisé ». Tout ce qui n’est pas adossé à ce matériel doit être traité comme lisible par un attaquant qui a déjà rooté le téléphone sans déclencher aucune alarme.

Verdict

OEMpocalypse rend explicite une vérité que l’écosystème Android contournait depuis des années : le code noyau des constructeurs est une surface d’attaque non auditée, et l’attestation d’intégrité ne couvre pas le noyau en cours d’exécution.

Si votre flotte contient des Samsung Galaxy S23–S26, des flagships Xiaomi ou des Oppo/OnePlus/Realme, cessez de traiter « non rooté » comme un signal de sécurité et basculez vos contrôles sur l’attestation matérielle StrongBox. Si vous publiez une application Android, déplacez toute donnée sensible vers un stockage de clés matériel — EncryptedSharedPreferences et FLAG_SECURE ne valent plus rien face à un pair rooté en mémoire. Et si vous êtes responsable de conformité, exigez des constructeurs une confirmation écrite que leur correctif de septembre couvre la chaîne, au lieu de supposer qu’un bulletin « 90 vulnérabilités » l’inclut.

Références

• calif.io — OEMpocalypse, Lukas Maar (recherche complète)
• Reptile Haus — Verified Boot Said Green. An App With No Permissions Had Root.
• Cybernews — Android OEM software vulnerabilities let apps root phones
• eSecurityPlanet — Samsung September 2026 Galaxy security update
• Android Security Bulletin — Septembre 2026