Apple iOS 26 met définitivement fin au jailbreak physique. Découvrez pourquoi Corellium est le seul moyen d’analyser et de vérifier pleinement les rouages internes d’iOS et les vulnérabilités des applications mobiles, et de mener des recherches en sécurité mobile. 

iOS 26 a tué le jailbreak. Voici ce que perdent les développeurs et les équipes de sécurité

Avec la sortie d’iOS 26, Apple a fermé le dernier moyen viable pour les équipes de sécurité de réaliser des tests de sécurité approfondis au niveau root sur iOS: les jailbreaks. Pendant des années, les jailbreaks ont permis aux équipes d’inspecter le comportement des applications sur de vrais appareils, et pas seulement en simulation ou par revue statique du code. 

Désormais, c’est terminé. Ce qu’Apple appelle une protection renforcée a créé un nouveau type de risque : une perte totale de visibilité pour les développeurs, les testeurs d’intrusion et les responsables de la sécurité qui ont besoin de comprendre comment les applications se comportent sur de vrais appareils. 

Les organisations ne testent plus des applications. Elles testent des hypothèses. 

Quand les jailbreaks iOS disparaissent, la validation à l’exécution disparaît avec eux 

Les jailbreaks n’ont jamais été idéaux, mais ils donnaient accès à l’essentiel. Ils permettaient de tester le comportement des applications au sein du système d’exploitation, et pas seulement leur fonctionnement apparent. Il n’existe aucun jailbreak public pour quoi que ce soit au-delà d’iOS 18, pour rester prudent. De nombreuses équipes se demandent : peut-on encore jailbreaker les nouveaux iPhone ? La réponse courte est non, pas de manière fiable. Corellium donne aux équipes de sécurité accès à des iOS et iPadOS virtuels, configurables avec ou sans jailbreak, y compris un accès de niveau root pour des tests d’inspection plus approfondis. Voici ce que les équipes de sécurité perdent sans accès de niveau root : 

  • Inspecter le keychain et le stockage local des fichiers 
  • Surveiller les appels d’API en direct et le comportement à l’exécution 
  • Auditer la communication inter-applications et les autorisations 
  • Observer les protections au niveau du noyau en action 

Les simulateurs ne reproduisent pas pleinement les contrôles de sécurité matériels, le comportement du système d’exploitation, ni les conditions d’un iPhone physique. L’analyse statique peut repérer du code et des composants tiers à risque, mais elle ne peut pas confirmer le comportement d’un SDK lorsque l’application s’exécute. Les anciens appareils jailbreakés peuvent encore servir à la recherche sur d’anciennes versions, mais ils ne représentent pas les appareils et versions d’iOS que les clients utilisent en production. 

Cela donne une vision incomplète du risque lié aux applications mobiles. Les équipes peuvent tester le code qu’elles peuvent inspecter sans voir le comportement à l’exécution qui émerge lorsque l’application, le système d’exploitation, les SDK tiers, le stockage et les connexions réseau interagissent.

iOS 26 crée de dangereux angles morts 

Les régulateurs se moquent de ce que dit une suite de tests. Ce qui les intéresse, c’est de savoir si les équipes peuvent prouver que leur application traite correctement les données sensibles sur de vrais appareils et dans des conditions réelles. 

iOS 26 verrouillant les tests au niveau root, cette preuve devient difficile, voire impossible. Les équipes de sécurité et de conformité perdent la capacité de vérifier si les applications mobiles satisfont ne serait-ce qu’aux exigences de base en matière de protection des données. 

Une visibilité limitée à l’exécution peut compliquer la validation des contrôles de sécurité mobiles et la production de preuves pertinentes au regard des exigences réglementaires et d’assurance :

  • HIPAA: Difficulté à confirmer que les informations électroniques de santé protégées sont correctement sécurisées lorsqu’elles sont stockées, mises en cache, transmises ou supprimées par une application mobile. 
  • PCI DSS: Capacité réduite à vérifier la façon dont les données de comptes de paiement sont traitées pendant l’exécution de l’application, notamment si des données sensibles sont stockées, transmises, journalisées ou exposées en violation de la politique. 
  • GDPR / RGPD / DSGVO: Difficulté à évaluer si la collecte, le partage, la conservation et le traitement par des tiers des données personnelles au sein de l’application mobile sont conformes aux finalités documentées et aux exigences de protection des données. (RGPD) 
  • CCPA: Visibilité réduite sur la façon dont les informations personnelles sont collectées, divulguées ou partagées via des technologies tierces intégrées, et sur la conformité de ce comportement avec les mentions faites aux consommateurs et les restrictions applicables aux prestataires. 
  • DORA: Lacunes dans les preuves utilisées par les entités financières pour évaluer et tester la résilience des applications mobiles qui soutiennent des services métier importants ou critiques. 
  • NIS2: Difficulté à valider si les mesures de gestion des risques de cybersécurité protégeant les services mobiles fonctionnent efficacement dans la pratique. 
  • FISMA: Preuves techniques limitées pour évaluer les contrôles de sécurité lorsqu’une application mobile entre dans le périmètre d’un système d’information fédéral. 
  • CMMC: Difficulté à démontrer la mise en œuvre des mesures de protection applicables lorsque des applications ou appareils mobiles traitent, stockent ou transmettent des Federal Contract Information (informations sur les contrats fédéraux) ou des Controlled Unclassified Information (information non classifiées contrôlées). 

Dans tous les cas, la conformité repose sur des preuves vérifiables, non sur des hypothèses ou la confiance. L’écosystème fermé d’Apple laisse les organisations — qu’elles répondent aux régulateurs américains, européens, britanniques ou autres — sans moyen indépendant de valider ce qui se passe sur les appareils iOS.

Pourquoi compter sur l’App Store pour arrêter les menaces est illusoire 

En l’absence de jailbreaks facilement disponibles sur les derniers iPhone et iPad, le processus d’examen d’Apple est devenu la ligne de défense par défaut de nombreuses applications iOS et iPadOS. Apple n’est pas une entreprise de sécurité, et son processus d’examen n’est pas conçu pour détecter le type de risques qui exposent des informations sensibles. Avec des millions d’applications soumises chaque année, il est irréaliste d’attendre d’Apple qu’il bloque chaque application risquée ou malveillante. 

Le compromis iOS : visibilité ou vulnérabilité

Toute organisation qui publie des applications iOS finit par se poser la même question : jusqu’où aller dans la prise en charge des versions du système d’exploitation ? 

La plupart des applications d’entreprise couvrent actuellement plusieurs versions, souvent d’iOS 15 à iOS 26. Mais cette plage impose un compromis douloureux : 

Prendre en charge les anciennes versions (iOS 15/16) 

  • Conserver l’accès au jailbreak et la visibilité au niveau système 
  • Mais exposer les clients à des vulnérabilités connues activement exploitées 

Ne prendre en charge que les versions récentes (iOS 17+) 

  • Réduire la surface d’attaque en abandonnant la prise en charge des anciennes versions 
  • Mais perdre la capacité de tester le comportement de l’application sur de vrais appareils 

Il n’existe pas de réponse parfaite, et quelle que soit la voie choisie, l’entreprise hérite d’un risque : 

  • Sur les anciennes versions, les attaquants s’introduisent. 
  • Sur les versions plus récentes, les équipes de sécurité ne peuvent pas vérifier que l’application est pleinement conforme et sécurisée. 

Si la plupart des organisations relèvent leur version minimale du système à 17+, ce qui est logique, elles négligent souvent ce qu’elles perdent : la visibilité. Les simulateurs ne peuvent pas reproduire le comportement de l’enclave sécurisée, la gestion de la mémoire ni les protections matérielles. L’analyse statique ne peut pas repérer les problèmes à l’exécution ni le comportement des SDK. Sans tests en conditions réelles, même une application qui passe tous les contrôles peut receler un risque caché.

Secrets codés en dur : un risque coûteux 

orsque les équipes de sécurité perdent en visibilité, l’exposition des données sensibles devient un risque silencieux. Les secrets codés en dur en sont souvent la cause. Dans une étude de 2025 portant sur plus de 156 000 applications, les chercheurs ont constaté les faits suivants :

  • 71 % de ces applications contenaient au moins un secret codé en dur, tel que des clés d’API, des identifiants cloud ou des clés de chiffrement intégrés directement dans le code. 
  • Dans l’ensemble de ces applications, ils ont découvert 815 000 secrets uniques, dont beaucoup liés à de véritables systèmes de production. 
  • De nombreux secrets étaient invisibles pour les scanners statiques et ne seraient probablement pas détectés par le processus d’examen d’Apple. 

Il ne s’agit pas d’une faille théorique ; c’est un risque de sécurité à fort impact, caché à la vue de tous. Si des identifiants sont exposés, les attaquants peuvent : 

  • Exfiltrer les données des clients 
  • Se déplacer latéralement dans les environnements d’entreprise 
  • Déclencher des violations de conformité 

Sans accès à l’application s’exécutant dans un environnement réel, il est impossible de confirmer si ces secrets sont accessibles à l’exécution. Dans le Verizon Mobile Security Report 2025, 85 % des répondants ont reconnu que les menaces visant les appareils mobiles augmentent, et plus de la moitié avaient déjà subi un incident de sécurité lié au mobile.

L’essor des arnaques aux faux jailbreaks 

La demande de jailbreaks est plus forte que jamais, et les acteurs malveillants en profitent. Les chercheurs et testeurs en sécurité se tournent parfois vers des solutions de contournement peu fiables : 

  • Acheter des iPhone jailbreakés auprès de vendeurs en ligne 
  • Essayer des outils de jailbreak en ligne risqués, comme les dernières versions de nekoJB 
  • Installer des charges utiles provenant de forums, de réseaux sociaux ou de dépôts GitHub non officiels 

Ces approches sont éphémères et à haut risque : 

  • Les jailbreaks ne fonctionnent pas sur iOS 17+ 
  • Certains outils sont des logiciels malveillants déguisés, injectant du code malveillant ou créant un risque sur la chaîne d’approvisionnement 
  • Même les jailbreaks légitimes entraînent souvent une instabilité de l’appareil, un « bricking » (appareil rendu inutilisable) ou une compromission de la sécurité 

Il ne reste aucune voie de jailbreak sûre ou pérenne. 

Corellium est le seul accès qui fonctionne 

Corellium est la voie à suivre pour les équipes qui ont besoin d’un accès approfondi, de niveau root, à iOS et iPadOS. La La plateforme fournit aux équipes des appareils iOS virtuels exécutant un vrai firmware, avec une visibilité approfondie au niveau du système et un accès contrôlé aux configurations avec ou sans jailbreak. 

Contrairement aux jailbreaks d’appareils physiques, Corellium ne s’appuie pas sur des vulnérabilités exploitées pour offrir ce niveau d’accès. Des équipes de sécurité et des agences gouvernementales du monde entier utilisent Corellium pour : 

  • Analyze how apps behave at runtime: analyser le comportement des applications à l’exécution, y compris l’accès illimité aux fichiers, l’accès à la mémoire utilisateur et noyau, le stockage keychain et la communication inter-processus. 
  • Inspect third-party SDK behavior: inspecter le comportement des SDK tiers pendant l’exécution de l’application, et pas seulement ce qui est déclaré statiquement. 
  • Run apps under real iOS conditions: exécuter les applications dans des conditions iOS réelles pour observer ce que les outils statiques et les simulateurs ne peuvent pas révéler. 
  • Reproduce issues tied to runtime state: reproduire les problèmes liés à l’état d’exécution, et pas seulement les bogues du code source. 
  • Validate security and privacy controls: valider les contrôles de sécurité et de confidentialité tels qu’ils s’exécutent, et pas seulement tels qu’ils sont écrits. 

Envie d’en savoir plus? Parlez à notre équipe du déploiement de Corellium.

Share this post