Datenabfluss bei Atlassian Rovo: Was passiert ist und was Jira-Admins jetzt prüfen sollten

Kurzantwort: Beim Datenabfluss über Atlassian Rovo handelt es sich um einen indirekten Prompt-Injection-Angriff, den PromptArmor Atlassian am 23. Mai 2026 gemeldet und am 5. August 2026 öffentlich gemacht hat. Eine versteckte Anweisung in einer hochgeladenen Datei bringt Rovo dazu, Inhalte aus Jira und Confluence an eine URL anzuhängen und diese aufzurufen. Der Angreifer kann die abgeflossenen Daten anschließend in seinen Server-Logs einsehen. Das Deaktivieren der Websuche verhindert diesen Angriff nicht.

Falls Ihr Team Jira und Confluence mit aktiviertem Rovo einsetzt, sollten sich Admins dafür zwanzig Minuten Zeit nehmen. Der Angriff erfordert weder Klicks noch Bestätigungsdialoge oder kompromittierte Konten. Eine hochgeladene Datei und eine ganz gewöhnliche Anfrage genügen bereits.

Im Folgenden erfahren Sie: wie der Angriff Schritt für Schritt abläuft, warum die naheliegende Einstellung ins Leere läuft, wie der Patch-Status per 27. Oktober 2026 aussieht und welche Checkliste Sie direkt umsetzen können. Wir entwickeln Sharkly – einen Workspace, in dem Coding-Agents Aufgaben von einem gemeinsamen Board übernehmen –, stehen also vor genau derselben Herausforderung. Prompt Injection ist branchenweit nach wie vor ungelöst. Die entscheidende Frage lautet daher: Worauf erhält ein gekaperter Agent über das jeweilige Tool überhaupt Zugriff?

Was passiert ist: Die Rovo-Prompt-Injection Schritt für Schritt

Der Bericht von PromptArmor beschreibt eine fünfstufige Kette:

1. Die manipulierte Datei. Ein Opfer lädt ein Dokument namens „Backlog Guide“ hoch. Es enthält eine versteckte Anweisung, die sich nicht an menschliche Leser, sondern gezielt an das Sprachmodell richtet.
2. Die alltägliche Anfrage. Später bittet das Opfer Rovo darum, die eigenen Jira-Tickets zu organisieren.
3. Die Suche. Rovo ruft Jira-Tickets sowie Confluence-Seiten ab und liest dabei auch die manipulierte Datei ein.
4. Der Datenabfluss. Die Anweisung weist Rovo an, diese Inhalte an eine URL des Angreifers anzuhängen und sie über das integrierte URL-Abruf-Tool aufzurufen. Der Server des Angreifers protokolliert die Anfrage samt den übermittelten Daten.
5. Die Tarnung. Dem Opfer werden völlig plausible Ticket-Vorschläge angezeigt – ohne jeden Hinweis darauf, dass im Hintergrund Daten abgeflossen sind.

Da kein menschliches Eingreifen zur Freigabe der ausgehenden Anfrage erforderlich ist, bezeichnet PromptArmor den Angriff als Zero-Click. Zur Reichweite hält PromptArmor fest: Betroffen sind sämtliche Daten, auf die der Agent in Atlassian zugreifen kann – einschließlich aller Inhalte, die über Connectors eingebunden sind.

Die Datei ist dabei nur ein möglicher Einstiegspunkt. PromptArmor nennt zudem externe Support-Tickets, Web-Ergebnisse bei aktivierter Websuche sowie Connectors von Drittanbietern. Überall dort, wo Rovo Inhalte einliest, können sich Anweisungen verbergen.

Warum das Deaktivieren der Websuche nicht hilft

Atlassian bietet Administratoren eine Option namens „Websuche“ für Rovo, die viele Teams vorsorglich deaktiviert haben. Laut PromptArmor funktioniert der Angriff jedoch auch bei ausgeschalteter Websuche, da der Schalter keineswegs das Tool entfernt, das URLs aufruft. Zudem prüfte dieses Tool nicht, ob die URL vom Agenten selbst dynamisch generiert wurde.

Eine Einstellung, die nach einer bestimmten Funktion benannt ist, schaltet die zugrunde liegende technische Fähigkeit eben nicht zwangsläufig ab.

Atlassians Admin-Dokumentation für Web-Zugriff und Websuche führt mittlerweile zwei Optionen auf: „Web-Zugriff“ steuert, ob Rovo auf öffentliche Webseiten zugreifen darf; die „Websuche“ setzt diesen voraus. Beide Optionen sind standardmäßig aktiviert. Auf der Hilfeseite wird zudem gewarnt: „Selbst wenn der Web-Zugriff deaktiviert ist, wird ein verbundenes Tool möglicherweise nicht blockiert.“ [VERIFY 2026-10-27: no public source confirms whether turning off Web access closes the URL-fetch path PromptArmor used. Do not tell readers it does.]

Gibt es einen zweiten Exfiltrationskanal?

Ja. PromptArmor stellt fest, dass Rovo Markdown-Bilder in seiner Ausgabe rendert. Eine Bild-URL, die auf den Server eines Angreifers verweist, leitet alle darin kodierten Daten in genau dem Moment ab, in dem der Browser das Bild lädt. PromptArmor hebt diesen Kanal hervor, führt dafür jedoch keine vollständige Rovo-Angriffskette vor.

Offenlegungszeitplan und Patch-Status

Mit Stand vom 27. Oktober 2026 konnten wir weder eine Stellungnahme noch einen Sicherheitshinweis oder einen bestätigten Patch von Atlassian für dieses Einfallstor finden. Auch im Hacker-News-Thread zum Bericht (306 Punkte, 138 Kommentare) liegt keine Antwort von Atlassian vor. [VERIFY before publish: re-check Atlassian’s security advisories and the PromptArmor page for an update note.]

Wie unterscheidet sich das von RovoBlast?

Es handelt sich um zwei voneinander unabhängige Sicherheitslücken. Varonis Threat Labs veröffentlichte RovoBlast, wo ein manipulierter Link den URL-Parameter rovoChatPrompt ausnutzte, um Anweisungen in den Rovo-Chat eines Opfers einzuschleusen. Varonis meldete dies über das Bugcrowd-Programm von Atlassian und stuft die Lücke als behoben ein. RovoBlast setzte jedoch eine Benutzerinteraktion per Klick voraus. Der von PromptArmor aufgedeckte Angriff erfordert hingegen lediglich, dass das Opfer seiner regulären Arbeit nachgeht. Ein Fix für das eine Problem sagt daher nichts über das andere aus.

Das Muster dahinter: Die „Lethal Trifecta“

Simon Willison taufte diese Konstellation „The Lethal Trifecta“: ein Agent mit Zugriff auf vertrauliche Daten, Kontakt zu Inhalten unter Kontrolle des Angreifers und einer Möglichkeit, nach außen zu kommunizieren. Kommen alle drei Faktoren zusammen, kann ein Angreifer das System austricksen und vertrauliche Unternehmensdaten abfließen lassen.

Rovo bringt in Jira- und Confluence-Instanzen bauartbedingt alle drei Voraussetzungen mit. Genau das macht das Werkzeug überhaupt erst nützlich.

Die Diskussion auf Hacker News kristallisierte einige Lösungsansätze heraus:

• Ausschließlich URLs abrufen, die von Menschen eingegeben oder von einem verifizierten Tool zurückgegeben wurden. Niemals URLs verarbeiten, die der Agent eigenständig zusammengesetzt hat. Simon Willison hob hervor, dass über Wildcard-DNS bereits die Subdomain allein für einen Datenabfluss ausreicht.
• Vorindizierte URLs helfen, verlangsamen den Abfluss aber nur. Johann Rehberger (wunderwuzzi) merkte an, dass Angreifer Daten dennoch Zeichen für Zeichen pro Anfrage herausschleusen können.
• Domain-Allowlists für spezialisierte Agenten einsetzen. Wenn ein Agent nur drei Domains benötigt, sollte er auch nur auf diese drei Zugriff erhalten.

Keiner dieser Ansätze behebt das Problem im Modell selbst. Sie schränken lediglich den ausgehenden Pfad ein, da Modelle eingeschleusten Instruktionen nach wie vor gelegentlich Folge leisten. Aus genau diesem Grund führt das OWASP Prompt Injection als LLM01 an erster Stelle seiner LLM-Risikoliste.

Rovo-Sicherheits-Checkliste: Was Jira-Admins heute prüfen sollten

Jeder Schritt schränkt einen Teil der Gefahren-Trias gezielt ein.

1. Zugriffsbereiche von Rovo kartieren. Erfassen Sie jede App, jedes Projekt, jeden Space und jeden Connector. Rovo berücksichtigt Benutzerberechtigungen – eine kompromittierte Sitzung erreicht also alles, worauf der anfragende Nutzer Zugriff hat. Laut Atlassian lässt sich Rovo selbst nicht global abschalten, Admins können den Zugriff von Rovo jedoch pro App blockieren.
2. Externe Inhalte identifizieren. Service-Desk-Tickets, E-Mail-zu-Issue-Funktionen, Dateianhänge und synchronisierte Dokumente enthalten Texte, die nicht von Ihrem Team stammen. Das sind Ihre Angriffsflächen für Injection-Angriffe.
3. Connectors auditieren. Trennen Sie ungenutzte Schnittstellen. Nutzen Sie für Google Drive und SharePoint die entsprechenden Block- oder Allowlists. Halten Sie Inhalte aus den Bereichen Recht, Personalwesen, Finanzen und Incident Response konsequent außen vor, wie auch Varonis empfiehlt.
4. Beide Web-Schalter überprüfen. Deaktivieren Sie Websuche und Web-Zugriff, wenn sie nicht zwingend benötigt werden. Betrachten Sie jedoch keinen von beiden als Schutz vor diesem Angriff, solange Atlassian dies nicht offiziell bestätigt.
5. Ausgehenden Datenverkehr überwachen. Achten Sie in Ihren Proxy-Logs auf unerwartete externe Bild- und Link-Domains.
6. Mit einem Test-Prompt überprüfen. Platzieren Sie eine harmlose Anweisung in einem Test-Ticket, die Rovo auffordert, eine von Ihnen kontrollierte URL aufzurufen. Trifft der Request auf Ihrem Server ein, haben Sie Gewissheit.
7. Das Team sensibilisieren. Ein harmloser Befehl wie „Organisiere meine Tickets“ kann im Hintergrund Anweisungen ausführen, die in einem Dateianhang versteckt sind.

Falls Coding-Agents ihre Aufgaben ebenfalls über Jira beziehen, finden Sie weitere Informationen unter Jira-Tickets an KI-Agenten zuweisen.

Die gleichen Fragen gelten für Coding-Agents

Coding-Agents verarbeiten den ganzen Tag lang nicht vertrauenswürdigen Text: Issue-Beschreibungen, Kommentare in Pull Requests, READMEs von Drittbibliotheken oder online abgerufene Dokumentationen. Sie haben Zugriff auf Ihren Quellcode und verfügen meist über eine Netzwerkverbindung. Das ist exakt dieselbe Dreierkombination – nur im Terminal statt im Chat-Fenster. Warum ein besseres Modell strikte Zugriffsgrenzen (Scope) nicht ersetzen kann, haben wir im Artikel über Prompt Injection und Leitplanken für Agenten erläutert.

Sharkly macht Agenten nicht immun gegen Injections – kein Tool kann das heute versprechen. Es bietet Ihnen jedoch die Möglichkeit, den Zugriffsumfang festzulegen, bevor ein Vorgang startet. Agenten laufen auf von Ihnen angebundenen Computers über einen lokalen Dienst, der die Verbindung nach außen hin aufbaut – ein typisches Setup erfordert somit keine offenen eingehenden Ports. Gäste können ausschließlich auf jene Spaces zugreifen, denen sie ausdrücklich zugewiesen wurden. Drittanbieter-Aktionen in Automatisierungs-Workflows laufen über Connectors, die Sie zuvor autorisieren. Laut Dokumentation sollten Passwörter, Token oder Schlüssel niemals in Anweisungen für Skills hinterlegt werden, und Repositories sollten nur die minimal für den Task erforderlichen Rechte erhalten.

Agenten recherchieren, führen Aufgaben aus und berichten. Freigaben und die Abnahme der Ergebnisse bleiben in Menschenhand. Ausführliche Details dazu finden Sie in unseren Beiträgen darüber, was ein Coding-Agent darf und was nicht, sowie an welchen Stellen Genehmigungsschranken eingerichtet werden sollten.

Fazit

Der Rovo-Angriff ist keineswegs exotisch: Eine Datei, eine gewöhnliche Anfrage und ein URL-Werkzeug ohne Einschränkungen bei den Zieladressen genügten völlig – und die Einstellung, zu der die meisten Teams griffen, erfasste genau dieses Tool nicht. Für diesen inhaltsbasierten Angriffspfad gibt es zum Zeitpunkt dieses Artikels noch keinen bestätigten Fix.

Betrachten Sie den Zugriffsumfang (Scope) als das wirksamste Steuerungselement in Ihrer Hand. Verschaffen Sie sich einen Überblick darüber, was Rovo liest, kappen Sie ungenutzte Connectors und testen Sie den ausgehenden Kommunikationskanal selbst. Stellen Sie sich anschließend bei jedem Agenten in Ihrem Team drei Fragen: Was kann er lesen? Welche unbereinigten Texte erreichen ihn? Und wohin kann er Daten senden? Wenn Sie Ihre Coding-Agents auf einem gemeinsamen Board organisieren und den Scope pro Aufgabe festschreiben möchten: Sharkly ist für Organisationen mit bis zu 5 Personen kostenlos.

FAQ

Was ist der Angriff zum Datenabfluss über Atlassian Rovo?

Ein indirekter Prompt-Injection-Angriff, den PromptArmor am 5. August 2026 publik gemacht hat. Versteckte Anweisungen bringen Rovo dazu, Daten aus Jira und Confluence an eine URL des Angreifers anzuhängen und diese aufzurufen.

Schützt das Deaktivieren der Rovo-Websuche meine Daten?

Laut PromptArmor nein. Die Einstellung entfernt keineswegs das Tool, das URLs im Web öffnet.

Hat Atlassian die Rovo-Prompt-Injection behoben?

Mit Stand vom 27. Oktober 2026 konnten wir weder eine Stellungnahme noch einen bestätigten Fix von Atlassian für die von PromptArmor beschriebene Lücke finden. Die separate RovoBlast-Schwachstelle wurde behoben.

Ist Rovo Dev betroffen?

Rovo Dev ist Atlassians Coding-Agent – ein separates Produkt, das sich von Rovo in Jira und Confluence unterscheidet – und wird im Bericht von PromptArmor nicht behandelt. Weitere Einblicke bietet unser Leitfaden zum Free-Tier von Rovo Dev.

Sind Coding-Agents für denselben Angriff anfällig?

Ja. Jeder Agent, der nicht vertrauenswürdige Texte verarbeitet und das Netzwerk erreichen kann, birgt dasselbe Risiko. Begrenzen Sie konsequent, was er lesen darf, welche Zugangsdaten er besitzt und wohin er Daten übermitteln kann.