Google Workspace : l’attaque peut commencer par OAuth, et non par la messagerie

La nouvelle chaîne : d’abord le token, puis Gmail

Une analyse publiée le 14 août 2026 affirme que les compromissions associées à Vercel et Composio pourraient relever d’un même schéma : l’accès à Google Workspace ne commence pas nécessairement par la boîte mail, mais par un token OAuth compromis ou une intégration autorisée.

Cette distinction modifie le modèle traditionnel de l’account takeover. Auparavant, la séquence la plus courante impliquait un message de phishing, le vol des identifiants, l’accès à Gmail et Drive, puis un mouvement latéral vers d’autres services. Dans ce scénario, l’attaquant peut au contraire pénétrer dans l’environnement via une application connectée et n’atteindre la messagerie que dans un second temps.

La messagerie reste donc centrale, mais pas toujours comme point d’entrée. Une fois accessible, elle peut devenir un multiplicateur d’incident : elle contient souvent des liens de réinitialisation de mots de passe, des magic links, des identifiants conservés dans les conversations et des références à des applications internes.

L’analyse est signée par Rajan Kapoor, VP Security de Material Security, également à l’origine de la publication. Les détails techniques concernant les incidents de Vercel et Composio n’ont pas été communiqués : aucun identifiant CVE, aucune campagne attribuée ni aucun groupe de menaces associé n’ont été mentionnés.

Pourquoi OAuth peut survivre à une réinitialisation du mot de passe

Un token OAuth permet à une application d’agir au nom de l’utilisateur, selon les autorisations définies dans les scopes. Si le token est dérobé, l’attaquant peut l’utiliser pour accéder aux ressources autorisées sans nécessairement connaître le mot de passe.

Cette situation pose un problème opérationnel aux équipes de sécurité. Une réinitialisation du mot de passe peut ne pas suffire à interrompre l’accès, car le token peut rester valide. Selon l’analyse, certains tokens peuvent par ailleurs ne pas présenter de date d’expiration évidente et être difficiles à détecter si l’organisation surveille uniquement les connexions, les mots de passe et l’activité des utilisateurs.

Le risque augmente lorsque le token appartient à une application tierce. La compromission du fournisseur ou de l’intégration peut se transformer en attaque de supply chain, avec un accès apparemment légitime à l’environnement de l’entreprise.

La séquence envisagée se déroule en plusieurs étapes :

1. un token OAuth est compromis ;
2. l’attaquant exploite les scopes accordés à l’application ;
3. Gmail et Drive deviennent accessibles ;
4. le compte est ciblé sans vol initial du mot de passe ;
5. le contenu des messages et des documents est exploité pour atteindre d’autres systèmes ;
6. les données sont collectées ou transférées vers des tiers.

L’aspect le plus difficile à détecter réside dans la légitimité apparente de l’accès. L’application peut être autorisée, le token peut être valide et l’utilisateur peut ne constater aucun signal évident sur son compte.

Les agents IA transforment les privilèges en actions automatisées

La même dynamique peut se produire sans token volé. Les utilisateurs connectent de plus en plus souvent des agents IA à Google Workspace via OAuth, leur permettant de lire des e-mails, de rechercher des documents dans Drive et d’agir au nom de personnes réelles.

Un agent peut donc accéder à des données et à des services en fonction des scopes qui lui sont attribués. Le problème ne tient pas uniquement à un comportement malveillant ou à une prompt injection. Un système peut fonctionner comme prévu tout en disposant de privilèges disproportionnés par rapport à la tâche demandée.

Un agent chargé de rechercher des informations dans une boîte mail pourrait, par exemple, également consulter des conversations contenant des identifiants ou des documents stockés dans des disques partagés. S’il rencontre des instructions ambiguës, des contenus manipulés ou une chaîne décisionnelle non prévue par les développeurs, il peut utiliser ces informations pour effectuer des actions supplémentaires.

La chaîne peut notamment comprendre :

• la lecture de messages ou de dossiers au-delà du périmètre nécessaire ;
• l’identification d’identifiants, de données personnelles ou d’informations confidentielles ;
• l’ouverture de liens et l’envoi de requêtes vers d’autres services ;
• le passage d’une application à une autre ;
• le transfert de données à un tiers.

Dans ce cas, il n’est pas indispensable qu’un attaquant contrôle directement l’agent. Le risque naît de l’interaction entre des autorisations trop larges, les contenus présents dans l’environnement et la capacité du système à exécuter automatiquement des actions.

Un opérateur humain disposant des mêmes privilèges peut appliquer les politiques internes et faire preuve de discernement avant d’utiliser une information. Un agent, en revanche, tend à exécuter la tâche en fonction des instructions et des accès disponibles. Le token OAuth attribué à une personne et celui accordé à un système automatisé peuvent donc exposer des privilèges similaires, mais selon des modalités opérationnelles très différentes.

Gmail et Drive deviennent des points d’expansion

Dans ce modèle, Gmail et Drive ne sont pas seulement des réservoirs d’informations. Ils deviennent des infrastructures de mouvement latéral.

Un message peut contenir un lien de réinitialisation de mot de passe. Un document peut inclure une clé d’accès, une procédure opérationnelle ou une référence à un service interne. Un disque partagé peut exposer des données à un nombre d’utilisateurs et d’applications supérieur à celui qui était prévu.

La conséquence est qu’une compromission apparemment limitée peut s’étendre rapidement. L’accès à une application autorisée permet de lire les contenus ; ces contenus peuvent ensuite fournir les moyens d’atteindre d’autres comptes et systèmes.

L’impact potentiel couvre les e-mails, les documents professionnels, les identifiants, les informations personnelles identifiables et les données conservées par des applications connectées. L’automatisation peut accroître la vitesse et l’ampleur des opérations, notamment lorsque les outils d’IA aident à repérer les informations utiles et à les combiner entre plusieurs services.

La source n’attribue aucune classification formelle de gravité et ne fournit aucun indicateur de compromission à rechercher. Elle ne précise pas non plus les versions logicielles concernées, les produits vulnérables ni les échéances de remédiation. Le cas porte sur le modèle d’accès et de contrôle, et non sur une faille identifiée par un CVE.

Comment réduire le risque dans un environnement Workspace

La défense ne devrait pas se concentrer uniquement sur le filtre antiphishing ou la protection des comptes utilisateurs. La première mesure consiste à inventorier les applications, les tokens OAuth et les scopes effectivement accordés, tout en vérifiant l’évolution du comportement des intégrations.

Il ne suffit pas de savoir qu’une application est autorisée. Il faut observer quelles données elle lit, à quelle fréquence, auprès de quels utilisateurs, et si son activité évolue par rapport au comportement attendu. Un accès anormal peut signaler l’utilisation d’un token volé comme l’activité d’un agent légitime dépassant le cadre de sa mission.

Des contrôles portant sur les données sont également nécessaires :

• identifier les e-mails contenant des identifiants, des PII et des liens de récupération ;
• vérifier l’accessibilité des disques partagés ;
• réduire les scopes OAuth non indispensables ;
• appliquer le principe du moindre privilège aux utilisateurs, aux applications et aux agents automatisés ;
• contrôler les variations soudaines de l’activité des intégrations.

La messagerie nécessite une protection spécifique. En plus de bloquer le phishing, les payloads conçus pour contourner les protections et les attaques de type attacker-in-the-middle, il est utile d’empêcher qu’une boîte compromise devienne automatiquement un référentiel opérationnel pour l’attaquant. Les contenus les plus sensibles peuvent être masqués ou soumis à une vérification step-up avant leur accès.

La même règle doit s’appliquer aux agents IA. Un système autorisé à rechercher des informations dans la messagerie ne devrait pas pouvoir récupérer sans contrôle supplémentaire des identifiants, des liens de réinitialisation ou des données inutiles à son activité.

Enfin, la visibilité doit corréler les événements liés aux e-mails, à OAuth, à Drive et aux comptes. Surveiller ces éléments séparément laisse des angles morts entre les applications, précisément ceux qui permettent à un token légitime ou compromis de transformer un accès initial en exfiltration et en mouvement latéral.