Une faille dans l'IA d'Atlassian volait vos données Confluence et Jira en un clic

Un employé clique sur un lien qui ressemble à un lien Atlassian ordinaire. En arrière-plan, l'assistant IA de l'entreprise se met à fouiller les tickets, les pages internes, les documents confidentiels, puis expédie le tout vers un serveur inconnu. Personne ne voit rien.

C'est exactement le scénario que des chercheurs en sécurité ont démontré sur Rovo, l'assistant IA d'Atlassian (l'éditeur de Jira, l'outil de suivi de projets, et de Confluence, la base de connaissances interne des entreprises). Deux équipes distinctes ont trouvé comment retourner cet assistant contre sa propre organisation. L'une des failles a été corrigée. L'autre était toujours ouverte au moment de sa publication.

Ici, on parle bien de Rovo, la couche IA transversale d'Atlassian, à ne pas confondre avec Atlassian Intelligence, qui ajoute de l'IA à l'intérieur de chaque outil pris séparément. Rovo, lui, voit tout à la fois : Jira, Confluence, Bitbucket (l'hébergement de code source), et une cinquantaine d'applications connectées comme Slack, Microsoft 365 ou Google Workspace.

Dans cet article :

• Un clic, et l'IA travaille pour l'attaquant
• La deuxième faille, celle qui ne se corrige pas d'un clic
• Pourquoi ce n'est pas qu'un bug Atlassian
• La stratégie Posthumain

Un clic, et l'IA travaille pour l'attaquant

La première faille porte un nom : RovoBlast. Elle a été trouvée par Varonis Threat Labs, une équipe de recherche en sécurité, et présentée à la conférence DEF CON 34. Comme d'autres attaques récentes sur les assistants IA, tout part d'un simple lien.

Le principe est presque enfantin. Rovo accepte un paramètre dans l'adresse web, rovoChatPrompt, qui préremplit directement sa fenêtre de discussion. Un attaquant y glisse ses propres instructions. La victime, déjà connectée à son compte, clique, et l'assistant exécute ces ordres avec les droits de l'utilisateur [1].

Aucun mot de passe volé, aucun contournement de permissions. Rovo traite simplement le texte fourni de l'extérieur comme s'il venait d'une source de confiance [2]. Plus troublant encore : les chercheurs ont pu laisser vide l'identifiant d'organisation dans le lien, et Atlassian routait quand même la requête vers l'espace de la victime, sans le moindre avertissement.

Pour mesurer les dégâts possibles, les chercheurs ont posé la question à Rovo lui-même : à quelles données as-tu accès ? La réponse listait Jira, Confluence, Bitbucket, Slack, Google Workspace, Microsoft 365, des bases de données, des fichiers téléversés et des pages web. Un outil interne de recherche autonome, ResearchAgent, a ensuite servi à aspirer ces données et à les recracher vers l'extérieur en une seule chaîne automatique [1].

Les chercheurs ont monté trois démonstrations : exfiltration de pages Confluence, de tickets Jira et de contenu SharePoint (l'espace documentaire de Microsoft) contenant des données personnelles. Un seul lien piégé suffisait généralement à déclencher la fuite. Atlassian a corrigé cette faille côté serveur le 8 juillet 2026, sans action requise des clients, et a versé une prime de 6 000 dollars au chercheur [3].

La deuxième faille, celle qui ne se corrige pas d'un clic

La seconde équipe, PromptArmor, a pris un autre chemin. Pas besoin de lien piégé cette fois : les instructions malveillantes sont cachées dans un document. Des ordres dissimulés dans le fichier, invisibles pour un lecteur humain mais parfaitement lisibles par l'IA [4].

Un employé téléverse ce fichier et demande à Rovo une tâche banale, du genre organiser ses tickets Jira. Les instructions cachées détournent alors l'assistant : il collecte discrètement des données accessibles et les envoie vers le serveur de l'attaquant. L'utilisateur, lui, ne voit que des suggestions de tickets, aucun signe de la fuite.

Le plus gênant tient dans un réglage. Beaucoup d'administrateurs coupent la recherche web de Rovo en croyant fermer toute sortie vers l'extérieur. L'attaque fonctionne quand même, car désactiver la recherche web ne supprime pas l'outil sous-jacent qui va chercher et ouvre des adresses web [3].

Cette technique porte un nom générique : l'injection indirecte d'instructions (indirect prompt injection), c'est-à-dire des ordres cachés dans un contenu que l'IA lit, et qu'elle confond avec une demande légitime. C'est aujourd'hui considéré comme l'un des problèmes les plus difficiles de l'IA en entreprise, classé risque numéro un par l'OWASP, l'organisation de référence en sécurité applicative [5].

PromptArmor a prévenu Atlassian en privé le 23 mai 2026. L'éditeur a ouvert un dossier, puis n'a plus donné de nouvelles. Après deux mois de relances sans réponse, les chercheurs ont publié le 5 août, en précisant que la faille restait exploitable. Le contraste est net : la faille RovoBlast, elle, a été corrigée en un peu plus d'un mois [3].

Aucune des deux failles n'a reçu d'identifiant CVE, la référence standard qui catalogue les vulnérabilités connues. Cette absence de numéro officiel ne veut pas dire absence de risque, un piège récurrent quand la sécurité de l'IA avance plus vite que ses procédures.

Pourquoi ce n'est pas qu'un bug Atlassian

Rovo n'est pas un gadget marginal. L'assistant a dépassé les 5 millions d'utilisateurs actifs mensuels selon la lettre aux actionnaires d'Atlassian pour le deuxième trimestre de son exercice 2026, et l'IA est activée par défaut sur les offres Standard, Premium et Enterprise [6].

Le problème dépasse largement une entreprise. Varonis avait déjà décrit une attaque quasi identique en janvier 2026 sur Microsoft Copilot, baptisée Reprompt, reposant sur le même principe de paramètre transformé en instruction [1]. Le motif se répète d'un assistant à l'autre.

La racine est structurelle. Un assistant IA moderne lit du contenu externe non fiable, un fichier ou une page web, tout en gardant un accès privilégié aux systèmes internes. Or les modèles actuels distinguent encore mal ce qu'on leur demande de traiter de ce qui tente de leur donner des ordres [5].

Plus l'agent peut agir seul, plus le rayon d'explosion grandit. Quand une IA ne fait que résumer, le risque est faible. Quand elle peut chercher, se connecter et agir en votre nom, une seule entrée mal classée transforme un gain de productivité en fuite de données. Le vrai enjeu se déplace du contenu vers le contrôle laissé à l'agent.

On retrouve ce fil rouge dans nos articles sur les agents IA qui débordent de leur cadre : la puissance qu'on leur donne est aussi la surface qu'on offre aux attaquants. Rovo n'a pas exposé ce risque par négligence, mais parce qu'il vit au cœur du périmètre de confiance de l'entreprise, avec accès, identité et autonomie par défaut.

La stratégie Posthumain

Bonne nouvelle d'abord : pour la faille RovoBlast, vous n'avez rien à faire. Le correctif d'Atlassian est côté serveur, il s'applique automatiquement à tous les espaces cloud. Aucune mise à jour à installer.

Le vrai chantier est ailleurs, sur la seconde faille et sur la classe entière d'attaques qu'elle représente. Et là, il n'existe pas de bouton magique. Les chercheurs eux-mêmes le disent : l'injection d'instructions ne se filtre pas, elle se contient. Tout l'enjeu se déplace alors vers une autre cible : réduire ce que l'IA peut faire de dangereux une fois qu'elle s'est fait retourner.

Comprendre ce que Rovo peut vraiment voir

La première chose à intégrer, c'est que Rovo agit avec les droits de l'utilisateur, pas au-delà. Il ne casse pas les permissions Jira ou Confluence, il exploite celles qui existent déjà. Autrement dit, l'hygiène des droits d'accès de votre organisation devient la vraie ligne de défense.

Un employé qui a accès à trop de choses devient, via l'IA, une passerelle vers trop de choses. Le périmètre de la fuite, c'est le périmètre de ses habilitations. Reste une question concrète : quels réglages, précisément, faut-il activer aujourd'hui pour que cette IA ne devienne pas une porte grande ouverte ?