What the researchers discovered

Two security teams independently showed that Atlassian’s Rovo assistant could be coaxed into gathering information a signed-in user can access — then hand that info straight to an attacker. One team hid malicious instructions inside uploaded content so the assistant would dutifully follow them; the other stuffed a full prompt into a URL parameter so a single click from an authenticated user ran the attack.

The two chains behave differently. One is a content-borne prompt injection: an uploaded file contains sneaky directions that Rovo treats as part of the job and then reaches into Jira and Confluence to pull matching items and send them out. The other is a URL trick — researchers nicknamed it RovoBlast — where a rovoChatPrompt parameter preloads attacker commands into a chat link, and one click makes Rovo act with the user’s privileges and exfiltrate data.

Atlassian has already closed the URL-based one-click route with a server-side patch rolled out on July 8, 2026. That fix came after a coordinated disclosure through a bug bounty program, and the reporter validated the remediation. The content-carried route, demonstrated separately and published later, remains less clearly resolved in public reporting.

Why this matters and what you can do

Neither finding means Rovo magically gained superpowers — it accesses whatever the signed-in account is allowed to see. The problem is that permitted data can be made to leave without the user explicitly asking to send it. In short: the assistant does what it’s supposed to, but an attacker can quietly steer it to do the wrong thing.

  • Data exfiltration mechanics: the assistant collects items (tickets, pages, API results) and then appends or embeds them into a request that an attacker controls. That outside server ends up with the content in its logs.
  • One-click vs. content-borne: the former has been patched; the latter was demonstrated using uploaded files and is less clearly marked as fixed in public disclosures.
  • There’s no tenant-wide override to immediately patch everything on your side — fixes were applied by Atlassian for the link vector, while mitigation for content-based injection is largely about scoping who and what can talk to Rovo.

Practical steps for admins and security teams:

  • Audit which apps and user groups have Rovo enabled. Rovo is on by default for many plans, so this isn’t a set-and-forget setting.
  • Limit Rovo access per app or group where possible, and tighten connector permissions for Jira, Confluence, and external services.
  • Don’t rely on a single toggle (like a web-search option) as a full security boundary — agent-initiated fetches might behave differently from a manual web search setting.
  • Watch for vendor updates and verified fixes; this kind of issue is fixed server-side, so applying vendor guidance is the path to resolution.

Other notes worth keeping in your pocket: the reported one-click flaw fetched things like private API keys in proofs of concept and earned a bug bounty. There’s no public CVE tied to these reports in available vulnerability catalogs at the time the findings were published, and neither disclosure showed evidence that real-world attackers abused the techniques — only that the chains were possible in lab demonstrations.

Bottom line: if your org uses Rovo, treat it like any powerful cross-product assistant — it makes work easier, but it can also move permitted data around in surprising ways. Review who can use it, tighten permissions and connectors, and keep an eye on vendor advisories until every vector you care about is confirmed closed.