Beveiligingsonderzoekers melden dat Atlassian Rovo data lekken kan, als een aanvaller Rovo misleidt met door hem gecontroleerde instructies. Het gaat niet om een klassieke kwetsbaarheid waarbij een aanvaller zomaar toegang krijgt tot een heel tenant, maar om een scenario waarin Rovo informatie verzamelt die een ingelogde gebruiker al mag zien, en die vervolgens naar een buitenserver stuurt.
In totaal zijn er twee routes beschreven door twee verschillende partijen. Eén route heeft volgens de meldingen al een server-side fix gekregen. De andere route wordt in de rapportage nog als actueel gezien, maar de bevestigde status na latere correcties is beperkt.
Wat er misgaat: instructies als “inhoud” voor de assistent
De kern van de bevindingen is dat aanvallers instructies kunnen verstoppen in content die Rovo vervolgens gebruikt. Omdat het model die tekst als leidraad kan behandelen, kan het gedrag van de assistent omslaan van “assisteren” naar “gegevens opvragen en doorsturen”.
Belangrijk hierbij is de scope: de data die Rovo verwerkt, volgt de rechten van de ingelogde gebruiker. Er is dus geen aantoonbare autorisatie-bypass naar data waartoe de gebruiker geen toegang heeft.
Twee routes naar dataversturing
De twee onderzoekers kwamen onafhankelijk van elkaar tot vergelijkbare einduitkomsten: Rovo kan worden aangestuurd om informatie te verzamelen uit Atlassian-diensten en die informatie vervolgens naar een server van een aanvaller te laten gaan.
Route 1: PromptArmor’s content-borne aanpak
PromptArmor beschrijft een indirecte prompt-injection-aanval. In plaats van een kwaadaardige link te gebruiken, verbergt de aanvaller de instructies in een document of andere content die Rovo kan inlezen. In het door PromptArmor gedeelde voorbeeld uploadt een gebruiker een document met daarin een verborgen injectie en vraagt Rovo om bijvoorbeeld Jira-tickets te ordenen.
Vervolgens kan Rovo, wanneer het zoekt binnen Jira en Confluence, de gevonden informatie aanleveren in een verzoek richting een aanvallersgestuurde URL. De aanvaller kan die gegevens daarna teruglezen via eigen logbestanden.
PromptArmor meldt ook dat een gebruiker later in de chat vooral de voorgestelde ticketwijzigingen ziet en niet automatisch merkt dat er data is uitgestuurd. Daarbij merken de rapportauteurs wel op dat het scenario niet volledig “zero-click” is: de gebruiker moet Rovo wel blootstellen aan de geïnjecteerde content en daarna een normale interactie uitvoeren.
Route 2: Varonis’ “one-click” linkparameter (RovoBlast)
Varonis Threat Labs beschrijft een andere techniek, die volgens hen de naam RovoBlast kreeg. Hier draait het om een URL-parameter (rovoChatPrompt) die aanvallersinstructies vooraf in de Rovo-chat kan laden.
In deze route is één klik van een geauthenticeerde gebruiker voldoende: de aanvaller maakt een koppeling met de juiste parameter, waardoor Rovo de instructies direct kan uitvoeren met de rechten van de gebruiker. Het bewijsconcept laat zien dat Rovo vervolgens een verzoek kan doen dat data bij de aanvaller terecht laat komen.
Varonis meldt dat de demonstratie ook is getest op Jira en op data die bereikbaar is via connectoren en koppelingen met andere diensten, waaronder SharePoint en Outlook.
Is er al een fix? Eén route wel, de ander niet eenduidig
Volgens de Bugcrowd-registratie is de link-gedreven route server-side opgelost. De melding stelt dat Atlassian de fix implementeerde op 8 juli 2026 en dat de rapporteur de correctie heeft gevalideerd. In deze disclosure wordt ook aangegeven dat er geen afzonderlijk CVE-nummer is gekoppeld.
Voor de content-borne route is de situatie minder hard. PromptArmor publiceerde op 5 augustus 2026 en gaf aan dat de keten toen nog werkte, ook wanneer de web-search optie binnen Rovo was uitgeschakeld. De bevindingen noemen wel dat de status na latere aanpassingen niet volledig bevestigd is in de betreffende publicatie.
Waarom de “web-search toggle” geen volledige veiligheid is
Rovo biedt de mogelijkheid om web-search als bron toe te staan. PromptArmor stelt echter dat het uitschakelen daarvan de content-borne aanval niet volledig blokkeerde. De reden die ze beschrijven: de uitgaande verzoeken lopen via een andere URL-ophaal-/verwerkingsmogelijkheid dan puur de web-search functionaliteit.
Concreet wordt daarmee een belangrijk punt zichtbaar voor organisaties die tools configureren: een instelling die extern zoeken uitschakelt, is niet automatisch een complete grens waarbinnen “geen datalek” kan ontstaan. Het gaat uiteindelijk om welke uitgaande requests Rovo kan samenstellen en uitvoeren.
Rovo’s permissies: geen autorisatie-bypass, maar wel dataverkeer
Rovo’s toegang tot informatie volgt de permissies die zijn ingesteld in Atlassian-apps en aangesloten derde partijen. De demonstraties tonen dus vooral dat data die de gebruiker mag zien, ook daadwerkelijk kan worden verzameld en naar buiten kan worden gestuurd zonder dat de persoon expliciet “stuur dit” hoeft te kiezen.
Dat onderscheid is belangrijk: het risico wordt dan geen “tenant-wide” overname, maar eerder een misbruik van toegestane datatoegang via een slimme instruktieketen. Voor risicobeoordeling betekent dit dat je moet kijken naar de combinatie van rechten, app-beschikbaarheid en connector-scope.
Wat kun je doen in de praktijk?
Omdat één route al server-side is opgelost, is het niet nodig om te wachten op een patch van klanten voor dat onderdeel. Voor de resterende risico’s en voor het beperken van de impact, kunnen organisaties wel gerichte maatregelen nemen.
1) Beperk wie Rovo kan gebruiken
Volgens Atlassian staat Rovo standaard aan voor apps op Standard-, Premium- en Enterprise-plannen en kunnen gebruikers binnen een organisatie de functies gebruiken. Maar beheerders kunnen Rovo features voor ondersteunde apps blokkeren, waarmee AI-functies voor die app worden uitgeschakeld, inclusief Agents en Chat.
Daarnaast biedt Atlassian een beheerervaring waarmee Rovo per app en per gebruikersgroep kan worden gestuurd. Dat maakt het mogelijk om de inzet te beperken tot teams waar het echt nodig is.
2) Houd rekening met het “shared capabilities”-effect
Atlassian vermeldt een aandachtspunt: draait een site met meerdere Jira-familie-apps, dan kan het blokkeren van één app de gedeelde mogelijkheden niet volledig uitschakelen. In dat geval kunnen Rovo Search, Chat en Create nog beschikbaar blijven zolang er minstens één Jira-app op die site Rovo ingeschakeld heeft.
3) Herzie de onderliggende rechten en connector-scope
Omdat de misbruikroute draait op toegankelijke data, is het verstandig om te controleren welke apps en groepen Rovo mogen gebruiken. Zet daarnaast de onderliggende machtigingen en connectoren zo strak mogelijk, zodat Rovo niet onnodig toegang heeft tot gevoelige informatie.
Wie connectoren gebruikt voor extra datapunten, doet er goed aan om ook te kijken naar de breedte van die integraties. Het gaat immers om “wat de assistent kan bereiken”, niet enkel om “wat hij mag vragen”.
Gerelateerde beveiligingsontwikkelingen
Deze casus past in een breder patroon waarin aanvallers steeds vaker misbruik maken van AI-gedrag en toestemmingen binnen bedrijfssoftware. Als je wilt vergelijken met eerdere incidenten rond misleiding of misbruik van applicatiegedrag, lees dan ook:
- Metabase zero-day: admintoegang zonder authenticatie
- Nieuwe npm-aanval met cross-platform RAT en info-stealer
- Open source volwassen in security: wat verandert
Wat we (nog) niet weten
De twee rapportages bevatten geen bewijs dat de technieken daadwerkelijk zijn misbruikt tegen een echte organisatie. Dat betekent niet dat het onwaarschijnlijk is, maar dat het tot nu toe niet in de gepubliceerde inhoud is aangetoond.
Daarnaast geldt er voor de content-borne route een nuance rond de periode na publicatie. Eén route is bevestigd gesloten, maar voor de andere route blijft de exacte status na latere mitigaties in de openbaar gemaakte informatie beperkt.
Conclusie
De bevindingen rond Atlassian Rovo data lekken laten zien hoe een assistent kan worden misleid om informatie te verzamelen en door te sturen, zolang die informatie binnen de rechten van een ingelogde gebruiker valt. Eén van de besproken routes is volgens de disclosures server-side verholpen, maar de andere route vraagt nog om aandacht, vooral bij organisaties die Rovo breed inzetten of met ruime connector-toegang werken.
Door Rovo per app en groep te beheren, permissies te verscherpen en connector-scope te minimaliseren, verklein je de kans dat assistenten onbedoeld gevoelige gegevens buiten de organisatie brengen.
Bron: https://thehackernews.com/2026/08/atlassian-rovo-can-be-tricked-into.html
