Trois fonctionnalités du moteur WebKit permettent depuis des mois de contourner le système de relais censé masquer l’identité réseau des utilisateurs Safari, y compris sur les navigateurs tiers installés sur iPhone et iPad. Les chercheurs en sécurité Talal Haj Bakry et Tommy Mysk ont publié mardi 5 août 2026 le détail de ces vulnérabilités, accompagné d’un site de démonstration (leaks.psylo.app) où chacun peut vérifier, en quelques secondes, si sa propre adresse IP fuit malgré l’activation de Private Relay.
iCloud Private Relay, intégré aux forfaits payants iCloud+ depuis iOS 15, repose sur une architecture dite à double saut qui achemine le trafic Safari à travers deux relais successifs, de sorte qu’aucun intermédiaire, pas même Apple, ne puisse relier un utilisateur aux sites qu’il consulte. Le mécanisme ne couvre toutefois que Safari et ne constitue pas un VPN au sens strict, puisqu’il ne protège pas l’ensemble du trafic de l’appareil. Cette distinction, souvent mal comprise, prend aujourd’hui une dimension nouvelle.
Les trois vecteurs de fuite identifiés par Bakry et Mysk s’enracinent tous dans WebKit, le moteur de rendu qu’Apple impose à l’ensemble des navigateurs distribués sur iOS et iPadOS (Chrome, Edge, Firefox, Brave…). Le DNS prefetching, ajouté dans iOS 26, résout les noms de domaine par le chemin DNS habituel de l’appareil au lieu de passer par le proxy. WebTransport, apparu avec iOS 26.4, ouvre une connexion HTTP/3 qui échappe elle aussi au tunnel. Et la fonctionnalité WebAuthn Related Origin Requests, liée aux passkeys, déclenche une requête de validation directement depuis le système d’exploitation, hors de toute protection relais.
Le scénario WebAuthn est peut-être le plus préoccupant pour l’utilisateur ordinaire. Tommy Mysk l’a résumé sur X avec une économie de mots glaçante : « N’importe quel site peut configurer WebAuthn de façon à ce que WebKit révèle la vraie adresse IP, contournant le proxy et iCloud Private Relay dans Safari. Le site doit délibérément exploiter le bug pour associer la session de navigation courante à l’IP fuitée. Cela ne nécessite aucune interaction utilisateur ni l’usage de passkeys. » Aucune invite, aucun dialogue, aucune trace visible à l’écran. Un site malveillant prétendant supporter les passkeys suffit à récolter l’information en arrière-plan.
Les conséquences débordent largement le périmètre d’Apple. OnionBrowser, l’application iOS qui route le trafic via le réseau Tor, repose lui aussi sur WebKit et se retrouve donc vulnérable aux mêmes fuites, ce qui compromet l’anonymat de ses utilisateurs dans des contextes où celui-ci peut être vital. Sur macOS, tout navigateur s’appuyant sur les API de configuration proxy de WebKit est pareillement touché. Le navigateur Chrome en version desktop échappe en revanche au problème, puisqu’il utilise son propre moteur Blink.
Bakry et Mysk ont fait un choix inhabituel en ne signalant pas ces failles à Apple avant publication. Mysk a justifié cette décision par un constat d’expérience : « Notre expérience passée avec Apple nous dit que signaler ce problème impliquerait des mois de délais, une communication incohérente et, dans certains cas, un déni complet de l’impact. » Le précédent Hide My Email, corrigé un peu plus d’un mois auparavant après avoir été connu d’Apple pendant plus d’un an, illustre ce grief. Apple a indiqué à 404 Media qu’elle enquêtait sur le rapport, sans fournir de calendrier.
Pour un utilisateur français abonné à iCloud+, la vérification est immédiate. Il suffit de se rendre sur le site de test mis en ligne par les deux chercheurs, Private Relay activé dans Safari, et de comparer l’adresse IP affichée avec celle fournie par un service tiers. Si les deux correspondent… la promesse de confidentialité n’est pas tenue. En attendant un correctif d’Apple, la seule parade efficace reste l’utilisation d’un VPN complet, qui protège le trafic au niveau système et empêche ces requêtes hors tunnel d’atteindre le réseau en clair.
Ce n’est d’ailleurs pas la première fois que Private Relay se fissure de la sorte. Dès 2021, FingerprintJS avait démontré qu’un mécanisme WebRTC permettait déjà de récupérer l’adresse IP réelle des abonnés. Cinq ans plus tard, le moteur WebKit continue de creuser des brèches dans le dispositif qu’il est pourtant censé servir, et la question finit par se poser franchement : un bouclier de confidentialité peut-il tenir quand le socle logiciel sur lequel il repose multiplie les portes dérobées involontaires ?
