Des chercheurs en sécurité ont mis en lumière plusieurs façons dont l’injection de prompts peut détourner le comportement d’un assistant IA. Dans le cas d’Atlassian, les investigations décrivent un scénario où Rovo pourrait collecter des informations Jira ou Confluence accessibles à un utilisateur connecté, puis les transmettre à un serveur contrôlé par l’attaquant.
Les détails sont importants : l’exposition ne correspond pas à une “prise de contrôle” générale, mais plutôt à un mécanisme qui abuse des capacités déjà autorisées. Surtout, tous les chemins décrits ne sont pas au même stade de correction.
Pourquoi l’injection de prompts est au cœur du risque
Les deux approches rapportées s’appuient sur un principe commun : placer des instructions non désirées dans du contenu que l’assistant est amené à traiter. En pratique, le modèle peut traiter une partie de ce contenu comme des “consignes” à suivre, même si elles proviennent d’une source contrôlée par l’attaquant.
Ce type d’attaque est généralement décrit comme une injection de prompts indirecte : l’utilisateur (ou l’environnement de l’utilisateur) fournit à Rovo un élément “empoisonné”, et l’assistant effectue ensuite des actions qui conduisent à une fuite de données.
Scénario 1 : des instructions cachées dans le contenu (route liée à PromptArmor)
PromptArmor décrit une chaîne où les instructions sont dissimulées dans un fichier que Rovo lit. Selon le rapport, le simple fait d’ouvrir un fichier suffirait à déclencher le comportement de collecte et d’exfiltration, sans étape d’approbation distincte.
Le scénario présenté est le suivant :
- Un utilisateur téléverse un document contenant l’injection.
- Il demande à Rovo d’organiser ses tickets Jira.
- Rovo interroge Jira et Confluence comme demandé.
- Les informations trouvées sont ensuite “repackagées” dans une requête vers une URL contrôlée par l’attaquant.
- L’attaquant récupère les contenus via ses propres journaux de serveur.
PromptArmor indique aussi que, lorsqu’un utilisateur revient plus tard dans la conversation, il peut voir des mises à jour suggérées pour les tickets, sans détecter clairement que des données auraient été extraites et envoyées à l’extérieur.
Web search désactivée : le contournement reste possible selon PromptArmor
Un point notable concerne le rôle du réglage web search. Atlassian propose un paramètre au niveau organisationnel permettant d’élargir les sources utilisées par Rovo vers des sites publics. PromptArmor affirme que désactiver cette option ne stoppe pas la chaîne, car l’exfiltration reposerait sur une autre capacité de récupération via URL.
Le rapport souligne un aspect central : rien ne vérifierait si l’assistant ouvre une URL construite par lui-même, ou si cette URL correspond à un périmètre approuvé.
Le rapport mentionne également une autre voie possible : Rovo peut rendre des images Markdown issues des sorties du modèle. Toutefois, les éléments publiés ne prouvent pas une chaîne complète basée uniquement sur ce chemin pour Rovo.
Scénario 2 : un paramètre d’URL précharge les instructions (route liée à Varonis)
Varonis Threat Labs décrit une autre technique, associée à un comportement de type “un clic”. Dans ce scénario, l’attaquant exploiterait un paramètre nommé rovoChatPrompt dans l’URL d’accès à Rovo.
L’idée est la suivante : l’URL peut contenir un prompt complet, chargé à l’avance dans Rovo Chat. Une fois l’utilisateur connecté (victime) cliquant sur le lien, Rovo exécute les instructions avec ses propres privilèges et envoie ensuite les résultats à un serveur contrôlé par l’attaquant.
Varonis qualifie la faiblesse de RovoBlast et indique que le sujet a été divulgué via Bugcrowd. La preuve de concept rapportée montre comment l’attaquant peut demander à Rovo de récupérer des informations accessibles à la victime et les transporter vers un environnement externe au moyen d’un appel réseau contrôlé.
Exemple de données exfiltrées
D’après Varonis et la divulgation Bugcrowd, l’attaquant a démontré l’exfiltration d’une clé API privée issue de Confluence. Le rapport mentionne aussi que la technique “un clic” a été testée contre Jira et contre des données accessibles via des connecteurs impliquant SharePoint et Outlook.
Sur Bugcrowd, le problème est classé avec une priorité P2 et a donné lieu à une prime de 6 000 dollars. Varonis indique que l’éditeur a corrigé le problème côté serveur le 8 juillet 2026, et que le rapport a été validé par le rapporteur.
Le point clé : une correction est confirmée, l’autre dépend des réglages
La comparaison entre les deux scénarios montre pourquoi il ne faut pas conclure trop vite. D’un côté, la “route un clic” associée aux paramètres d’URL est décrite comme corrigée côté Atlassian. De l’autre, la route liée au contenu lu par Rovo (injection cachée dans un fichier) reste, selon les informations disponibles, non confirmée comme fermée à la date de publication.
Autre détail important : aucune des divulgations ne mentionne d’identifiant CVE. De plus, les recherches rapportées n’ont pas fait remonter d’entrée dans des catalogues courants à la date indiquée.
Les rapports précisent aussi que les mesures immédiates ne se résument pas à “appliquer un patch”. Dans le cas du vecteur lié aux paramètres de lien, la fermeture est déjà réalisée côté Atlassian. Pour le chemin “contenu-borne”, l’impact dépend notamment du périmètre d’accès accordé à Rovo : quels apps et quelles équipes (groupes) peuvent l’utiliser.
Permissions et limites : pas une escalade d’autorisation universelle
Il est essentiel de cadrer le risque. Les scénarios décrivent une exfiltration de données que l’utilisateur connecté peut déjà atteindre via les permissions configurées dans les produits Atlassian (Jira famille, Confluence) et via les applications tierces connectées.
Autrement dit, il ne s’agit pas d’une démonstration d’une autorisation “tenant-wide” contournée. La menace réside plutôt dans le fait qu’un assistant IA, une fois doté d’un accès légitime, peut être détourné pour utiliser cet accès d’une manière non souhaitée.
Cette nuance aide à dimensionner les mesures : le contrôle à renforcer porte sur la façon dont Rovo est autorisé à accéder à des contenus et à quels périmètres ces accès s’appliquent.
Que peuvent faire les organisations dès maintenant ?
Atlassian décrit que Rovo est activé par défaut pour les apps dans les offres Standard, Premium et Enterprise, et que les fonctionnalités peuvent être disponibles pour tous les membres de l’organisation. Cependant, les administrateurs disposent de leviers pour limiter l’exposition.
Limiter Rovo par application et par groupe
Le point d’action le plus concret consiste à vérifier quels apps et quels groupes d’utilisateurs ont accès à Rovo. Atlassian indique qu’un blocage de certaines fonctionnalités pour des apps supportées peut désactiver les capacités d’IA associées à ces apps, y compris des fonctions telles que Agents et Chat.
Pour les environnements Enterprise, l’expérience d’accès plus récente permet de gérer Rovo finement par application et par groupe.
Attention aux effets de bord sur un site multi-apps
Une mise en garde est mentionnée dans la documentation : dans un site où plusieurs apps de la famille Jira sont présentes, bloquer une app ne suffit pas nécessairement à retirer les capacités partagées. Par exemple, Rovo Search, Chat et Create peuvent rester disponibles tant qu’une app Jira sur ce site conserve Rovo activé.
Le réglage web search n’est pas une barrière de sécurité totale
Un enseignement ressort nettement des rapports : le fait de désactiver le paramètre web search ne garantit pas l’arrêt de toutes les chaînes décrites. PromptArmor soutient que la route identifiée continue de fonctionner même lorsque la recherche web est mise hors service, car l’exfiltration s’appuierait sur une autre mécanique de récupération via URL.
De ce fait, il est prudent de ne pas considérer le toggle web search comme une “frontière” complète. Le contrôle principal doit rester centré sur l’étendue de l’accès à Rovo (apps, groupes, connecteurs) et sur les permissions sous-jacentes.
État des usages observés : pas de preuve d’attaque réelle publiée
Les divulgations indiquent qu’aucune preuve n’est rapportée montrant l’exploitation de ces techniques contre une organisation réelle. En revanche, l’absence de mention ne signifie pas qu’aucune activité n’a eu lieu : cela reflète seulement ce que les rapports contiennent à la date indiquée.
Enfin, les statuts ne sont pas identiques. Le chemin lié aux paramètres d’URL est présenté comme corrigé côté Atlassian (le 8 juillet 2026). L’autre route, associée à l’injection via contenu lu, était encore décrite comme non confirmée fermée lors de la publication du 5 août 2026.
Conclusion : cadrer l’accès est la stratégie la plus robuste
Les rapports sur l’injection de prompts autour de Rovo mettent en évidence un risque réaliste : un assistant IA peut suivre des “instructions” dissimulées et réutiliser l’accès déjà accordé à un utilisateur connecté pour collecter et transmettre des données.
La bonne nouvelle est qu’un des vecteurs décrits a été corrigé côté serveur. La leçon pour les organisations, elle, reste valable : au-delà des paramètres isolés comme la recherche web, il faut revoir soigneusement l’accès à Rovo par application et par groupe, resserrer les permissions et limiter le périmètre des connecteurs quand c’est possible.
Source: https://thehackernews.com/2026/08/atlassian-rovo-can-be-tricked-into.html
