Atlassian Rovo Data Exfiltration: RovoBlast and the File That Carries Orders

Atlassian Rovo, the AI assistant built into Jira and Confluence, can be tricked into collecting data a signed-in user can access and sending it to an attacker-controlled server. Two security firms found the behavior independently: Varonis reported a URL-parameter flaw it calls RovoBlast, which Atlassian fixed server-side on July 8, 2026, and PromptArmor reported a file-borne indirect prompt injection that, as of its August 5, 2026 write-up, still worked with Rovo's web-search option switched off. There is no CVE and no patch for customers to install; the primary customer-managed control is scoping which apps and groups can use Rovo at all. The two reports describe different entry points to the same outcome, a confused-deputy AI assistant acting on an outsider's instructions with an insider's privileges.

Varonis put the malicious instructions in a link. It found that the rovoChatPrompt URL parameter would preload attacker text into Rovo Chat, so a single click from an authenticated user was enough for Rovo to execute those instructions with that user's access and return the results to an external server. Varonis disclosed through Bugcrowd, and the Bugcrowd record shows Atlassian remediated it server-side on July 8, 2026, with the reporter validating the fix. That specific URL-parameter vector was remediated.

PromptArmor took the other route, hiding instructions inside content Rovo is asked to read. It said an uploaded file was enough to make the assistant gather internal data and send it out through a URL request with no separate approval step, and that the chain still functioned with web search disabled. That finding is single-sourced and its status is established only as of the August 5 publication date; a later remediation is not confirmed here. The distinction matters: one flaw was a fixable bug, the other is closer to how the assistant is designed to behave when it treats attacker-supplied content as trusted input.

Why can't Atlassian just patch the prompt-injection path?

Because the underlying problem is architectural, not a single bug. Practitioners reacting to the disclosures kept returning to the same point: in today's assistants, untrusted data (an attachment, a page) and trusted instructions (the system prompt, the user's request) share one context window, so there is no clean line the model can be told never to cross. Grant an assistant broad read access and every document it ingests becomes a potential instruction, which turns every user into a possible exfiltration path with a single click or file view. Until vendors segregate untrusted content from execution, the durable controls are least-privilege scoping and egress restriction, not a prompt that asks the model to behave.

What should enterprise defenders do about Rovo now?

Scope it down. Audit Rovo's indexing boundaries and restrict its access to non-sensitive Jira projects and Confluence spaces under least privilege, so a hijacked session can reach less. Enforce a strict content-security policy in the tenant to block rendering of untrusted external links and images, a common covert channel for agentic exfiltration, and limit automatic AI indexing of unvetted external attachments. Because the payload can leave through inline markdown or image requests rather than an obvious HTTP call, watch for data egress at the application layer, not just the network.

Our read

This is a supervised-adversary-simulation problem before it is a patching problem. You cannot verify an AI assistant's safety by reading its policy; you verify it by feeding it hostile content the way an attacker would and watching what it does with an authenticated user's access. RovoBlast being fixable while the file-borne path persists is the tell that model behavior alone is not a boundary. The verifiable-by-design answer is to constrain what the assistant can reach and where its output can go, then continuously test those constraints against real injection payloads rather than trusting that a fix to one URL parameter closed the category. Treat every AI assistant with broad read access as a confused deputy whose scope and boundaries have to be verified continuously under adversary simulation, not signed off once.

Reporting by The Hacker News; disclosure details per Varonis Threat Labs (Bugcrowd) and PromptArmor. Sources linked above.

Related: JFrog Artifactory zero-day and the OpenAI Hugging Face chain · AI coding-agent sandbox escapes across Cursor, Codex, and Gemini CLI