Atlassian’s Rovo AI assistant can be manipulated into collecting Jira and Confluence data that an authenticated user is allowed to access and sending that information to an attacker-controlled server.
Two security firms found separate ways to trigger the behavior.
PromptArmor placed malicious instructions inside content that Rovo processes. Varonis Threat Labs found another route through a specially crafted Rovo URL. The 2 techniques are different, and their remediation status is different too.
Atlassian has confirmed a server-side fix for the URL-based issue reported by Varonis. The status of PromptArmor’s content-based attack remains less clear.
Malicious instructions hidden inside a file
PromptArmor discovered a prompt-injection chain in which attacker-controlled instructions could be placed inside content that Rovo was asked to process.
The firm published its findings on August 5, 2026, describing an attack where a user uploads a document containing a hidden instruction and then asks Rovo to organize Jira tickets.
Rovo follows the user’s request, searches Jira and Confluence, and processes the information it finds.
The malicious instructions then tell Rovo to append that information to an attacker-controlled URL and open the URL. The attacker can collect the data through their own server logs.
PromptArmor said the attack didn’t require a separate approval from the user before the exfiltration request was made.
There is an important detail here. The attack isn’t accurately described as completely zero-click because the victim still needs to expose Rovo to the malicious content and make a normal request.
The narrower issue is what happens afterward. Once Rovo processes the poisoned content, the outbound request can happen without another human approval step.
PromptArmor also said the chain continued to work when Rovo’s web-search option was disabled.
That finding comes from PromptArmor’s own testing and hasn’t been independently reproduced in the material available here. The firm said the attack used a separate URL-retrieval capability rather than the web-search feature.
Rovo’s URL handling creates another attack path
The second issue came from Varonis Threat Labs.
Varonis found that Rovo’s rovoChatPrompt URL parameter could preload instructions into Rovo Chat. An attacker could construct a malicious URL and send it to a victim who was already authenticated.
A single click could then cause Rovo to process the attacker’s instructions using the victim’s existing permissions.
The proof of concept instructed Rovo to find information the victim could access, place that information into an attacker-controlled image URL, and fetch the image.
The request sent the information to the attacker’s server.
Varonis demonstrated the technique by extracting a private API key from Confluence. Bugcrowd’s disclosure also records testing against Jira and information available through SharePoint and Outlook connectors.
Varonis named the vulnerability RovoBlast and disclosed it through Bugcrowd.
The Bugcrowd record provides the clearest remediation status. Atlassian deployed a server-side fix on July 8, 2026, and the reporter validated that the issue had been fixed.
The report received a P2 priority rating and a $6,000 bounty.
The PromptArmor issue remains less certain
The 2 findings shouldn’t be treated as if they have the same status.
The Varonis URL-based flaw has a documented fix.
PromptArmor’s content-borne attack was disclosed to Atlassian on May 23, 2026. According to PromptArmor, Atlassian provided a case number 2 days later. PromptArmor followed up on June 4 and July 29 and later published its research after what it described as no further communication.
The report published on August 5 still described the content-based attack as working.
The Ash Hacker News found no post-publication update to that report as of August 10, 2026.
That creates an unresolved point in the timeline. Atlassian’s July 8 server-side fix predates PromptArmor’s August 5 publication, but neither disclosure establishes whether that fix also addressed PromptArmor’s content-based attack.
So the status should be kept separate: the Varonis link-based flaw is confirmed fixed, while the later status of the PromptArmor technique isn’t confirmed here.
How the file-based attack works
PromptArmor describes its technique as an indirect prompt-injection attack.
The attacker puts instructions inside content that Rovo is expected to read. When Rovo processes that content, the model can interpret those instructions as commands.
In the published demonstration, the victim uploads a document containing the hidden injection and asks Rovo to organize Jira tickets.
Rovo searches the connected data sources and retrieves the requested information.
The injected instructions then cause Rovo to construct a URL containing the collected information and access that URL. The attacker controls the destination and can read the information from their server logs.
PromptArmor said the victim could later return to the Rovo conversation and see the suggested ticket updates without an obvious indication that the information had also been sent elsewhere.
The firm also pointed to another possible route involving Markdown images generated from model output. It didn’t demonstrate a complete Rovo attack chain through that method, so that possibility should be treated separately from the demonstrated attack.
Disabling web search isn’t necessarily enough
The web-search detail matters because Atlassian provides an organization-level setting that controls whether Rovo can use public websites as an additional source.
PromptArmor said switching that option off didn’t stop its attack.
The reason, according to the research, is that the outbound request relied on a separate URL-retrieval capability.
PromptArmor’s report points to a basic security question: if the assistant can open a URL that it has constructed itself, what prevents an attacker from getting the model to create a URL that carries sensitive information?
Atlassian’s documentation for the web-search setting doesn’t establish whether an assistant-generated request falls under that same control.
The research therefore raises a practical question for organizations using Rovo: disabling public web search shouldn’t automatically be treated as a complete control against data exfiltration through other agent capabilities.
That conclusion is based on PromptArmor’s testing, however. The web-search bypass wasn’t independently reproduced in the material described here.
Rovo still follows the user’s existing permissions
The attacks described don’t demonstrate a tenant-wide authorization bypass.
Rovo’s access to Jira, Confluence, and connected third-party services follows the permissions assigned to the signed-in user.
That means an attacker using these techniques is attempting to extract information that the victim’s account can already reach.
The problem is how that permitted access can be redirected.
A user may have access to sensitive Jira tickets, Confluence pages, or information connected through other services. Rovo can access that information as part of its normal operation. A malicious instruction can then attempt to make the assistant send the information somewhere else.
The scope of an attack therefore depends heavily on the permissions and connected services available to the compromised user’s Rovo session.
Organizations can control Rovo access
Rovo is enabled by default for apps on Atlassian Standard, Premium, and Enterprise plans, and Atlassian says everyone in an organization can use its features.
Administrators can still control access.
Organizations can block Rovo features for supported apps. That disables current and upcoming AI features for the affected app, including Rovo Agents and Chat.
Enterprise customers also have a newer access-management option that can control Rovo by application and user group.
There is a caveat for organizations running multiple Jira-family applications.
Blocking Rovo for one app doesn’t necessarily remove shared Rovo capabilities. Rovo Search, Chat, and Create with Rovo remain available while another Jira app on the same site still has Rovo enabled.
That makes application-level access reviews important for organizations that have several Atlassian apps connected.
What organizations should review
The confirmed RovoBlast vulnerability has already been fixed server-side by Atlassian, so customers don’t have a patch to install for that issue.
The separate PromptArmor finding requires more caution because its post-publication status isn’t established in the supplied reports.
Organizations using Rovo can review which applications and user groups have access to Rovo and reduce access where it’s unnecessary.
Underlying Jira and Confluence permissions should also be reviewed, along with the scope of connected third-party services such as SharePoint and Outlook.
Disabling Rovo’s web-search option alone shouldn’t be treated as a complete defense against the content-based technique described by PromptArmor.
Neither disclosure reports evidence that either attack has been used against a real organization.
That only means the reports don’t contain evidence of real-world exploitation. It doesn’t establish that such activity has never occurred.
For now, the clearest picture is simple: Atlassian has confirmed and fixed the one-click Rovo URL flaw reported by Varonis. PromptArmor’s separate content-based attack was still described as working when its research was published on August 5, and its current status remains unconfirmed.
