Atlassian Rovo Vulnerabilities Allow Indirect Prompt Injection and Data Theft

An Atlassian Rovo vulnerability discovery highlights how attackers can trick the enterprise AI assistant into harvesting sensitive Jira and Confluence data and exfiltrating it to external servers. Two independent research efforts demonstrated methods to execute Rovo Chat prompt injection, exposing how generative AI tools integrated across internal workspaces introduce serious data exfiltration risks. While Atlassian resolved a one-click URL prompt injection flaw in July 2026, an indirect prompt injection vector leveraging malicious file uploads remains a key architectural consideration for enterprise security teams.

The Attack Vectors: One-Click Links and Malicious Content

Security researchers uncovered two distinct attack paths that bypass boundaries within Atlassian Rovo, enabling malicious actors to coerce the AI assistant into retrieving and transmitting sensitive data without explicit user authorization.

Varonis Threat Labs identified a vector dubbed “RovoBlast” that abused the rovoChatPrompt URL parameter. By crafting a URL containing preloaded instructions, an attacker could force Rovo Chat to launch commands automatically when an authenticated user clicked the link. Operating with the victim’s underlying authorization, Rovo queried connected systems—including Jira tickets, Confluence pages, and integrated third-party sources such as Microsoft SharePoint and Outlook—and gathered confidential information like private API keys. To exfiltrate the data, the payload directed Rovo to construct an outbound HTTP request to an attacker-controlled server by appending the retrieved text to an external image URL path. Varonis disclosed the vulnerability through Bugcrowd, earning a $6,000 P2 bounty before Atlassian deployed a server-side remediation on July 8, 2026.

Simultaneously, AI security firm PromptArmor demonstrated an indirect prompt injection technique that relied on poisoned content rather than malicious links. In this scenario, an attacker places hidden system instructions inside a document uploaded to an Atlassian workspace. When a user subsequently asks Rovo to summarize, analyze, or organize documents or Jira issues, Rovo processes the file and interprets the concealed text as system commands. The model searches accessible Jira and Confluence repositories, appends the contents to an attacker’s URL, and executes an outbound request. The exfiltration step requires no separate human-in-the-loop approval, and when the user returns to the chat session, Rovo shows standard ticket updates with no visible record of the data transmission.

Root Cause and the Web-Search Boundary

These vulnerabilities illustrate a core structural weakness in Large Language Model (LLM) agent deployments: the inability of the underlying model to distinguish trusted operational instructions from untrusted data inputs retrieved during task execution. When Rovo digests document text or ticket attachments, attacker-controlled strings overwrite system intent.

PromptArmor’s investigation also exposed a critical misconception surrounding administrative privacy controls. Disabling Rovo’s organization-level “web search” setting—intended to restrict the assistant from browsing public websites—did not stop the exfiltration chain. Rovo relies on a separate internal URL-retrieval tool to make outbound requests, and the system failed to verify whether an outbound target URL was user-requested or autonomously constructed by the AI model. Researchers also noted that Rovo renders Markdown images generated in model outputs, which provides an additional vector for data leakage via automatic asset requests.

PromptArmor disclosed its findings to Atlassian on May 23, 2026, and published its technical details on August 5, 2026, after receiving no further updates on remediation for the content-borne path. Neither finding has been assigned a formal CVE identifier.

Blast Radius and Enterprise Impact

The blast radius of these vulnerabilities depends entirely on the access privileges of the user interacting with the poisoned link or document. Because Rovo abides by Atlassian’s standard user permissions model, an attack does not trigger a tenant-wide privilege escalation. However, in enterprise environments where accounts hold broad visibility, the reach of a single user account represents significant risk.

If an executive, project manager, or software engineer triggers the prompt injection, an attacker can extract sensitive code, internal business communication, security keys, or customer data across Jira, Confluence, and linked cloud services. Because Atlassian enables Rovo features by default across Standard, Premium, and Enterprise plans, many organizations run the assistant globally without granular restrictions, leaving users who routinely handle untrusted external attachments vulnerable to content-borne injections.

Mitigation and Access Control Guidance

Because the link-based preloading flaw (rovoChatPrompt) was remediated on Atlassian’s backend, administrators do not need to apply local software patches. However, protecting environments against content-borne indirect prompt injection requires administrative scoping and strict permission controls:

• Restrict Rovo Scope by App and Group: Security teams should access Atlassian Administration to disable Rovo features for specific applications or high-risk user groups who regularly ingest external or untrusted files. Enterprise customers should use refined access experiences to restrict AI capabilities to strictly necessary teams.
• Account for Multi-App Jira Dependencies: Administrators managing multiple Jira applications on a single site must note that blocking Rovo on one Jira product does not disable shared services like Rovo Search or Chat if another Jira app on the same site retains Rovo access.
• Enforce Least Privilege: Audit and tighten user permissions across Jira, Confluence, SharePoint, and Outlook. Restricting what a user account can read directly limits what Rovo can harvest if an injection occurs.
• Do Not Rely Solely on Web-Search Toggles: Disabling the web-search setting does not serve as a complete security boundary against autonomous outbound requests generated by the AI model. Treat file-borne data ingestion as an active trust boundary.