TL;DR

Varonis Threat Labs disclosed RovoBlast, a vulnerability in Atlassian Rovo that allowed an attacker to place arbitrary instructions inside the rovoChatPrompt URL parameter. When an authenticated Rovo user clicked the crafted link, the externally supplied content entered Rovo Chat and was treated as if it were a legitimate user instruction. No jailbreak, stolen credentials, or conventional authorization bypass was required.

Once the instruction was accepted, Rovo could search information available to the victim across Atlassian products and connected enterprise systems. The demonstrated exploit then caused Rovo to send retrieved information toward an attacker controlled host, for example, by inserting harvested information into the URL of an image Rovo was instructed to fetch. Varonis also identified Rovo's ResearchAgent as a particularly powerful potential exfiltration mechanism because it could perform multi-step web browsing autonomously.

The important security failure was therefore not excessive model cleverness or a broken ACL. It was a trust-boundary failure:

External data → interpreted as trusted instruction → executed with legitimate user authority → enterprise data retrieved → trusted functionality used to move it outside the boundary.

Atlassian received the report on November 4, 2025, classified it P2, deployed the fix on July 8, 2026, and the researcher subsequently validated the remediation. The vulnerability is resolved.

Core Attack Pattern

Rovo provides an AI layer across Atlassian services such as Jira, Confluence, and Bitbucket and can connect to external enterprise applications. Atlassian's connector catalog includes systems such as Microsoft Teams, Outlook Mail, OneDrive, Google Drive, Gmail, GitHub, Box, Notion, and many others, with search results respecting the permissions available to the user.

Rovo Chat supported URLs containing a rovoChatPrompt parameter:

<https://home.atlassian.com/chat?rovoChatPathway=chat&rovoChatPrompt=><prompt>


The vulnerable implementation allowed content supplied through this external parameter to enter Rovo as a prompt. When a victim with an authenticated session opened the crafted link, Rovo interpreted the embedded text as the user's query rather than treating its external provenance as a security boundary.

Varonis reported that there was no warning, confirmation, or taint indicator ****telling the user that the Rovo session had been seeded by an external parameter. In testing, Rovo could then retrieve and summarize organizational information that the user was authorized to access.

The Bugcrowd disclosure demonstrates the exfiltration primitive more concretely. The malicious prompt could instruct Rovo to obtain information accessible to the victim, store it in a variable, substitute that value into an attacker controlled URL, and then retrieve an apparent image from that address. The resulting request transmitted the harvested value as part of the URL to infrastructure controlled by the attacker. The proof of concept demonstrated exfiltration of a private API key from a Confluence page.

What the Attacker Actually Did

The attack can be reduced to a relatively small chain.

1. Weaponize a legitimate Rovo URL.

The attacker inserted instructions into the legitimate rovoChatPrompt query parameter rather than exploiting memory corruption or obtaining access to the victim's account.

2. Get an authenticated user to click it.

Because the attack was URL based, it could be delivered through phishing, chat, scams, or another social-engineering channel. The victim needed an active Atlassian/Rovo session.

3. Turn external input into trusted instruction.

Rovo accepted the parameter contents as a user query. Varonis describes this pattern as Parameter-to-Prompt (P2P): externally controllable data crosses into an AI execution context and becomes executable instruction.

4. Frame the malicious operation as a legitimate task.

The reported exploit deliberately avoided directly requesting exfiltration. Instead it framed the operation as an innocuous task involving identifying or retrieving an image, causing the model to use the sensitive value while pursuing an apparently legitimate objective.

5. Access information with the victim's existing permissions.

Rovo operated as the legitimate user. It did not have to defeat the application's ACLs because information accessible through the user's Rovo session was already within its reachable trust boundary. Varonis demonstrated access across Confluence and additional connected surfaces such as Jira, SharePoint, and Outlook.

6. Use legitimate functionality for exfiltration.

The proof of concept embedded harvested data into a URL that Rovo then fetched, causing the sensitive value to reach attacker controlled infrastructure. Varonis additionally showed how ResearchAgent's browsing and multi-step capabilities could provide another natural path for moving internally retrieved information toward external destinations.

That makes RovoBlast especially interesting: the attacker did not need to compromise the user's identity, the attacker caused the AI to misuse that identity.

‍

The Attack Progression Across the AI Kill Chain

1. Reconnaissance (Active): The attacker mapped Rovo's capability and action surface, identifying the vulnerable rovoChatPrompt entry point along with the data and tool surfaces Rovo could reach.
2. Trust Manipulation (Active): Through authority impersonation, a crafted rovoChatPrompt caused attacker-controlled instructions to be processed as the authenticated user's own request.
3. Input & Instruction Weaponization (Active): The attacker injected instructions directly into the rovoChatPrompt parameter via indirect prompt injection, so the payload was processed as the user's prompt.
4. Reasoning-Time Execution (Active): Rovo interpreted the externally supplied instructions as the user's intended task and reasoned toward completing them — a reasoning hijack.
5. Tool Invocation (Active): Rovo used its information retrieval and external-fetch/browsing functionality to carry out the attacker-directed actions, an unauthorized feature execution.
6. Privilege Escalation (Active): Through delegated authority abuse, the injected task inherited the legitimate user's access, letting Rovo retrieve information available through that identity. No underlying ACL bypass occurred.
7. Lateral Movement (Bypassed): Access to Jira and connected SaaS systems came through Rovo's existing integrations rather than attacker propagation between compromised systems.
8. Persistence (Bypassed): The disclosed attack required no durable attacker state or persistence mechanism.
9. AI Native C2 (Bypassed): The attacker-controlled endpoint served only as an exfiltration destination; the disclosed attack did not establish a persistent AI command-and-control channel.
10. Action on Objectives (Active): Sensitive information was incorporated into outbound requests reaching attacker-controlled infrastructure, via tool-mediated exfiltration.

The Difference With Traditional Systems

A conventional web application receiving:

?message=help+me+identify+this+image


normally treats the value as data.

An LLM-backed application may interpret exactly the same field semantically as instructions describing what actions the system should take.

That changes the security model.

Traditional input validation predominantly asks: Is this input syntactically safe to process?

Agentic AI additionally needs to ask: Should this input be allowed to influence the system's objective and actions?

RovoBlast crossed several trust boundaries without exploiting conventional authentication:

Attacker URL

↓

External parameter

↓

Rovo prompt

↓

Model reasoning

↓

Victim's authorized data

↓

Rovo capability/tool

↓

Attacker-controlled destination

Rovo's permissions behaved largely as designed: Atlassian states its connectors provide personalized results that respect user permissions. The problem was that the instruction controlling what to do with those permissions originated outside that user's trusted interaction.

This is why ordinary RBAC alone does not solve RovoBlast.

RBAC answers: Can this user access this Confluence page?

The missing control was closer to: Should an instruction originating from an external URL be allowed to cause the AI acting as this user to access that page and transmit derived information elsewhere?

That is an instruction-provenance and authorization-binding problem.

How to Prevent This Class of Attack

The immediate vulnerability has already been addressed. According to the public Bugcrowd disclosure, Atlassian changed the server-side behavior so crafted rovoChatPrompt URLs can no longer inject and automatically execute attacker supplied instructions, and the reporter validated the fix.

For the broader class of attacks, Varonis recommends reducing the assistant's blast radius: limit which systems Rovo can access, disconnect unused integrations, keep especially sensitive areas such as legal, HR, finance, and investor-relations information outside its reach where appropriate, and disable browsing or multi-step automation when those capabilities are unnecessary. It also recommends reviewing assistant logs, alerting on unusual agent activity, and testing how environments respond to seeded prompts.

From the attack chain itself, the strongest architectural controls are:

• Treat externally derived instructions as untrusted. URL parameters, documents, emails, web content, comments, connector output, and other externally controllable context should retain provenance rather than becoming indistinguishable from explicit user commands.
• Prevent automatic execution of externally seeded prompts. Requiring an intentional user action before promoting external content into executable instruction would have interrupted the RovoBlast primitive.
• Bind authorization to both identity and instruction provenance. A user having permission to read a secret should not automatically mean every externally originating instruction executing through that user may retrieve it.
• Constrain external communication. Agents that can access sensitive internal data should have tightly controlled outbound destinations and actions.
• Minimize agent permissions and connectors. Rovo cannot leak information it cannot access; reducing connected sources directly reduces blast radius.
• Apply controls before consequential tool execution. Sensitive retrieval followed by externally influenced network access is particularly high risk and should provide a policy enforcement opportunity.

The objective should therefore not simply be better prompt-injection detection. Detection remains useful, but a system should be designed so that a successful reasoning hijack cannot automatically become a successful data breach.

RovoBlast Didn’t Break In, It Was Let In

Everything Rovo did could occur through the legitimate victim session, using information that the user was entitled to access and capabilities legitimately provided to Rovo. Yet the objective guiding those actions could originate from an attacker-controlled URL. Such actions can consequently resemble normal AI assisted activity because they execute under the user's legitimate identity.

The attack therefore exploited a gap between three concepts that traditional enterprise security frequently treats as tightly coupled: Authentication (who is executing), Authorization (what they can access), and Intent (who actually determined what the system is trying to accomplish). RovoBlast preserved the first two while corrupting the third — the security boundary has to follow the instruction, not merely the account executing it.