Advisory
Ouvrir la page, c'est le téléchargement
Un lecteur a objecté que le simple chargement d'une page web ne peut compromettre un téléphone — il faudrait télécharger et exécuter quelque chose. C'était vrai en 2015. Nous expliquons pourquoi ouvrir la page est déjà le téléchargement, comment une chaîne d'exploitation iOS de niveau étatique est devenue un logiciel criminel banalisé en six mois, et pourquoi la même attaque ne montre aux visiteurs Android qu'un formulaire d'hameçonnage.
- Publication initiale
- 2026-09-02 06:25 UTC
- Dernière mise à jour
- 2026-09-02 15:08 UTC
Un lecteur a contesté une note de sécurité que nous avions publiée, et l'objection était bonne — suffisamment bonne pour mériter une réponse détaillée, car nous pensons que la plupart des personnes techniquement compétentes partagent encore la même conviction :
En 2015, c'était une règle raisonnable. Aujourd'hui, elle est fausse. Charger une page web suffit entièrement à prendre le contrôle d'un iPhone, et en 2026 ce n'est plus quelque chose que seuls des budgets étatiques peuvent atteindre.
Ouvrir la page est le téléchargement
Le modèle mental à remplacer, c'est le mot « téléchargement ». Charger une page est déjà télécharger et exécuter. Le navigateur récupère un programme écrit par un inconnu — du JavaScript — et l'exécute. Il analyse ensuite les images, les polices, la vidéo et les feuilles de style fournies par ce même inconnu, dans des décodeurs écrits en C++. Tout cela se déroule dans un bac à sable, et ce bac à sable est la seule chose qui sépare cette page de votre appareil.
Le bac à sable n'est pas un mur. C'est une hypothèse : celle que WebKit et le noyau ne contiennent aujourd'hui aucun bug atteignable et exploitable. WebKit représente des millions de lignes de C++, et Apple publie plusieurs fois par an des correctifs pour des failles WebKit marquées comme exploitées activement.
« Il faut télécharger un .exe pour être infecté » relève d'une pensée façonnée par Windows. Sous iOS, vous ne pouvez pas du tout exécuter un fichier exécutable téléchargé — et c'est précisément pour cela qu'une chaîne complète allant de Safari au noyau a historiquement valu sept chiffres. L'absence de sideloading ne supprime pas la porte d'entrée. Elle fait du navigateur la porte d'entrée.
L'antécédent remonte à dix ans
Rien de tout cela n'est nouveau. Trois points bien documentés sur la courbe :
- 2016La chaîne Trident de Pegasus a compromis un iPhone entièrement à jour à partir d'une seule pression sur un lien dans Safari. Une pression, aucune invite d'installation, aucune saisie d'identifiants.
- 2019Project Zero a documenté un ensemble de sites compromis qui infectaient tout iPhone non à jour qui les visitait. Aucun ciblage, aucune interaction — la visite suffisait.
- 2023Predator était livré en détournant le trafic HTTP ordinaire et non chiffré de la cible, puis en y injectant la chaîne. La victime naviguait normalement.
Ce qui a changé en 2026, ce n'est pas la capacité. C'est la distribution.
2026 : la capacité a été mise en location
En mars, le Google Threat Intelligence Group — en collaboration avec iVerify et Lookout — a publié l'analyse d'un kit d'exploitation iOS à chaîne complète suivi sous le nom de DarkSword. Il couvrait iOS 18.4 à 18.7, enchaînait six vulnérabilités — dont trois étaient alors des zero-days — et était en service depuis au moins novembre 2025.
Deux détails de ce rapport comptent davantage que le nombre de vulnérabilités.
Le premier est la liste des opérateurs. L'activité en Turquie a été rattachée à un éditeur turc de logiciels de surveillance ; un autre client de cet éditeur a été observé en janvier utilisant la même chaîne contre des utilisateurs malaisiens ; et un groupe distinct, soupçonné d'espionnage, a mené des attaques par point d'eau contre des utilisateurs ukrainiens — en implantant la chaîne sur des sites que les cibles visitent d'elles-mêmes. Une chaîne d'exploitation, plusieurs mains sans lien entre elles. C'est une relation de fournisseur, pas une opération sur mesure.
Le second : les chercheurs ont trouvé des indices selon lesquels le développement ou la personnalisation de la chaîne aurait pu être assisté par IA. Quel que soit le poids que l'on accorde à ce constat particulier, la direction qu'il indique est ce qui importe ici : la barrière à l'entrée s'abaisse, et des capacités réservées à une poignée d'éditeurs se diffusent vers l'extérieur.
Puis c'est devenu bon marché
Le 1er septembre, Socket a publié une recherche sur la version grand public de cette même tendance — et il ne s'agit pas du tout d'espionnage. Il s'agit de vol.
Treize paquets de thèmes Composer malveillants ont été publiés sur Packagist, sous plusieurs espaces de noms. Des sites vietnamiens de streaming de films et de bandes dessinées les ont installés avec composer require, ce qui a discrètement piégé les ressources front-end de ces sites. Chaque visiteur recevait dès lors du JavaScript injecté.
Ce script effectuait un aiguillage :
- La plupart des visiteurs mobiles étaient dirigés vers une chaîne de fraude publicitaire et de redirection vers des sites de jeux d'argent. Bruyant, rentable, banal.
- Les visiteurs sur iPhone non à jour recevaient à la place une chaîne d'exploitation allant de WebKit au noyau, et se voyaient installer un logiciel espion.
AppleM2ScalerCSCDriver, aboutissant à un accès en lecture et écriture au noyauLa chaîne entrait par deux failles WebKit et aboutissait à un accès en lecture et écriture au noyau. Notez leur nature : ce sont des N-days, pas des zero-days. Toutes deux étaient déjà publiques et déjà corrigées. Tout le modèle économique repose sur l'écart entre le moment où Apple publie un correctif et celui où une personne donnée l'installe. Ce kit n'attaque pas les iPhone. Il attaque les iPhone qui n'ont pas été mis à jour depuis un moment — ce qui, sur un appareil traité comme un appareil ménager, représente une population énorme.
Ce qui nous amène à une offre de VPS gratuit
Le 31 août, un domaine a été enregistré. Le 1er septembre, il se diffusait.
L'appât est bien choisi pour son public : un hébergeur cloud annonce une bêta fermée, avec des instances VPS gratuites — jusqu'à trois ans — pour les 5 000 premières inscriptions. Il s'est propagé dans les communautés VPS, sysadmin et blockchain par invitation par courriel et, plus efficacement, par liens de parrainage.
Le mécanisme de parrainage est la partie sur laquelle un défenseur devrait s'arrêter. Il ne se contente pas de distribuer le lien ; il recrute les membres établis de la communauté eux-mêmes pour le distribuer, enveloppé dans leur propre réputation, parce qu'ils obtiennent en échange une durée gratuite plus longue. Le message n'arrive pas d'un inconnu. Il arrive de quelqu'un dont vous lisez les publications depuis des années. Au moins une personne ayant partagé un lien de parrainage a ensuite publié une rétractation pour en détourner les autres.
Comportement rapporté de la page :
Une réponse promotionnelle aurait insisté sur le fait que le lien de réservation « doit être ouvert sur un téléphone ». Aucune véritable page de réservation de VPS n'a de raison d'exiger cela. Un kit d'exploitation uniquement mobile en a toutes les raisons.
Ce que nous pouvons confirmer et ce que nous ne pouvons pas
Nous tenons à être précis sur le statut probatoire, car ces trois affaires ne se situent pas au même niveau de confirmation et il serait malhonnête de les présenter comme équivalentes.
DarkSword et la campagne Packagist relèvent de recherches publiées par des éditeurs. Chercheurs nommés, CVE identifiées, détails techniques reproductibles, publication sous responsabilité organisationnelle. Traitez-les comme établies.
La campagne du VPS gratuit provient de la communauté. L'existence de la campagne est bien corroborée : la promotion est documentée dans plusieurs fils de discussion, la date d'enregistrement du domaine est vérifiable, et un participant a publiquement retiré sa propre publication de parrainage. C'est amplement suffisant pour agir défensivement.
Les affirmations techniques approfondies — la chaîne précise, l'enchaînement exact des étapes — proviennent d'une analyse anonyme sans identifiants CVE publiés ni empreintes d'échantillons, produite en une journée. C'est réalisable si l'auteur a reconnu un kit connu ; il serait remarquable qu'il ait rétro-conçu une chaîne inédite en une nuit. La recherche de Socket évoquée plus haut est ce qui rend le rapport crédible, et non l'inverse : même plage de versions, même inventaire de données volées, même mobile crypto, même architecture de prise d'empreinte puis de chargement. Un kit N-day loué, pointé sur des gens qui n'ont pas mis à jour depuis un an, ressemble exactement à cela.
Notre position : assez crédible pour s'en protéger, pas assez confirmé pour être cité comme un fait. Si cela change, nous mettrons cet article à jour sur place, comme nous l'avons fait pour de précédents avis.
« Zéro clic » est le mauvais terme, et la réalité n'est guère meilleure
Le rapport communautaire est intitulé comme une attaque zéro clic. Ce n'en est pas une, et la distinction mérite d'être maintenue au propre, car elle change ce qui vous protège.
Zéro clic signifie aucune action de l'utilisateur, quelle qu'elle soit — un message arrive et l'appareil est compromis avant que quoi que ce soit ne soit ouvert. Ici, vous devez ouvrir un lien. Dans la taxonomie standard, il s'agit d'une attaque en un clic, par point d'eau ou par simple visite.
La distinction importe pour une raison pratique : face à une chaîne en un clic, la discipline sur les liens vous protège réellement. Face à une véritable chaîne zéro clic, elle ne le fait pas, et seuls le niveau de correctif et le mode Isolement le font.
Mais n'en tirez pas trop de réconfort. « Un clic » signifie ici ouvrir un lien qu'une personne de confiance vous a envoyé. Il n'y a pas de seconde invite, pas de barre de téléchargement, pas de boîte de dialogue d'installation, pas de demande d'autorisation. L'ouvrir constitue tout le parcours utilisateur. Le terme est erroné ; la différence pratique pour la victime est d'une pression du doigt.
Android est-il à l'abri ?
De cette chaîne, oui. De cette classe d'attaque, non.
Cette chaîne est bâtie à partir de failles WebKit et JavaScriptCore, d'un pilote noyau IOKit d'iOS et de décalages propres à chaque build pour des modèles d'iPhone précis. Rien de tout cela n'existe sous Android. Les deux campagnes le confirment par leur comportement : dans le cas Packagist, le script injecté vérifiait la plateforme et envoyait les visiteurs Android vers la bannière de fraude publicitaire ; dans le cas du VPS gratuit, les visiteurs Android et ordinateur n'obtiennent que le formulaire d'hameçonnage.
Cette classe, c'est autre chose. Chrome, V8 et Android WebView sont le même type d'objet que WebKit : d'énormes moteurs C++ qui analysent des entrées hostiles. Google a corrigé cinq zero-days Chrome exploités activement en 2026, dont l'un permettait à un attaquant distant d'exécuter du code dans le bac à sable du navigateur à partir d'une simple page HTML forgée. C'est exactement la première étape que franchissent les chaînes iOS.
Les cinq sont CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 et CVE-2026-11645. Le dernier est une lecture et écriture hors limites dans V8.
Des chaînes Android par simple visite sont également documentées, dont une combinant un zero-day Chrome, un contournement du bac à sable GPU de Chrome propre à Android et une élévation de privilèges dans le GPU Mali, livrée par un lien SMS.
Là où Android diffère réellement
Trois différences réelles, et elles ne pointent pas toutes dans la même direction.
Ce qui vous protège réellement
Pour les deux campagnes iOS documentées, le niveau de correctif est décisif, et il y a un piège dans les numéros de version :
Au-delà des correctifs, le conseil structurel : ne conservez pas de graine de portefeuille sur l'appareil avec lequel vous ouvrez des liens. Les charges finales des deux campagnes visaient le trousseau et les applications de portefeuille. Un portefeuille matériel ou un appareil dédié transforme une perte totale en désagrément.
Et considérez « ouvrez ceci sur votre téléphone » comme une anomalie. Une page d'inscription légitime se moque de l'appareil que vous utilisez. Un kit d'exploitation uniquement mobile ne s'en moque pas du tout.
Si vous l'avez ouverte
Partez du principe qu'il y a compromission plutôt que d'espérer le contraire, dans cet ordre :
- Déplacez d'abord les fonds. Si des applications de portefeuille étaient installées sur cet appareil, considérez les phrases de récupération comme divulguées. Transférez les actifs vers un portefeuille dont les clés ont été générées ailleurs. Ne vous contentez pas de changer un code — la graine est le compte.
- Ensuite mettez à jour, puis redémarrez. Installez la version actuelle d'iOS. Beaucoup de ces implants ne survivent pas à un redémarrage ; mettre à jour et redémarrer ferme la faille et élimine une étape non persistante.
- Renouvelez ce qui se trouvait dans le trousseau. Mots de passe enregistrés, identifiants Wi-Fi, cookies de session. Déconnectez toutes les sessions partout, puis changez les mots de passe depuis un autre appareil.
- Vérifiez les ajouts sur vos comptes, pas seulement les connexions. Nouvelles méthodes de double authentification, nouvelles adresses de récupération, nouvelles clés d'API, nouveaux appareils autorisés. Les cookies exfiltrés servent à installer une voie de retour durable.
Étapes de la chaîne, telles que rapportées
Reconstituées à partir de l'analyse publiée par Socket sur la campagne Packagist. Les frontières entre étapes comptent pour le tri : chacune laisse des traces différentes, et seule la dernière est persistante.
AppleM2ScalerCSCDriver, aboutissant à un accès en lecture et écriture au noyau. À partir de là, le bac à sable n'est plus une frontière.Deux faits à retenir de cette forme. D'abord, seule l'étape 1 touche tous les visiteurs — un site qui sert l'injecteur est dangereux pour l'ensemble de son public, même si presque personne n'atteint l'étape 4. Ensuite, la condition d'entrée est dans les deux cas une faille corrigée : l'exposition dépend du retard de mise à jour, pas du comportement de l'utilisateur.
Matrice d'exposition
Tri d'un appareil que vous pensez touché
Cet ordre diffère délibérément du conseil destiné aux lecteurs. Le blog dit au propriétaire de mettre à jour et de redémarrer immédiatement, ce qui est juste quand l'objectif est d'arrêter l'hémorragie. Si l'objectif est d'établir si l'appareil a été compromis, un redémarrage détruit les preuves : plusieurs de ces étapes ne sont pas persistantes et n'existent qu'en mémoire volatile.
- Choisissez d'abord : récupération ou preuve. On n'a généralement pas les deux. Si des fonds sont en jeu, prenez la récupération et acceptez la perte des preuves.
- Pour la preuve : capturez avant de redémarrer. Un sysdiagnose pris avant le redémarrage préserve bien plus qu'un sysdiagnose pris après. Des plantages répétés du processus WebContent ou GPU autour de l'heure de la visite sont la trace la plus susceptible de subsister.
- Traitez les éléments de portefeuille comme divulgués, non comme menacés. L'étape 5 les vise directement. La rotation des clés n'est pas optionnelle et aucun correctif ne la remplace.
- Auditez les ajouts, pas les accès. Les cookies exfiltrés servent à enrôler une seconde voie durable — nouveaux facteurs MFA, adresses de récupération, clés d'API, appareils autorisés. Un historique de connexion propre ne prouve rien.
- Vérifiez le réseau, pas seulement le téléphone. Les mots de passe Wi-Fi étaient dans le périmètre. Un combiné compromis implique des identifiants exposés pour chaque réseau qu'il a mémorisé.
Évaluation, et ce qui la ferait changer
Nous énonçons la confiance explicitement, car ces trois éléments ne sont pas également établis, et un avis qui brouille cette distinction vaut moins qu'un avis qui la maintient.
Ce qui relèverait l'évaluation basse : une empreinte d'échantillon publiée, une seconde analyse indépendante, ou une confirmation d'éditeur nommant les mêmes CVE. Ce qui l'abaisserait : que l'appât se révèle être une page d'hameçonnage d'identifiants ordinaire, sans charge conditionnée à la version — c'est l'hypothèse nulle, et rien de ce que nous avons vu nous-mêmes ne l'exclut.
Nous ne détenons aucun échantillon de la campagne du VPS gratuit. Tout ce que cet avis en dit est de seconde main. Nous le précisons plutôt que de laisser l'offre permanente de ce site de partager des charges utiles suggérer le contraire.
Chronologie
- 2025-11DarkSword en service, selon l'analyse ultérieure du GTIG.
- 2026-03Le GTIG, avec iVerify et Lookout, publie l'analyse de DarkSword — un kit iOS à chaîne complète partagé entre éditeurs commerciaux et acteurs présumés étatiques.
- 2026-08-31Le domaine servant d'appât au VPS gratuit est enregistré.
- 2026-09-01Socket publie la campagne des thèmes Packagist. Le domaine appât se diffuse le jour même dans les communautés VPS, sysadmin et blockchain.
- 2026-09-02Publication de cet avis. L'appât résolvait encore au moment de la rédaction.
Vérifier par vous-même
Si vous voulez vérifier ce comportement d'aiguillage plutôt que de croire quelqu'un sur parole, faites-le depuis une machine qui n'est pas la cible : récupérez le script de la page depuis Linux avec un User-Agent d'iPhone et le forum communautaire en Referer, puis comparez avec ce que reçoit un User-Agent de bureau. La livraison de charge selon le User-Agent est la norme dans ces kits, et un User-Agent de bureau recevra très probablement du JavaScript propre.
Ne le faites pas depuis un téléphone, ni depuis un appareil contenant des éléments de portefeuille. Le camouflage joue dans les deux sens : qu'un scanner déclare propre un site d'hameçonnage actif est le résultat attendu, pas un résultat rassurant.
Indicateurs
event.polarnode[.]vip hôte servant d'appât, enregistré le 2026-08-31 CVE-2025-31277 WebKit, corrigée dans iOS 18.6 CVE-2025-43529 WebKit, corrigée dans iOS 18.7.3 / 26.2 AppleM2ScalerCSCDriver client utilisateur IOKit employé pour atteindre le noyau Espaces de noms Packagist : vsmov, vsphim, haiau009, chilltvcms, ophimcms
Pourquoi cet article ne contient aucun lien
Chaque adresse hostile que nous publions est écrite sous forme neutralisée et aucune n'est un lien fonctionnel. Un nom d'hôte d'hameçonnage rendu sous forme d'ancre active transforme un article en redirection, prête à la campagne une fraction de notre réputation et demande à un moteur de recherche d'associer les deux. Notre chaîne de publication l'impose : un hôte qui apparaît neutralisé quelque part dans un article ne peut porter de lien actif nulle part ailleurs dans ce même article.
Les recherches d'éditeurs citées ici se trouvent facilement par leur nom. Nous préférons que vous y parveniez par une recherche que vous avez menée vous-même plutôt que par un lien que nous aurions placé.