Atlassian Rovo Can Be Tricked into Sending Jira and Confluence Data to Attackers

Attacker-controlled instructions can cause Atlassian's Rovo assistant to collect Jira or Confluence data accessible to a logged-in user and then transmit that data to an external server. Two security firms independently identified this behavior through different attack paths, and only one of those paths has been confirmed as fixed.

AI security firm PromptArmor embedded malicious instructions within content processed by Rovo. The company found that an uploaded file could be sufficient to instruct the assistant to collect internal data and exfiltrate it through a URL request without requiring a separate confirmation step.

In a report published on August 5, 2026, the company stated that the attack chain continued to work even when Rovo's web search option was disabled. This bypass was reported by a single source, and the report only reflects the status of the vulnerability as of that date; no subsequent fix has been confirmed here.

Varonis Threat Labs took a different approach by embedding the instructions in a link. Researchers found that the rovoChatPrompt URL parameter could preload attacker-controlled instructions into Rovo Chat. As a result, a single click by an authenticated user could cause Rovo to execute those instructions with the user's privileges and send the resulting data to an attacker-controlled server.

Varonis named the vulnerability RovoBlast and said it reported the issue through Bugcrowd. Bugcrowd's disclosure indicates that Atlassian fixed the issue server-side on July 8, 2026, and that the researcher who reported it verified the fix.

The File Containing the Instructions

PromptArmor described the attack chain as an indirect prompt injection attack: attacker-controlled text is embedded within content that the assistant is asked to process, and the AI model interprets part of that text as instructions.

In the company's published example, a user uploads a document containing a hidden injection and asks Rovo to organize Jira tickets. Rovo searches Jira and Confluence as requested, appends the information it finds to an attacker-controlled URL, and opens that URL. The attacker can then retrieve the ticket and page contents from their own server logs.

PromptArmor stated that when the user later returned to the conversation, they saw the suggested ticket updates but no indication that data had been exfiltrated.

The interaction cannot strictly be described as a zero-click attack. The victim still needs to expose Rovo to the malicious content and make a normal request. PromptArmor's more specific claim is that the data-exfiltration stage itself does not require separate human approval.

The web search finding is significant because Atlassian provides web search as a separate organization-level setting that allows users to extend Rovo's information sources to public websites. PromptArmor stated that disabling this option did not stop the attack chain because the outbound request used a separate URL-fetching capability.

The company identified the root cause as the lack of a mechanism to determine whether an opened URL had been generated by the AI agent itself. The report also noted that Rovo renders Markdown images from model output, potentially creating another data-exfiltration path, although a complete Rovo attack chain using this method was not demonstrated. The web search bypass is attributed to PromptArmor rather than being treated as independently reproduced.

Atlassian's documentation for the web search setting does not clarify whether requests independently generated and fetched by the assistant fall under the same security control. This raises an important question for organizations evaluating how much security protection disabling the setting actually provides.

PromptArmor stated that it reported 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 received no further communication before publishing its findings.

As of August 8, 2026, The Hacker News had found no post-publication update to the report, which continued to state that Rovo was vulnerable as of the publication date. This was almost a month after the July 8 fix, and neither disclosure clarified whether that change affected the content-based attack path.

The One-Click Link Vulnerability Has Been Fixed

Bugcrowd's disclosure provides a more definitive record of the issue, while Varonis published a more detailed technical explanation of the RovoBlast attack.

The rovoChatPrompt parameter could carry an entire prompt within a Rovo URL. In the Proof of Concept (PoC), Rovo was instructed to locate information accessible to the victim, insert that information into the path of an attacker-controlled image URL, and fetch the image. This request transmitted the data to the attacker's server.

The researcher demonstrated how a private API key could be exfiltrated from Confluence. Bugcrowd also stated that the same one-click technique was tested against Jira and against data accessible through SharePoint and Outlook integrations.

The report was rated P2 on Bugcrowd's priority scale and received a $6,000 bounty. Atlassian deployed a server-side fix on July 8, and the report was subsequently marked as resolved.

Neither disclosure includes a CVE identifier. As of August 8, 2026, searches of the NVD and CISA Known Exploited Vulnerabilities (KEV) Catalog did not return entries for either issue.

Permissions and What Can Be Disabled

Rovo's data access follows the permissions configured across Atlassian products and connected third-party applications. Therefore, the demonstrated risk concerns data that the authenticated victim is already authorized to access; it is not a demonstrated tenant-wide authorization bypass.

These demonstrations introduce a mechanism through which authorized data can be exfiltrated even though the user with those permissions never intentionally chooses to send it. This distinction defines the scope of the risk rather than reducing its severity. In an assistant intentionally integrated across Atlassian products and third-party applications, the access scope of a single compromised account can potentially extend across multiple connected services.

According to Atlassian's documentation, Rovo is enabled by default for applications on Standard, Premium, and Enterprise plans, allowing users within an organization to access its features. Administrators are not limited to simply enabling or disabling everything globally.

Organizations can block Rovo functionality for supported applications, disabling current and future AI capabilities for those applications, including Agents and Chat. The newer Enterprise access-management experience also allows Rovo access to be managed by application and user group.

Atlassian notes one important limitation: if multiple Jira applications are running on the same site, blocking Rovo for only one of them does not necessarily remove shared functionality. Rovo Search, Chat, and Create with Rovo may remain available as long as Rovo is enabled for any Jira application on the site.

The link-based vulnerability has already been fixed by Atlassian, so the immediate remediation requirements are more limited than they may initially appear. For the separate content-driven risk, organizations should review which applications and user groups have access to Rovo, tighten underlying permissions and integration scopes, and avoid treating the web search toggle alone as a complete security boundary.

Neither disclosure provides evidence that these techniques have been used against a real-world organization. This statement reflects the contents of the published reports and should not be interpreted as confirmation that such exploitation has never occurred.

One attack path has been confirmed as fixed. PromptArmor stated in its August 5 disclosure that the other attack path remained unresolved at that time; its status after that date has not been confirmed.

Some of the measures that can be taken to protect against these types of attacks include;

• Restrict Rovo access to only necessary users and groups.

• Apply the Principle of Least Privilege across Jira, Confluence, and connected applications.

• Regularly review third-party application and data access permissions granted to Rovo.

• Implement prompt injection and data exfiltration controls against untrusted content.

• Disable unnecessary Rovo/AI features and integrations.

• Monitor suspicious Rovo, Jira, and Confluence activities through SIEM/SOC solutions.

  
  

For more information or professional assistance, please contact our security experts at. info@zerosecond.ae.