Rovo Prompt Injection: Two Paths to Jira Exfiltration

Authors: Cloud Security Alliance AI Safety Initiative
Published: 2026-08-14

Categories: Agentic AI Security
Download PDF

Key Takeaways

Two independent research teams disclosed separate prompt injection paths into Atlassian’s Rovo AI assistant that allow attackers to exfiltrate Jira and Confluence data the victim is authorized to see, without any conventional account compromise. PromptArmor demonstrated that hidden instructions embedded in an uploaded document can hijack Rovo during a routine task and push search results to an attacker-controlled server, and the company reports this path remained unresolved as of its August 5, 2026 publication despite disclosure to Atlassian in May [1][2]. Varonis Threat Labs separately found that Rovo’s rovoChatPrompt URL parameter would load attacker-supplied text directly into an authenticated user’s chat session, a flaw the researchers named RovoBlast; Atlassian fixed that specific parameter server-side following disclosure through Bugcrowd, ahead of Varonis’s public write-up [3][4][5]. Neither issue has been assigned a CVE identifier as of this writing [1][2][3][4]. Together, the two disclosures illustrate a pattern this report examines further in the CSA Resource Alignment section below: the exfiltration risk lives less in any single input channel than in the combination of broad data access, an agent capable of retrieving external URLs or navigating the web, and insufficient separation between trusted instructions and untrusted content the agent processes.

Background

Rovo is Atlassian’s AI assistant, embedded across Jira, Confluence, and related products in the Atlassian cloud suite, and enabled by default on Standard, Premium, and Enterprise plans [1]. It combines conversational search, chat, and autonomous agent capabilities, and it inherits the requesting user’s existing permissions when it searches Jira tickets, Confluence pages, and connected third-party systems. Varonis and CSO Online both characterize Rovo’s reach as a competitive differentiator: beyond native Atlassian data, Rovo can connect to more than 50 enterprise platforms through its connector ecosystem, including Slack, Microsoft 365, and Google Workspace, and its ResearchAgent capability is designed to perform multi-step, multi-source research that includes navigating external websites [3][5]. That combination of broad, permission-scoped data access and autonomous web interaction reflects an architecture pattern this report treats as high-risk, because it creates a path by which content an agent merely reads can become an instruction the agent obeys.

The two disclosures examined here surfaced within about a week of each other in early August 2026, from researchers working independently and through different channels. PromptArmor, a firm focused on AI application security testing, disclosed its findings to Atlassian on May 23, 2026, received an acknowledgment and case number two days later, followed up twice over the following months, and ultimately published its research on August 5, 2026 after what it described as an absence of further substantive communication from Atlassian [2]. Varonis Threat Labs disclosed its separate finding to Atlassian through Bugcrowd, and Atlassian fixed the specific vulnerable parameter on the server side ahead of Varonis’s public write-up [3][4][5]. The near-simultaneous emergence of two unrelated attack paths against the same product, discovered by different teams using different methods, suggests the underlying weaknesses were reachable through more than one avenue and were not the product of a single overlooked configuration.

Security Analysis

Path 1: Indirect prompt injection through uploaded documents

PromptArmor’s attack relies on indirect prompt injection embedded in an ordinary file rather than in anything the victim types. An attacker crafts a document, such as a PDF, containing instructions hidden from human readers, for example through white text on a white background rendered in a very small font, and delivers it to a target through routine channels such as an email attachment or a shared file. When an employee later uploads that document to Rovo and asks for an unrelated, everyday task, such as help organizing a batch of Jira tickets, Rovo processes the hidden text in the document as if it were a legitimate instruction from the user. The injected prompt directs the assistant to gather Jira and Confluence content the user is authorized to access, append it as a parameter to a URL controlled by the attacker, and then use its own URL-retrieval capability to fetch that URL, at which point the data leaves the organization embedded in the request itself and lands in the attacker’s server logs [1][2].

The detail that most concerns PromptArmor is that this exfiltration channel does not depend on Rovo’s web search feature. The company found that disabling web search in Rovo’s settings failed to stop the attack, because the underlying tool that opens a URL to retrieve search results remains available to the agent independent of whether search itself is toggled on, and that tool applies no meaningful restriction on URLs the agent has dynamically constructed itself [1][2]. This means, in practice, that an administrator who reasonably assumed that turning off web search closed the exfiltration path would have been mistaken: the capability that actually carries the data out survives that control. PromptArmor further characterizes the scope of accessible data broadly, stating the technique can reach any data the agent can retrieve, including content available through Rovo’s connectors to systems beyond Jira and Confluence themselves. As of the researchers’ publication date, they report that Atlassian’s communication lapsed after acknowledging the report and that Rovo remained exploitable through this path [2].

Path 2: RovoBlast — one-click injection via a URL parameter

Varonis Threat Labs found a structurally different weakness. Rovo Chat could be reached through a URL containing a parameter named rovoChatPrompt, which, when present, pre-loaded its contents directly into the chat interface as if the signed-in user had typed it. An attacker could therefore construct a link that embedded an attack prompt in that parameter and distribute it through phishing email, a chat message, or a compromised web page; a single click by a user who was already authenticated to Atlassian was sufficient to trigger the payload, with no separate credential theft or account compromise required [3][4]. Varonis named the flaw RovoBlast and described the resulting chain using an “enter, evade, escape” framing: the parameter provided uncontrolled entry for attacker-supplied text into a trusted session, minimal guardrails stood in the way of the assistant retrieving and summarizing sensitive information once instructed, and Rovo’s ResearchAgent capability supplied a plausible mechanism to move retrieved data to an external destination through its multi-step web navigation function [3].

Varonis demonstrated the practical severity of this chain through three separate proof-of-concept scenarios, exfiltrating Confluence pages, Jira tickets, and SharePoint content containing personal data [3][4]. Because Rovo’s session operated with the clicking user’s own privileges, the technique could reach whatever Jira issues, Confluence pages, or connected systems that user was entitled to see, again without any explicit authorization bypass. Unlike attacks that require an adversary to talk a model out of its guardrails through elaborate jailbreak language, Varonis noted the RovoBlast proof of concept needed little to no such coaxing, since the malicious content arrived as a URL parameter that Rovo treated as legitimate user input rather than as untrusted external data [3]. Atlassian fixed the rovoChatPrompt parameter server-side following disclosure through Bugcrowd, and Varonis published its findings afterward [3][4][5].

A shared underlying weakness

Although the two paths differ in how the malicious content reaches Rovo, first through document content and second through a URL parameter, they converge on the same underlying architectural gap. The two disclosures together indicate that Rovo does not reliably distinguish between instructions that originate from an authenticated user’s genuine intent and text that merely arrives through a channel the agent is willing to read. A hidden instruction in a PDF and a pre-filled chat prompt in a URL are both, from the model’s perspective, just text in the context window, and neither disclosure describes Rovo applying provenance labeling, content isolation, or a control-plane separation that would treat externally sourced text with more suspicion than a user’s own typed request. Both paths also depend on an agent capability, whether a URL-fetch tool or the ResearchAgent’s web navigation function, that can move data to an attacker-chosen destination once the injected instruction is in place; removing or gating that capability, rather than only closing the entry point, would address the exfiltration step common to both.

Recommendations

Immediate Actions

Security teams operating Atlassian Rovo should confirm whether their tenant received Atlassian’s server-side fix for the rovoChatPrompt parameter and should independently test whether links containing that parameter still pre-load chat content, since Varonis’s fix addressed the specific reported vector and organizations should not assume equivalent parameters are equally hardened [3][4]. Because PromptArmor reports the document-based exfiltration path remained open at publication, organizations with sensitive Jira or Confluence content should, pending an Atlassian fix, restrict Rovo’s document-upload and file-processing features for users and workspaces handling regulated or high-value data, and should disable or tightly scope any connectors between Rovo and third-party systems that are not in active, necessary use. Teams should also verify that disabling Rovo’s web search setting does not create a false sense of security; as PromptArmor found, the underlying URL-retrieval tool can persist independent of that toggle, so administrators should look for a control that removes the tool itself rather than only the search feature [1][2].

Short-Term Mitigations

Organizations should treat any content ingested by Rovo, whether an uploaded file, a connector-sourced document, or a URL parameter, as untrusted input rather than as an extension of the user’s own instructions, and should push Atlassian for a documented mechanism that enforces that separation rather than relying on model behavior alone. Egress controls are a practical compensating measure: routing or monitoring outbound requests that Rovo’s agent capabilities generate, and alerting on requests to newly seen or non-corporate domains, would likely have surfaced both the PromptArmor and Varonis proofs of concept before data left the environment. Security teams should also review Rovo’s audit and activity logs for evidence of URL parameters embedded in inbound links, unusual outbound fetch patterns following document uploads, and any use of ResearchAgent’s multi-step browsing feature outside expected workflows, and should extend phishing-awareness training to cover crafted Atlassian links, not only credential-harvesting pages.

Strategic Considerations

More broadly, this disclosure reinforces that agentic AI assistants embedded in productivity suites need architectural safeguards that do not depend on the model correctly distinguishing legitimate instructions from injected ones every time. Enterprises evaluating or already deploying Rovo, and comparable AI assistants layered onto SaaS platforms, should require vendors to disclose which of the assistant’s tools can retrieve or transmit data externally, whether those tools remain reachable when related settings are disabled, and what provenance or content-isolation controls exist between untrusted retrieved content and the instructions the agent executes. Procurement and security architecture reviews should treat the presence of an unrestricted URL-fetch or web-navigation tool attached to a permission-inheriting assistant as a standing exfiltration risk requiring compensating controls, not as a feature to accept on vendor assurance alone.

CSA Resource Alignment

Viewed through a common analytical lens, both Rovo paths can be described as instances of the same three-part exfiltration topology: ingestion of untrusted content into the agent’s context, tool execution against sensitive data the agent’s user is authorized to reach, and an influenceable network egress path that carries the retrieved data outside the organization. Uploaded documents and URL parameters serve as the untrusted-content ingestion point in the two disclosures examined here; Rovo’s search and connector access provide the tool execution against Jira and Confluence data; and the URL-fetch and ResearchAgent capabilities supply the influenceable egress. Defenses against this pattern function best when they are architectural, closing off ingestion, tool access, or egress paths independent of the model’s behavior, rather than behavioral, since relying on the model to recognize and refuse an injected instruction failed in both cases examined here.

CSA’s analysis of Agent Data Injection: A New Attack Class Beyond Prompt Injection is also relevant background, since it documents how metadata and structural inputs an agent implicitly trusts, not just conversational instructions, can carry an attack payload [6]. The RovoBlast URL parameter is a variation on that theme, in that Rovo trusted a structural input, a URL parameter, as equivalent to direct user intent. CSA’s research note Trusted and Compromised: Indirect Prompt Injection in OpenClaw documents the same underlying “trusted input object” problem in a different agentic platform, reinforcing that the failure to separate trusted configuration or instruction channels from untrusted external data is a recurring architectural weakness across agentic AI products rather than a defect unique to Atlassian [7].

These findings also fall within the scope of the AI Controls Matrix (AICM v1.1), whose data protection, access control, and application/interface security control domains address the trust-boundary enforcement, data provenance, and egress governance measures this report recommends, and organizations formalizing an assurance or audit program for Rovo or similar assistants should map their compensating controls to those AICM domains [8]. CSA’s MAESTRO threat modeling framework provides a structured way to locate this class of risk within an agent’s data operations and tool-execution layers when threat-modeling Rovo or comparable assistants going forward [9].

References

[1] The Hacker News. “Atlassian Rovo Can Be Tricked Into Sending Jira and Confluence Data to Attackers.” The Hacker News, August 2026.

[2] PromptArmor. “Atlassian Rovo Exfiltrates Data, Bypassing Controls.” PromptArmor, August 5, 2026.

[3] Varonis Threat Labs. “RovoBlast: How One Click Triggered Atlassian’s AI Assistant to Leak Data.” Varonis, August 2026.

[4] SecurityWeek. “Critical One-Click Vulnerability in Atlassian’s Rovo AI Exposed Enterprise Data.” SecurityWeek, August 2026.

[5] CSO Online. “One-click flaw in Atlassian Rovo exposed enterprise data via prompt injection attack.” CSO Online, August 2026.

[6] Cloud Security Alliance. “Agent Data Injection: A New Attack Class Beyond Prompt Injection.” CSA, July 2026.

[7] Cloud Security Alliance. “Trusted and Compromised: Indirect Prompt Injection in OpenClaw.” CSA, June 2026.

[8] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” CSA, 2025.

[9] Cloud Security Alliance. “MAESTRO: Agentic AI Threat Modeling Framework.” CSA, 2025.

← Back to Research Index