CoreGraphics : ce que révèle vraiment la zero-day iOS liée à un fichier piégé

Correctif publié le 26 octobre 2026 ; notice Apple datée du 29 octobre. Apple indique que CVE-2026-86950 est une écriture hors limites dans CoreGraphics : le traitement d’un fichier malveillant peut mener à une exécution de code. L’entreprise dit avoir connaissance d’un signalement selon lequel la faille pourrait avoir été exploitée dans une attaque très sophistiquée visant des personnes précises sur des versions d’iOS antérieures à iOS 27. Ce niveau de formulation compte : Apple ne publie ni la chaîne, ni le fichier déclencheur, ni une liste de victimes vérifiée dans l’avis.

Comment un fichier devient une écriture mémoire

CoreGraphics transforme des formats graphiques et des données de rendu en objets utilisés par les applications. Un fichier non fiable fournit des valeurs que le parseur convertit en longueurs, offsets, nombres d’éléments et emplacements de destination. Pour copier n octets dans un tampon de taille L à l’offset i, le programme doit notamment vérifier i <= L puis n <= L - i. Si l’une de ces conditions manque ou si un entier se transforme de manière inattendue, une écriture peut dépasser le tampon.

Cette description est le mécanisme général d’une écriture hors limites, pas la fonction précise vulnérable de CoreGraphics : Apple ne divulgue pas cette fonction. La primitive est plus directement dangereuse qu’une simple lecture hors limites parce qu’elle modifie la mémoire. Elle peut corrompre un objet voisin, faire planter le processus ou, sous des conditions plus fortes, contribuer au contrôle du flot d’exécution. L’impact dépend aussi de l’application qui traite le fichier et des protections du processus. L’avis Apple dit « may lead to arbitrary code execution » ; il ne dit pas que n’importe quelle image ouverte donne automatiquement le contrôle de l’appareil.

La chaîne d’attaque reste inconnue

Une attaque ciblée sur iOS associe souvent plusieurs étapes pour sortir du processus initial ou conserver un accès, mais aucune telle chaîne ne peut être attribuée à cette CVE sur la base de la notice publiée. On ne connaît publiquement ni l’extension du fichier, ni le canal de livraison, ni le besoin d’un geste utilisateur, ni la présence d’un second bug. La mention d’une exploitation possible est un signal sérieux, pas une preuve publique de toutes ces étapes.

Un chercheur autorisé chercherait les formats réellement pris en charge, testerait des fichiers réduits avec dimensions, tables et blocs malformés, puis comparerait les résultats des versions avant et après correction sous instrumentation mémoire. Il suivrait la première écriture invalide, sa valeur source et les objets voisins ; un crash isolé ne constituerait pas une preuve de prise de contrôle. Cette méthode explique comment retrouver une classe de faille, sans prétendre reproduire la recherche de Meta Product Security, créditée par Apple.

Quels appareils et quelle vérification ?

L’avis consulté concerne iOS 18.7.11 et iPadOS 18.7.11 pour les iPhone XS, XS Max et XR ainsi que l’iPad de 7e génération. Ces versions corrigées sont particulièrement importantes pour les appareils anciens restant sur cette branche. Le contrôle pratique consiste à vérifier la version réellement installée, puis à examiner les autres bulletins Apple applicables au modèle et à la branche utilisés. Le fait qu’une mise à jour existe pour iOS 18 ne signifie pas qu’une installation récente sur une autre branche serait vulnérable ; l’état exact doit être déterminé par son propre avis.

La valeur de cette CVE est autant dans ses limites de preuve que dans sa sévérité : le public dispose d’une primitive mémoire et d’un avertissement d’exploitation ciblée, mais pas d’un PoC ni d’un récit détaillé. Une analyse sérieuse explique ce qui rend l’exécution plausible tout en laissant visibles les maillons que seul Apple ou un rapport d’enquête ultérieur pourra établir.

Source principale : bulletin de sécurité Apple pour iOS 18.7.11 et iPadOS 18.7.11.