Exfiltration de données Atlassian Rovo : que s'est-il passé et que doivent vérifier les administrateurs Jira ?

En résumé : L'exfiltration de données via Atlassian Rovo repose sur une attaque par injection indirecte de prompt (indirect prompt injection) divulguée par PromptArmor à Atlassian le 23 mai 2026 et rendue publique le 5 août 2026. Une instruction dissimulée dans un fichier téléversé demande à Rovo d'intégrer des contenus Jira et Confluence au sein d'une URL, puis de l'ouvrir. L'attaquant récupère ensuite ces données directement dans les journaux de son serveur. Désactiver la recherche web ne suffit pas à bloquer l'attaque.

Si votre équipe utilise Jira et Confluence avec Rovo activé, cela vaut la peine d'y consacrer vingt minutes de temps d'administration. Cette attaque ne nécessite aucun clic, aucune invite d'approbation et aucun compte compromis. Un simple fichier téléversé et une requête ordinaire suffisent.

Au programme ci-dessous : le déroulement de l'attaque étape par étape, pourquoi l'option de configuration évidente passe à côté du problème, le statut des correctifs au 27 octobre 2026 et une liste de contrôle à appliquer dès aujourd'hui. Nous développons Sharkly, un espace de travail où des agents de code prennent en charge des tâches depuis un tableau partagé ; nous sommes donc confrontés au même défi. L'injection de prompt reste un problème non résolu dans tout l'écosystème. La véritable question est de savoir à quoi un agent détourné peut accéder en fonction des outils mis à sa disposition.

Que s'est-il passé : l'injection de prompt sur Rovo étape par étape

Le rapport de PromptArmor décrit une chaîne d'attaque en cinq étapes :

1. Le fichier piégé. Une victime téléverse un document intitulé « Backlog Guide ». Celui-ci contient une instruction masquée destinée au modèle, et non au lecteur humain.
2. La requête anodine. Plus tard, la victime demande à Rovo d'organiser ses tickets Jira.
3. La recherche. Rovo extrait des tickets Jira et des pages Confluence, et lit au passage le fichier piégé.
4. La fuite. L'instruction ordonne à Rovo d'ajouter ces informations à l'URL d'un attaquant et de l'ouvrir à l'aide de son outil de récupération d'URL. Le serveur de l'attaquant enregistre la requête dans ses logs, données comprises.
5. La dissimulation. La victime reçoit des suggestions de tickets tout à fait cohérentes, sans le moindre indice laissant penser que des données ont fuité.

Aucun être humain ne valide la requête sortante, ce qui amène PromptArmor à la qualifier d'attaque « zero-click ». Leur synthèse quant à la portée de la faille : toute donnée accessible par l'agent dans Atlassian peut être compromise, y compris les contenus provenant de connecteurs tiers.

Le fichier n'est qu'un point d'entrée parmi d'autres. PromptArmor mentionne également les tickets de support provenant de l'extérieur, les résultats web lorsque la recherche web est active, ainsi que les connecteurs tiers. Tout élément lu par Rovo constitue un vecteur potentiel pour dissimuler une instruction malveillante.

Pourquoi désactiver la recherche web ne suffit pas

Atlassian met à disposition des administrateurs une option « Web search » (recherche web) pour Rovo, et de nombreuses équipes l'ont désactivée par précaution. PromptArmor indique que l'attaque fonctionne toujours une fois cette option coupée, car ce commutateur ne supprime pas l'outil chargé d'ouvrir les URL. De plus, cet outil n'effectuait aucune vérification sur les URL construites directement par l'agent.

Un paramètre portant le nom d'une fonctionnalité ne garantit pas la suppression technique de la capacité sous-jacente.

La page d'administration d'Atlassian consacrée à l'accès web et à la recherche web présente désormais deux options. « Web access » contrôle la capacité de Rovo à accéder aux pages web publiques ; « Web search » en dépend. Toutes deux sont activées par défaut. La page avertit également que « même si l'accès web est désactivé, un outil connecté peut ne pas être bloqué ». [VERIFY 2026-10-27 : aucune source publique ne confirme si la désactivation de Web access bloque le vecteur de récupération d'URL utilisé par PromptArmor. N'affirmez pas aux lecteurs que c'est le cas.]

Existe-t-il un second canal d'exfiltration ?

Oui. PromptArmor souligne que Rovo affiche les images au format Markdown dans ses réponses. Une URL d'image pointant vers le serveur d'un attaquant fait fuiter toutes les données qui y sont encodées dès que le navigateur charge l'image. PromptArmor signale ce canal mais ne détaille pas de chaîne d'exploitation complète sur Rovo pour celui-ci.

Chronologie de divulgation et statut des correctifs

Au 27 octobre 2026, nous n'avons trouvé aucun communiqué, avis de sécurité ou correctif confirmé d'Atlassian pour ce vecteur d'attaque. Le fil de discussion Hacker News consacré à l'article (306 points, 138 commentaires) ne contient pas non plus de réponse d'Atlassian. [VERIFY before publish : vérifier à nouveau les avis de sécurité d'Atlassian et la page de PromptArmor pour voir s'il y a une mise à jour.]

En quoi cela diffère-t-il de RovoBlast ?

Il s'agit de failles distinctes. Varonis Threat Labs a publié RovoBlast, où un lien spécialement conçu exploitait le paramètre d'URL rovoChatPrompt pour injecter des instructions dans le Rovo Chat d'une victime. Varonis l'a signalé via le programme Bugcrowd d'Atlassian et indique que la faille est corrigée. RovoBlast nécessitait un clic. L'attaque de PromptArmor, elle, exige simplement que la victime accomplisse son travail habituel. La correction de l'une ne préjuge en rien de la résolution de l'autre.

Le schéma sous-jacent : le trio fatal

Simon Willison a baptisé cette configuration le trio fatal (lethal trifecta) : un agent disposant d'un accès à des données privées, exposé à des contenus contrôlés par un attaquant et doté d'un moyen de communiquer vers l'extérieur. Lorsque ces trois conditions sont réunies, un attaquant peut manipuler l'agent pour qu'il exfiltre vos données.

Dans un environnement Jira et Confluence, Rovo réunit par conception ces trois composantes. C'est précisément ce qui fait son utilité.

La discussion sur Hacker News a mis en avant plusieurs pistes de remédiation :

• Ne récupérer que les URL saisies par un humain ou renvoyées par un outil de confiance. Jamais une URL construite par l'agent lui-même. Simon Willison a souligné qu'avec des DNS wildcard, des données peuvent fuiter rien qu'à travers le sous-domaine.
• Les URL pré-indexées aident, mais permettent des fuites lentes. Johann Rehberger (wunderwuzzi) a fait remarquer qu'un attaquant peut malgré tout exfiltrer des données à raison d'un caractère par requête.
• Les listes d'autorisation de domaines conviennent aux agents à périmètre restreint. Si un agent n'a besoin que de trois domaines, limitez-le strictement à ces trois-là.

Aucune de ces solutions ne résout le problème au niveau du modèle lui-même. Elles restreignent le canal de sortie, car les modèles continuent parfois d'exécuter le texte injecté. C'est pour cette raison que l'OWASP place l'injection de prompt en tête de sa liste des risques liés aux LLM, sous la référence LLM01.

Liste de contrôle de sécurité Rovo : ce que les administrateurs Jira doivent vérifier dès aujourd'hui

Chaque étape vise à neutraliser l'un des piliers du trio fatal.

1. Cartographier les accès de Rovo. Répertoriez chaque application, projet, Espace et connecteur. Rovo respecte les autorisations des utilisateurs, de sorte qu'une session détournée a accès à tout ce que l'utilisateur à l'origine de la requête peut consulter. Atlassian précise que Rovo lui-même ne peut pas être désactivé globalement, mais les administrateurs peuvent bloquer l'accès de Rovo application par application.
2. Identifier les contenus externes. Les tickets de centre de services, les conversions d'e-mails en tickets, les pièces jointes et les documents synchronisés contiennent du texte que votre équipe n'a pas rédigé. Ce sont autant de surfaces d'injection.
3. Auditer les connecteurs. Déconnectez ceux qui sont inutilisés. Pour Google Drive et SharePoint, utilisez la liste de blocage ou d'autorisation du connecteur. Excluez du périmètre les contenus juridiques, RH, financiers et liés à la réponse aux incidents, comme le préconise également Varonis.
4. Vérifier les deux options web. Désactivez « Web search » et « Web access » si personne n'en a l'utilité. Ne considérez toutefois aucune de ces options comme une parade à cette attaque tant qu'Atlassian ne l'a pas confirmé.
5. Surveiller le trafic sortant. Repérez les domaines externes inattendus pour les images et les liens dans les journaux de votre proxy.
6. Tester à l'aide d'un prompt piégé. Intégrez une instruction inoffensive dans un ticket de test demandant à Rovo d'interroger une URL que vous contrôlez. Si la requête aboutit, vous avez votre réponse.
7. Sensibiliser votre équipe. Une simple demande du type « Organise mes tickets » peut exécuter des instructions masquées dans une pièce jointe.

Si vos agents de code récupèrent également des tâches depuis Jira, consultez notre article sur l'attribution de tickets Jira à un agent IA.

Les mêmes questions se posent pour les agents de code

Les agents de code lisent en permanence du texte non fiable : corps des tickets, commentaires de pull requests, README des dépendances, documentation en ligne. Ils ont accès à votre code source et disposent généralement d'un accès réseau. C'est exactement le trio fatal, transposé dans un terminal plutôt que dans une fenêtre de chat. Nous avons expliqué pourquoi un modèle plus performant ne remplace pas une stricte délimitation du périmètre dans notre article sur l'injection de prompt et les garde-fous pour agents.

Sharkly ne rend pas un agent immunisé contre les injections, et aucun outil ne peut le promettre aujourd'hui. Il vous offre en revanche un cadre pour définir le périmètre avant le lancement d'une exécution. Les agents s'exécutent sur des Machines que vous connectez, via un service local qui établit la connexion vers l'extérieur, si bien qu'une configuration type ne requiert aucun port entrant ouvert. Les invités ne peuvent accéder qu'aux Espaces auxquels ils sont explicitement ajoutés. Les actions tierces dans les workflows d'automatisation passent par des connecteurs que vous autorisez. La documentation recommande de ne jamais enregistrer de mots de passe, jetons ou clés dans les instructions des Skills, et d'accorder aux dépôts uniquement les privilèges strictement nécessaires à la tâche.

Les agents recherchent, exécutent et rendent compte. Les humains accordent les autorisations et valident le résultat. Pour en savoir plus, consultez nos articles sur ce qu'un agent de code devrait ou ne devrait pas être autorisé à faire et sur les étapes clés où placer des points de validation.

Conclusion

L'attaque contre Rovo n'a rien d'extravagant. Un fichier, une requête banale et un outil d'ouverture d'URL sans restriction sur ses destinations ont suffi, tandis que le paramètre que la plupart des équipes ont tenté d'utiliser ne couvrait pas cet outil. À l'heure où nous écrivons ces lignes, ce vecteur d'attaque via du contenu tiers ne dispose d'aucun correctif confirmé.

Considérez la délimitation du périmètre comme le levier de contrôle qui vous appartient. Cartographiez ce que Rovo lit, supprimez les connecteurs inutilisés et testez vous-même les requêtes sortantes. Posez-vous ensuite trois questions pour chaque agent utilisé par votre équipe : que peut-il lire, quels textes non fiables peuvent l'atteindre et vers où peut-il envoyer des données ? Pour réunir vos agents de code sur un tableau unique avec un périmètre défini pour chaque tâche, Sharkly est gratuit pour les organisations comptant jusqu'à 5 personnes.

FAQ

Qu'est-ce que l'attaque par exfiltration de données d'Atlassian Rovo ?

Il s'agit d'une injection indirecte de prompt révélée par PromptArmor le 5 août 2026. Des instructions masquées amènent Rovo à concaténer des données Jira et Confluence à l'URL d'un attaquant, puis à ouvrir cette dernière.

La désactivation de la recherche web de Rovo protège-t-elle mes données ?

Non, d'après PromptArmor. Ce paramètre ne désactive pas l'outil capable d'ouvrir des URL.

Atlassian a-t-elle corrigé cette injection de prompt sur Rovo ?

Nous n'avons trouvé aucun communiqué ni correctif confirmé d'Atlassian pour le vecteur documenté par PromptArmor au 27 octobre 2026. La vulnérabilité distincte RovoBlast a quant à elle été corrigée.

Rovo Dev est-il concerné ?

Rovo Dev est l'agent de code d'Atlassian, un produit distinct de Rovo dans Jira et Confluence, et le rapport de PromptArmor ne le concerne pas. Consultez notre guide sur l'offre gratuite de Rovo Dev.

Les agents de code sont-ils vulnérables à la même attaque ?

Oui. Tout agent qui traite du texte non fiable et a accès au réseau présente le même risque. Limitez ce qu'il peut lire, les identifiants auxquels il a accès et les destinations vers lesquelles il peut transmettre des données.