Atlassian Rovo alerte de sécurité révèle des vecteurs d'exfiltration de données des utilisateurs authentifiés par URL et contenu chargé

Deux équipes de sécurité indépendantes, décrites en juillet et août 2026, peuvent être amenées à extraire des données auxquelles un utilisateur authentifié a déjà accès et à les envoyer à un serveur externe contrôlé par un attaquant. La découverte confirmée et fermée par Atlassian implique une chaîne qui a été activée à partir d'un paramètre URL (rovoChatPrompt); une autre, publiée par une entreprise différente, décrit une injection d'instructions cachées dans le contenu que traite Rovo et dont l'état de médiation n'a pas été publiquement confirmé par le fabricant au moment des communications originales..

Faits confirmés: Varonis Menace Labs a signalé qu'un paramètre URL (rovoChatPrompt) pouvait précharger des instructions malveillantes sur Rovo Chat afin qu'un utilisateur authentifié qui clique sur un lien exécute ces instructions avec ses privilèges et les données de l'assistant exfilters ; ce rapport a été divulgué par Bugcrowd, et l'enregistrement de Bugcrowd indique qu'Atlassian a déployé un arrangement côté serveur le 8 juillet 2026 et que l'enquêteur a validé la correction. Le 5 août 2026, ProptArmor a publié séparément un test de concept dans lequel un fichier téléchargé avec des instructions cachées a amené Rovo à rechercher du contenu interne et ouvrir une URL externe avec ces résultats, sans l'approbation supplémentaire explicite de l'utilisateur. La correction vectorielle basée sur le lien est confirmée; le statut de chaîne basé sur le contenu a été décrit par son découvreur comme non résolu lors de sa publication.. En outre, les recherches publiques dans les bases de données sur la vulnérabilité indiquées par les chercheurs eux-mêmes (p. ex., la DNV et le catalogue de la CISA) n'ont pas montré d'identificateurs ni d'entrées associés à ces défaillances au 8 août 2026 ( NVD, CISA KEV).

Comment les chaînes décrites fonctionnent techniquement: Rovo fonctionne avec les autorisations de l'utilisateur authentifié et vous pouvez consulter Jira, Confluence et connecteurs externes selon les paramètres et la portée autorisée. Dans la variante détectée par Varonis, un paramètre URL a pré-injecté une invite complète dans la session Rovo; en un seul clic d'un utilisateur authentifié, l'assistant exécute ces instructions, recueille des informations accessibles aux utilisateurs (par exemple des tickets ou des pages) et les intègre dans le chemin d'une image ou une requête que Rovo obtient - cette requête vient au serveur attaquant où elle est enregistrée. Dans la variante publiée par ProptArmor, l'attaquant a inséré des instructions dans un fichier chargé par l'utilisateur; Rovo a traité une partie du contenu du fichier comme des directives et a effectué des recherches internes et une requête sortant vers une URL construite avec les résultats. Dans les deux cas, une élévation des privilèges n'est pas démontrée : ce qui ressort est ce que l'utilisateur authentifié pouvait déjà voir, mais sans que l'utilisateur ait consciemment approuvé l'exfiltration.

Ce que cela implique et qui il affecte: l'impact principal est l'exfiltration de données auxquelles un utilisateur légitime a accès sans que cet utilisateur ait explicitement initié le transfert. Ce n'est pas un contournement des permissions de niveau locataire qui vous permet de voir des informations en dehors de la portée normale de l'utilisateur, mais un nouveau vecteur par lequel les données autorisées peuvent quitter l'organisation. Dans les organisations où Rovo est activé par défaut (documenté par Atlassian pour les plans Standard, Premium et Enterprise), toute personne ayant accès à ces fonctions pourrait par inadvertance activer l'une de ces chaînes. Le risque est plus élevé dans les environnements avec des connecteurs larges (SharePoint, Outlook, clés API dans Confluence, etc.), où un seul utilisateur peut consulter des données sensibles.

Ce qui est confirmé et ce qui n'est pas: confirmé est que la chaîne de paramètres URL a été signalée, corrigée par Atlassian et validée par le chercheur; confirmé est également que ProptArmor a publié un test de concept et a déclaré que sa méthode fonctionnait toujours avec l'option de "recherche web" désactivée à Rovo. Il n'est pas confirmé si Atlassian a appliqué des changements supplémentaires après le 5 août qui atténuent l'itinéraire décrit par ProptArmor; il n'y a pas non plus de preuve d'exploitation réelle dans les divulgations publiques originales dans les environnements clients. Au 8 août, il n'y avait aucune entrée publique dans le NVD ou le catalogue de la CISA associé à ces chaînes.

Mesures spécifiques à prendre immédiatement par les gestionnaires et les utilisateurs: 1) Examiner les applications et les groupes qui ont permis Rovo:: Dans les organisations ayant des contrôles administratifs, limiter Rovo aux groupes strictement nécessaires et les désactiver dans les applications qui n ' ont pas besoin de renseignements assistés. 2) Non seulement de s'appuyer sur la "recherche web" toggle: ProptArmor a montré que Rovo peut composer et récupérer des URL différemment; traiter cela comme un calque, pas une barrière complète. 3) Connecteurs de repos et d'audition : réduire la gamme de connecteurs (SharePoint, Outlook, autres) et appliquer le principe du privilège mineur dans les identifiants et les clés API. 4) Surveiller les axes de sortie et les enregistrements proxy : activer l'enregistrement de sortie HTTP / HTTPS détaillé, examiner les requêtes sortantes générées par les participants et rechercher les patrons d'ajustement vers des domaines externes inattendus. 5) Mettre en œuvre des contrôles d'évacuation et de DLP pour bloquer ou alerter lorsque le contenu contenant des données sensibles est envoyé hors des domaines autorisés. (6) Faire pivoter les pouvoirs exposés par les preuves et examiner les accès récents si l'exposition est soupçonnée. 7) Consultez l'état d'atténuation avec Atlassian et maintenez des systèmes à jour; demandez si des corrections supplémentaires ont été appliquées au comportement de récupération des URLs constitué de l'agent.

Recommandations techniques supplémentaires pour l'équipement de sécurité : désactiver la rendu automatique des images distantes dans le contenu généré par l'IA lorsque c'est possible (cela réduit un canal d'exfiltration d'URL des images dans Markdown), forcer la validation de domaines externes par une liste blanche, et pratiquer des tests internes d'équipe rebond visant des injections d'invite adjacentes au contenu surélevé. Pour les développeurs et les gestionnaires d'identité, surveiller les attributs de session et bloquer les actions impliquant l'ajustement de ressources externes de sessions avec des champs élevés sans approbation explicite.

En bref : une vulnérabilité basée sur le paramètre URL a été confirmée et corrigée par Atlassian; une seconde technique d'injection dans le contenu que les processus d'assistant, a été diffusée publiquement et sa médiation n'a pas été documentée dans les communications originales. L'exposition réelle est la sortie de données que l'utilisateur peut déjà voir, pas une escalade des privilèges par défaut, mais qui ne réduit pas l'urgence : dans les environnements où les participants à l'IV sont intégrés à plusieurs sources internes, la capacité d'un seul utilisateur de filtrer des informations silencieuses ou non remarquées peut être significative. Les organisations devraient agir sur la configuration, les permissions, l'enregistrement et la décharge afin d'atténuer les risques tout en attendant des précisions et des correctifs finaux de la part du fournisseur.