A támadó által vezérelt utasítások rávehetik az Atlassian Rovo asszisztensét, hogy összegyűjtse a bejelentkezett felhasználó által elérhető Jira- vagy Confluence-adatokat, majd elküldje azokat egy külső szerverre. Két biztonsági cég egymástól függetlenül, eltérő módszerrel találta meg ezt a viselkedést. A két útvonal közül eddig csak az egyikről erősítették meg, hogy lezárták.

A PromptArmor, egy AI-biztonsággal foglalkozó cég, a Rovo által olvasott tartalomba rejtette az utasításokat. Azt állítja, hogy már egy feltöltött fájl is elég volt ahhoz, hogy az asszisztens belső adatokat gyűjtsön, majd egy URL-kérésen keresztül kiküldje azokat, külön jóváhagyási lépés nélkül.

A cég 2026. augusztus 5-én tette közzé az eredményeit, és azt írta, hogy a lánc akkor is működött, ha a Rovo webes keresési opcióját kikapcsolták. Ez a megkerülés egyetlen forrásból származik, és a beszámoló csak az adott dátumra vonatkozóan rögzíti az állapotot; későbbi elhárítást itt nem erősítettek meg.

A Varonis Threat Labs ezzel szemben egy hivatkozásba tette az utasításokat. Azt találta, hogy a rovoChatPrompt URL-paraméter előre betölti a támadó utasításait a Rovo Chat felületére, így egyetlen kattintás egy hitelesített felhasználótól elég volt ahhoz, hogy a Rovo a felhasználó jogosultságaival futtassa ezeket, majd az eredményeket egy támadó által vezérelt szerverre küldje.

A Varonis a hibát RovoBlast néven említi, és azt mondja, a problémát a Bugcrowd rendszeren keresztül jelentette. A Bugcrowd bejegyzése szerint az Atlassian 2026. július 8-án, szerveroldalon javította a hibát, és a bejelentő ellenőrizte a javítást.

Egyik probléma sem igényel ügyféloldali javítócsomagot: a link-alapú hibát az Atlassian saját oldalán zárták le, a tartalomból érkező támadási útvonalnál pedig az a fő védelmi pont, hogy mely appok és csoportok használhatják egyáltalán a Rovo-t.

A fájl, amely parancsokat hordoz

A PromptArmor által leírt lánc egy közvetett prompt-injection támadás: a támadó által vezérelt szöveg olyan tartalomba kerül, amelyet az asszisztensnek felhasználásra adnak, a modell pedig ennek egy részét utasításként értelmezi.

A cég példájában a felhasználó feltölt egy dokumentumot, amely rejtett injectiont tartalmaz, majd megkéri a Rovo-t, hogy rendezze a Jira-jegyeit. A Rovo a kérésnek megfelelően keres a Jira és a Confluence között, az eredményeket hozzáfűzi a támadó URL-jéhez, megnyitja azt, a támadó pedig a saját szervernaplóiból kiolvassa a jegyek és oldalak tartalmát.

A PromptArmor szerint ha a felhasználó később visszatér a beszélgetéshez, csak a javasolt jegyfrissítéseket látja, az adatszivárgásnak nincs látható nyoma.

A helyzetet nem lehet tisztán „zero-click” támadásként leírni. Az áldozatnak továbbra is meg kell nyitnia a Rovo számára a fertőzött tartalmat, és egy szokásos kérést kell indítania. A PromptArmor szűkebb állítása az, hogy magához az adatexfiltrációhoz már nem kell külön, emberi jóváhagyási lépés.

A webes kereséses lánc azért fontos, mert az Atlassian külön, szervezeti szintű beállításként kínálja a web search funkciót, amellyel a felhasználók a Rovo adatforrásait nyilvános weboldalakkal bővíthetik. A PromptArmor szerint ennek a opciónak a kikapcsolása sem állította le a láncot, mert a kimenő kérést egy külön URL-lekérésre szolgáló képesség indította.

A gyökérokot egyenesen fogalmazták meg: senki sem ellenőrzi, hogy a megnyitott URL-t valóban maga az agent állította-e össze. A jelentés azt is megjegyzi, hogy a Rovo Markdown-képek megjelenítésére is képes a modell kimenetében. Így egy másik csatornán is kiszivároghatnak adatok, bár a PromptArmor nem mutatott be teljes támadási láncot ezen az úton. A web search megkerülését továbbra is PromptArmor-felfedezésként kezelik, nem pedig függetlenül reprodukált eredményként.

Az Atlassian vonatkozó beállítási oldala nem tér ki arra, hogy az asszisztens által önállóan összeállított és lekért kérésekre is vonatkozik-e ugyanaz a korlátozás. Erre a kérdésre hívja fel a figyelmet a mostani eset, és ez az, amit minden döntéshozónak mérlegelnie kell, amikor eldönti, mennyit ér számára ez a kapcsoló.

A PromptArmor azt közölte, hogy a problémát 2026. május 23-án jelentette az Atlassiannak, két nappal később kapott esetszámot, majd június 4-én és július 29-én is rákérdezett a fejleményekre, végül pedig azért hozta nyilvánosságra a részleteket, mert elmondása szerint nem kapott további választ.

A Hacker News augusztus 8-ig nem talált a jelentéshez utólag hozzáadott frissítést, és a szöveg még a publikálás idején is sebezhetőként írja le a Rovo-t. Ez majdnem egy hónappal azután történt, hogy július 8-án bevezették a javítást, és egyik disclosure sem tér ki arra, hogy ez a változtatás érintette-e a tartalomalapú támadási útvonalat.

Az egykattintásos linkhiba javítva lett

A Bugcrowd-jelentés a kettő közül a szilárdabb forrás, és a Varonis részletesebb technikai leírást is közzétett a támadásról.

A rovoChatPrompt paraméterrel teljes promptot lehetett átadni egy Rovo URL-ben. A proof of concept arra utasította a Rovo-t, hogy keresse meg az áldozat által elérhető információkat, fűzze be ezeket egy támadó által vezérelt kép URL-jének útvonalába, majd töltse be a képet. A kérés így a támadó szerverére továbbította az adatokat.

A bejelentő demonstrálta, hogy így ki tudott szivárogtatni egy privát API-kulcsot a Confluence-ből, és a Bugcrowd szerint ugyanezt az egykattintásos technikát Jira, valamint SharePoint- és Outlook-csatlakozókon át elérhető adatok ellen is tesztelték.

A jelentés a Bugcrowd prioritási skáláján P2 besorolást kapott, és 6000 dolláros jutalmat ért; az Atlassian július 8-án élesítette a szerveroldali javítást, a jelentést pedig lezártnak jelölték.

Egyik közzétételhez sem tartozik CVE-azonosító, és 2026. augusztus 8-ig sem az NVD-ben, sem a CISA ismert, aktívan kihasznált sebezhetőségeket listázó katalógusában nem találtak bejegyzést egyik problémára sem.

Jogosultságok, és mi kapcsolható ki

A Rovo adat-hozzáférése az Atlassian termékekben és a csatlakoztatott külső alkalmazásokban beállított jogosultságokat követi. A bemutatott kockázat ezért azokra az adatokra vonatkozik, amelyeket a bejelentkezett áldozat elér, nem pedig egy teljes bérlőre kiterjedő jogosultság-ellenőrzés megkerülésére.

A demonstrációk olyan kimenő csatornát adnak a jogosan elérhető adatoknak, amelynél a jogosultsággal rendelkező felhasználó soha nem dönt úgy, hogy elküldi azokat. Ez a különbség inkább a kockázat pontos körülhatárolását segíti, mintsem csökkentené azt: egy olyan asszisztensnél, amelyet szándékosan kötöttek össze az Atlassian termékekkel és a csatlakoztatott külső alkalmazásokkal, egyetlen fiók elérési köre a termék tervezett működésének része.

A Rovo alapértelmezés szerint be van kapcsolva a Standard, Premium és Enterprise csomagokhoz tartozó alkalmazásoknál, és az Atlassian dokumentációja szerint a szervezeten belül mindenki használhatja a funkcióit. A rendszergazdák nincsenek rákényszerítve az „mindent vagy semmit” döntésre.

A szervezetek tilthatják a Rovo funkcióit az érintett alkalmazásoknál, ami letiltja az adott app jelenlegi és jövőbeli AI-funkcióit, beleértve az Agents és a Chat lehetőségeit is. Az Enterprise újabb hozzáféréskezelési felülete alkalmazásonként és felhasználói csoportonként is tudja szabályozni a Rovo használatát.

Az Atlassian egy fontos kivételt is dokumentál: ha egy oldalon több Jira-családba tartozó alkalmazás fut, akkor az egyik blokkolása nem szünteti meg a közös képességeket. A Rovo Search, a Chat és a Create with Rovo addig elérhető marad, amíg az adott oldalon bármelyik Jira appnál engedélyezve van a Rovo.

A linkkel kapcsolatos hibát az Atlassian már kijavította a saját oldalán, ezért a közvetlen teendők köre szűkebb, mint amilyennek elsőre látszik. A tartalomból eredő, különálló kockázat miatt a szervezetek átnézhetik, mely alkalmazások és csoportok férnek hozzá a Rovohoz, szigoríthatják az alapjogosultságokat és a csatlakozók hatókörét, és nem tekinthetik önmagában a webes keresés kapcsolóját teljes értékű biztonsági határnak.

Egyik közzététel sem számol be arról, hogy bármelyik technikát valódi szervezet ellen bevetették volna. Ez kizárólag arra vonatkozik, mi szerepel a két jelentésben, és nem jelenti azt, hogy ilyen tevékenység biztosan nem történt.

Az egyik támadási útvonalat biztosan lezárták. A PromptArmor szerint a másik még megoldatlan volt az augusztus 5-i publikáláskor; az azóta eltelt időszakra vonatkozó állapota továbbra sem ismert.