Cas 01 — Google Messages

Un aperçu de lien
qui révèle votre IP.

Google Messages est intégré à une très grande part des téléphones Android. Il génère les aperçus sur l'appareil : un lien envoyé par un contact enregistré peut donc révéler discrètement l'IP du destinataire, des informations sur son téléphone et l'heure de la requête au propriétaire du lien. Aucun clic sur le lien, aucune notification. Il suffit d'avoir ouvert le chat une fois ; les nouveaux liens peuvent ensuite être consultés automatiquement. La fuite reste limitée à une IP et quelques métadonnées, avec une gravité moyenne. Mais elle découle du fonctionnement prévu d'une application installée sur des centaines de millions de téléphones.

Par Abbas Hoseiny·Recherche indépendante en sécurité·Éditeur : Google

Google Messages est l'application de SMS et de conversations RCS derrière l'icône de messagerie de la plupart des téléphones Android, souvent utilisée sans même connaître son nom. L'aperçu est pratique : le chat affiche un titre, une description et une miniature à la place d'une simple adresse. Pour la vie privée, la question décisive est qui récupère la page. Si un serveur intermédiaire s'en charge, le propriétaire du lien voit ce serveur. Si votre téléphone la récupère directement, il voit des informations sur vous : votre réseau, votre appareil et l'heure de la requête.

Une grille de téléphones verrouillés ; certains affichent un lien envoyé par un contact enregistré
Fig. 1 — la même application sur d'innombrables téléphones

La même application, les mêmes conversations ordinaires, sur un très grand nombre de téléphones. Un contact enregistré envoie un lien dans un chat déjà ouvert au moins une fois ; aucune autre action n'est nécessaire.

Dans Google Messages, l'aperçu est généré sur l'appareil. L'application extrait l'URL puis, lorsque les conditions requises sont remplies, envoie une requête HTTPS ordinaire depuis le téléphone. Elle ne passe pas par un proxy de Google. C'est tout le mécanisme ; les autres précisions portent sur le moment où il se déclenche.

Des pointillés rouges relient plusieurs téléphones à un seul serveur
Fig. 2 — des requêtes silencieuses qui se multiplient

Chaque téléphone récupère lui-même le lien pour générer l'aperçu. Aucun signal, aucune demande d'autorisation. Les requêtes issues des différentes conversations arrivent au même endroit : le serveur qui héberge le lien.

C'est ici qu'il faut être précis, car la version précédente du rapport allait trop loin. À l'arrivée du message, le premier gestionnaire ne fait souvent qu'insérer une entrée deferred, puis termine sans requête réseau. La récupération réelle dépend d'un observateur démarré lorsque la conversation devient interactive, c'est-à-dire à l'ouverture du chat. Il s'exécute en arrière-plan et le code examiné ne montre pas d'arrêt lors de la sortie. Après une première ouverture, les liens suivants peuvent donc être récupérés alors que l'écran est verrouillé et l'application en arrière-plan.

Un journal serveur accumule la même IP, un User-Agent GoogleMessages et des horodatages espacés de quelques minutes
Fig. 3 — le journal de l'autre côté

Sur le serveur du lien, les requêtes s'accumulent : IP du destinataire, User-Agent et horodatages espacés de quelques minutes. Le destinataire n'a pas consenti à transmettre ces données.

Une requête ne fournit qu'un indice approximatif. Mais l'aperçu est enregistré par message, pas par URL. Le même lien envoyé dans un nouveau message est donc récupéré à nouveau. Un contact enregistré peut répéter l'envoi à intervalles réguliers et établir une chronologie approximative des réseaux utilisés par le destinataire.

Un téléphone verrouillé relié à une carte comportant des zones rouges diffuses, sans point de localisation précis
Fig. 4 — une trace approximative dans le temps

Une IP n'est pas une adresse postale. Des requêtes répétées peuvent néanmoins fournir des indices sur une ville, un réseau et les changements de connexion. C'est le coût, pour la vie privée, d'un aperçu récupéré par le téléphone plutôt que par un proxy.

Le problème a été signalé à Google en mars 2026. Selon la chronologie ci-dessous, Google a évalué puis clôturé le rapport le 2026-03-17. Le comportement était toujours présent dans la version installée sur l'appareil de test lors du nouvel examen du 29 octobre 2026. Cette page précise ce que le code et un test sur un seul appareil permettent d'affirmer, et ce qu'ils ne permettent pas d'affirmer.

Analyse technique

Google Messages — constats et analyse

Synthèse et gravité

Google Messages (com.google.android.apps.messaging) a été examiné sur un Samsung Galaxy A26 (SM-A266B), sous Android 16, build BP4A.251205.006, avec le paquet messages.android_20260910_03_RC02.phone_samsung_dynamic et le code de version 323089900. Le transport testé était RCS. L'analyse statique porte sur l'APK exact installé, dont l'APK de base a pour SHA-256 9e869a68…ff60b2 et une signature vérifiée comme authentique de Google. Elle est complétée par le comportement observé sur ce seul appareil.

IDConstatCWECVSS 3.1Gravité
F-PREVIEWFuite d'IP et de métadonnées via l'aperçu généré sur l'appareil200/3594.3Moyenne
F-UALa requête d'aperçu utilise un User-Agent usurpé, configuré à distance (intégré à F-PREVIEW)451—Contexte
F-PREVIEW · CWE-200 / CWE-359

Fuite d'IP et de métadonnées via l'aperçu généré sur l'appareil

Moyenne · CVSS 4.3

Description

Lors du traitement d'un message contenant une URL, Google Messages génère l'aperçu par une requête HTTP(S) GET envoyée depuis l'appareil, sans proxy côté serveur. Le serveur du lien reçoit l'IP de sortie actuelle du destinataire, le User-Agent de l'aperçu, Accept-Language et l'heure. Les requêtes suivantes pour une og:image ou un favicon peuvent aussi contenir un User-Agent Dalvik révélant la version d'Android, le modèle de l'appareil et le numéro de build.

Ce qui déclenche réellement la récupération

Ce point doit être décrit précisément, car il détermine la gravité. Le cheminement comporte deux étapes :

  1. À la réception, la tâche request_link_preview est planifiée après validation de l'écriture du message en base (dfvl/bcnl → btlr.b()). Pour un nouveau lien, le premier passage peut insérer une ligne d'aperçu deferred et se terminer avant toute requête réseau (btln).
  2. Quand le chat est ouvert et la conversation devient interactive, onMessageListInteractive lance un observateur (ahxw → aied). Il surveille les lignes deferred de cette conversation et planifie une seconde tâche avec deferred=true (aieb → btlr.a()), qui peut récupérer le lien une fois les conditions suivantes remplies.

L'observateur s'exécute dans un contexte de coroutines en arrière-plan, sans désinscription visible à la sortie du chat. Cela explique une récupération écran verrouillé et application en arrière-plan après une première ouverture du chat. Le code examiné ne démontre pas une récupération dans une conversation jamais ouverte, et ce rapport ne la revendique pas.

Conditions préalables

  • Réglage des aperçus. Les aperçus automatiques doivent être activés (aqck). Google Messages propose d'afficher tous les aperçus, uniquement ceux des liens web, ou de les désactiver.
  • Confiance accordée à l'expéditeur. Il doit satisfaire la condition btez.m(). Un contact doté d'un lookup_key renseigné est un état accepté, avec deux autres états de participant. Un chemin alternatif, piloté par un paramètre, compte les chargements manuels d'aperçus : le seuil par défaut dans l'APK est de 3, enregistré par participant. La valeur par défaut de enable_link_preview_untrusted_senders est false. Ouvrir le chat ou marquer un message comme lu n'équivaut pas à charger manuellement un aperçu. Les valeurs actives de la configuration distante n'ont pas été lues.
  • Schéma de l'URL. L'analyseur accepte uniquement http/https et réécrit ws:/wss:. Il rejette file:// et content://. Les images passent par le même client limité à HTTP.

Impact établi par les éléments disponibles

Le serveur du lien apprend l'IP de sortie actuelle, le User-Agent, la langue et l'heure de la requête. Les téléchargements d'image ou de favicon peuvent ajouter le modèle, la version du système et le build. L'aperçu étant indexé par identifiant de message et non par URL, un même lien dans un nouveau message provoque une nouvelle récupération. Un expéditeur de confiance peut ainsi constituer une trace approximative du réseau et de la localisation dans le temps. Lors du test archivé de mars, l'appareil utilisait un VPN : l'IP observée était celle de sa sortie, pas une IP résidentielle. Aucun accès à d'autres applications ou services locaux, aucune prise de contrôle de compte et aucune exécution de code n'ont été démontrés ni ne sont revendiqués.

Qui est considéré comme « de confiance » ?

Un contact enregistré n'est pas nécessairement un ami : il peut s'agir d'un magasin, d'un livreur ou d'une banque dont vous avez gardé le numéro. Les expéditeurs professionnels vérifiés, qui envoient des SMS/RCS en masse avec un nom d'entreprise et sans avertissement d'expéditeur inconnu, n'ont pas été testés. Leur éventuelle admissibilité reste une question pour Google. Dans tous les cas, les expéditeurs susceptibles de déclencher une récupération automatique ne se limitent pas à vos proches.

Détail du score CVSS 3.1

AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N → Score de base 4.3 (moyen)

L'impact est la divulgation d'une IP, d'un User-Agent et de métadonnées de l'appareil, soit C:Low, ce qui maintient la gravité au niveau moyen. UI:R reflète le code : la chaîne de récupération dépend de l'ouverture de la conversation. L'ancienne qualification « critique / sans clic » n'est pas justifiable : elle suppose un chemin UI:N avec un chat jamais ouvert que le code ne démontre pas, et un impact C:High que cette fuite n'atteint pas.

Pistes de correction

  • Récupérer les aperçus via un proxy de Google, pour que le serveur du lien voie son infrastructure et non l'appareil du destinataire, comme c'est déjà le cas pour d'autres services d'aperçu.
  • Si la récupération reste sur l'appareil, exiger une action explicite pour chaque message et empêcher un observateur en arrière-plan de la relancer après fermeture de la conversation.
  • Décrire clairement le flux de données dans l'aide relative à la vie privée, afin que « aperçus automatiques » ne soit pas compris comme « aperçus incapables de révéler votre IP ».
Gravité

À propos du score

Le score de base CVSS dépend du vecteur d'attaque, de l'interaction et de l'impact sur la confidentialité, l'intégrité et la disponibilité. Une IP et quelques métadonnées relèvent de C:Low, même si la victime intervient très peu. L'absence de clic ne changerait que la métrique d'interaction, pas l'impact. Ici, le code ne démontre même pas la variante où le chat n'a jamais été ouvert : le vecteur justifié est UI:R, pour un score de base de 4.3.

Ce constat est réel et mérite une correction, avec une gravité moyenne. Un ancien brouillon le qualifiait de critique, en contradiction avec son propre CVSS et l'impact réel d'une fuite d'IP et de métadonnées. Je préfère publier un score défendable qu'un score exagéré.

Portée et limites du constat

Les points suivants ont également été examinés, mais ne font pas partie des effets revendiqués :

Vérifier par soi-même

Aucune capture d'écran n'est publiée ici. Le constat repose sur le chemin de code décrit et peut être reproduit avec ses propres appareils et un point de collecte sous son contrôle. Le principe :

Pour éviter ces requêtes, désactivez les aperçus automatiques de liens web dans les réglages. L'option « Afficher uniquement les aperçus de liens web » ne les bloque pas. Un contact enregistré peut obtenir des informations sur votre réseau en vous envoyant un lien.

Chronologie de la divulgation

Ce qui constituerait une correction

Je préfère mettre cette page à jour que la défendre. Elle indiquera « corrigé » lorsque la version distribuée récupérera les aperçus via l'infrastructure de Google, sans exposer l'IP du destinataire, ou exigera une action explicite sur l'appareil sans relance en arrière-plan après fermeture du chat. Un changement limité à un build interne ne suffit pas.


Tous les tests ont été réalisés sur mes appareils et comptes, vers des points de collecte que je contrôle. Aucun appareil, compte ou donnée d'autrui n'était impliqué. Ce rapport ne contient ni logiciel malveillant ni outil d'attaque : la reproduction consiste à envoyer un lien ordinaire vers son propre serveur. Les identifiants sont abrégés.