RovoBlast: un singur link putea transforma Atlassian Rovo într-un canal de exfiltrare

Cercetătorii Varonis au prezentat la DEF CON 34 RovoBlast, o vulnerabilitate prin care un singur link putea introduce instrucțiuni controlate de atacator direct într-o sesiune autentificată Atlassian Rovo. Asistentul putea apoi folosi accesul legitim al victimei pentru a căuta date în Jira, Confluence și sisteme conectate și pentru a le trimite în afara organizației.

Cum putea un URL să devină o comandă

Rovo Chat accepta parametrul rovoChatPrompt pentru a precompleta conversația. În scenariul legitim, acest lucru face un link convenabil: deschizi Rovo și găsești întrebarea pregătită. În scenariul malițios, textul din URL nu mai era doar conținut afișat, ci ajungea să fie tratat ca o cerere autentică a utilizatorului și executat în sesiunea lui.

Varonis numește clasa Parameter-to-Prompt. Nu a fost nevoie de ocolirea permisiunilor Atlassian: Rovo lucra exact cu drepturile victimei. Nu a fost nevoie nici de un jailbreak clasic. Atacatorul trebuia să convingă un utilizator deja autentificat să deschidă un link pregătit special, un gest care seamănă mult cu phishingul obișnuit.

De ce raza de impact era atât de mare

Rovo este proiectat să unească informația din Atlassian și din numeroase servicii SaaS. Lista oficială de conectori include Jira, Confluence, Bitbucket, SharePoint, OneDrive, Slack, Microsoft Teams, Google Drive, GitHub, ServiceNow și multe altele. Acest context federat este valoarea produsului, dar înseamnă și că o instrucțiune interpretată greșit poate ajunge la mult mai multe date decât un chatbot izolat.

• Instrucțiunea introdusă prin link îi cerea asistentului să găsească informația la care victima avea deja acces.
• ResearchAgent putea parcurge mai multe surse și efectua pași succesivi fără confirmări suplimentare.
• Datele puteau fi incluse într-o cerere către o resursă externă, transformând funcția de navigare într-un canal de ieșire.
• Demonstrațiile publice au acoperit pagini Confluence, tichete Jira și conținut SharePoint cu date personale.

Permisiunile corecte nu opresc o instrucțiune greșită

Controlul de acces răspunde la întrebarea „poate acest utilizator să citească documentul?”. În RovoBlast, răspunsul era da. Problema era că acțiunea de citire fusese declanșată de atacator și că rezultatul putea părăsi frontiera de încredere. Jurnalele puteau arăta ca o sesiune normală a utilizatorului, deoarece identitatea și permisiunile erau reale.

Acest lucru schimbă modelul de amenințare pentru agenți. Autorizarea utilizatorului rămâne necesară, dar nu mai este suficientă. Sistemul trebuie să distingă între intenția utilizatorului și instrucțiuni venite din URL-uri, e-mailuri, documente, pagini web, conectori sau memorie externă.

Ce a reparat Atlassian și ce nu dispare odată cu patch-ul

Raportul Bugcrowd indică prioritate P2 și status rezolvat. Atlassian a aplicat remedierea server-side, iar linkurile construite cu rovoChatPrompt nu mai injectează și nu mai execută automat instrucțiunile atacatorului. Problema fusese raportată în noiembrie 2025, triată în ianuarie 2026 și marcată rezolvată pe 8 iulie 2026.

Patch-ul închide acest traseu concret. Nu elimină clasa de risc: orice agent care citește conținut neîncrezut, vede date private și poate comunica sau acționa în exterior combină trei capabilități care trebuie controlate împreună. Următoarea intrare poate fi un document, un e-mail ori un conector, nu neapărat un parametru URL.

Controale practice pentru administratorii Atlassian și AI

• Confirmă prin canalele Atlassian că instanța beneficiază de remedierea server-side și urmărește comunicările de securitate relevante.
• Inventariază conectorii Rovo și deconectează sursele nefolosite. Fiecare integrare extinde datele pe care agentul le poate căuta.
• Ține în afara razei agentului zonele cu sensibilitate ridicată, precum juridic, HR, financiar, răspuns la incidente și depozite de secrete.
• Aplică least privilege utilizatorilor și conturilor de serviciu. Agentul nu ar trebui să moștenească acces pe care persoana nu îl folosește efectiv.
• Dezactivează navigarea externă sau automatizările în mai mulți pași acolo unde nu sunt necesare pentru un caz de utilizare aprobat.
• Monitorizează rulările agenților, interogările neobișnuite între surse și cererile către domenii externe. Păstrează jurnale suficiente pentru investigație.
• Testează periodic prompt injection cu date sintetice și scenarii aprobate, inclusiv intrări prin URL, document, e-mail și conector.

Ce trebuie să învețe utilizatorii, inclusiv într-un LMS

Trainingul trebuie să trateze linkurile către asistenți AI la fel de atent ca linkurile către pagini de login. Un URL Rovo, Copilot sau alt instrument cunoscut nu este automat sigur doar pentru că domeniul este legitim. Parametrii pot transporta instrucțiuni, iar o sesiune deja autentificată poate amplifica efectul unui singur clic.

Într-un modul LMS, exercițiul util nu este „recunoaște domeniul fals”, ci „oprește-te când un link deschide un agent cu o cerere precompletată sau declanșează o acțiune neașteptată”. Utilizatorul trebuie să închidă sesiunea, să păstreze URL-ul pentru analiză fără a-l redistribui activ și să raporteze evenimentul echipei de securitate.

Dacă cineva a deschis un link suspect

• Nu presupune că lipsa unui mesaj vizibil înseamnă lipsa acțiunii; verifică istoricul și jurnalele Rovo pentru intervalul respectiv.
• Identifică sursele și documentele pe care agentul le-a accesat și orice destinație externă contactată.
• Revocă sesiunea și rotește secretele dacă jurnalele arată că agentul a citit chei, tokenuri sau credențiale.
• Păstrează URL-ul, ora, utilizatorul și dovezile tehnice pentru investigație, dar nu accesa din nou linkul într-un cont real.