Atlassian Rovo AI Assistant: Security Flaws Can Lead to Data Exfiltration Risks
Atlassian Rovo AI Assistant Can Be Manipulated to Leak Jira and Confluence Data to Outside Attackers
Two independent security firms have demonstrated that Atlassian's Rovo AI assistant can be manipulated into collecting internal workspace data and sending it to attacker-controlled servers — with one attack vector confirmed fixed and another still unresolved as of August 8, 2026.
The findings land at a critical moment for enterprise AI adoption. As organizations wire AI assistants deeper into their productivity stacks — connecting tools like Jira, Confluence, SharePoint and Outlook — the reach of a single compromised session grows with it. These disclosures show that the risk is not theoretical: both firms built working proof-of-concept attacks that moved real data outside Atlassian environments without the victim choosing to send it. Understanding the risks and challenges of AI adoption in business has never been more consequential for security teams responsible for enterprise tooling.
Two Firms Found the Same Core Problem by Different Routes
PromptArmor, an AI security firm, published its findings on August 5, 2026, describing what researchers call an indirect prompt-injection attack. In this technique, attacker-controlled instructions are hidden inside content that Rovo is asked to process. The firm's demonstrated chain worked like this: a user uploads a document carrying concealed instructions and asks Rovo to organize their Jira tickets. Rovo searches Jira and Confluence as directed, appends the retrieved data to an attacker's URL and fetches it — delivering the contents directly to the attacker's server logs.
The victim sees nothing unusual. A user returning to the chat later sees only the suggested ticket updates with no visible sign that any data left the environment.
PromptArmor's narrower claim is precise but significant: the exfiltration step does not require a separate human-in-the-loop approval. The firm also reported that disabling Rovo's web-search option — an organization-level setting meant to restrict Rovo's external reach — did not stop the chain because the outbound request used a separate URL-retrieval capability. The root cause, as PromptArmor described it, is that nothing checks whether the URL being opened was one the agent constructed itself.
PromptArmor said it disclosed the issue to Atlassian on May 23, 2026, received a case number two days later, followed up on June 4 and again on July 29, and published after what it described as no further communication. As of August 8, 2026, the report still describes Rovo as vulnerable. No post-publication update had appeared.
The RovoBlast Vector: One Click, Full Exfiltration
Varonis Threat Labs took a different path to the same destination. The firm found that the rovoChatPrompt URL parameter could preload attacker instructions directly into Rovo Chat. One click from an authenticated user was enough for Rovo to execute those instructions using that user's access privileges and transmit results to an attacker-controlled server. Varonis named the flaw RovoBlast and disclosed it through Bugcrowd.
In its proof-of-concept, Varonis demonstrated the exfiltration of a private API key from Confluence. The same technique was tested against Jira and data reachable through SharePoint and Outlook connectors. Bugcrowd rated the report P2 on its priority scale and awarded a $6,000 bounty. Atlassian deployed a server-side fix on July 8, 2026, and the reporter validated the correction. The report is marked resolved.
It is worth noting that neither disclosure carries a CVE identifier. Searches of the National Vulnerability Database and CISA's Known Exploited Vulnerabilities catalog returned no entries for either issue as of August 8, 2026. For organizations tracking formal vulnerability disclosures, the absence of a CVE means this exposure will not surface through standard patch-management feeds — making direct monitoring of vendor communications essential.
What Atlassian's Fix Does and Does Not Cover
The link-based RovoBlast flaw is confirmed closed on Atlassian's side — customers have no patch to apply because the fix was deployed server-side. The content-borne path documented by PromptArmor has no confirmed remediation date. Its status after August 5, 2026, remains unconfirmed in available public reporting.
Understanding the Scope of Exposure
Rovo's data access follows permissions configured in Atlassian products and connected third-party apps. What the demonstrations add is a route for permitted data to leave without the person holding those permissions choosing to send it. In an assistant deliberately wired across Atlassian products and connected apps, the reach of a single account is the product working as intended — which makes the exposure proportional to how broadly Rovo has been connected.
This is a broader pattern in enterprise SaaS security. The risks associated with securing data across SaaS platforms and connected applications are amplified significantly when AI agents are granted wide permissions across multiple integrated tools. A single manipulated session can traverse every system the assistant has been authorized to reach.
Rovo is enabled by default for organizations on Standard, Premium and Enterprise plans, with all users able to access its features. Administrators are not limited to an all-or-nothing choice. Organizations can block Rovo features for specific supported apps, which disables current and upcoming AI features including Agents and Chat for that app. Atlassian's Enterprise tier can also manage Rovo access by app and user group.
A Critical Caveat on Partial Disabling
One documented caveat applies: on a site running multiple Jira-family apps, blocking Rovo for one of them does not remove shared capabilities. Rovo Search, Chat and Create remain available as long as any Jira app on that site still has Rovo enabled. Organizations assuming partial disablement creates a meaningful security boundary should verify that assumption directly against their site configuration.
What Organizations Should Do Now
Neither disclosure reports evidence that either technique has been used against a real organization. That reflects what the two reports contain rather than a finding that no such activity has occurred.
The immediate exposure from RovoBlast is closed. For the content-borne risk, the available controls are administrative rather than patch-based. The nature of sensitive data exposure through connected enterprise tools means that waiting for a vendor patch before taking action is rarely the appropriate response — particularly when administrative controls are available now.
Steps Security and IT Teams Can Take Immediately
- Audit Rovo's access scope now. Review which apps and user groups have Rovo enabled and reduce connector scope to only what is operationally necessary. The demonstrated risk scales with how many systems Rovo can reach on a user's behalf.
- Do not treat the web-search toggle as a complete security boundary. PromptArmor's finding shows that disabling web search did not prevent outbound data requests through a separate URL-retrieval path. Organizations relying on that setting as a primary control should reassess their assumptions.
- Monitor for prompt-injection risks in AI workflows broadly. The technique used against Rovo — hiding instructions inside documents or links that an AI assistant is asked to process — is not unique to Atlassian. Any AI assistant with access to internal data and the ability to make outbound requests presents a comparable attack surface.
The Broader Implication for Enterprise AI Deployments
These findings should prompt a wider review that extends beyond Atlassian. The architecture of modern AI assistants — broad data access, instruction-following behavior, and outbound request capabilities — creates conditions where prompt injection is a structural risk, not an edge case. Security teams evaluating any AI assistant integrated with internal systems should apply the same scrutiny applied here: what data can the assistant reach, what external requests can it make, and is there any validation layer between those two capabilities?
For a current reference on the evolving threat landscape around AI-driven attacks, MITRE's ATLAS framework for adversarial threats to AI systems provides a structured taxonomy that security teams can use to assess their exposure across AI tooling more broadly.