If your organisation runs Atlassian Rovo on Standard, Premium, or Enterprise plans, your Jira tickets, Confluence pages, and connected API keys may be accessible to attackers without any action from you or your team.

Two independent security research teams disclosed prompt injection vulnerabilities in Atlassian’s AI assistant this week, and one of them remains unpatched as of today.

What Was Found

RovoBlast (patched July 8, 2026)

Varonis Threat Labs published research on August 7 after presenting at DEF CON 34, documenting an attack they called RovoBlast. The exploit used a URL parameter called rovoChatPrompt, which pre-fills content directly into Rovo’s chat window. When an authenticated user opened a crafted link, Rovo treated the attacker-supplied text as a genuine user query, searched the organisation’s connected content, and could send the retrieved results to an external server.

Varonis disclosed the issue to Atlassian before going public. Atlassian addressed it server-side on July 8, 2026. No customer action or patching is required to be protected from this specific attack path.

Content-Borne Prompt Injection (unpatched)

PromptArmor published a separate disclosure on August 5, describing a different attack route that works without any crafted links. Hidden instructions embedded inside files or documents cause Rovo to collect Jira tickets and Confluence content, append the results to an attacker-controlled URL, and silently open that URL, exfiltrating the data.

Crucially, turning off Rovo’s web search feature does not stop this attack. The prompt injection is triggered through document content, not internet access. PromptArmor confirmed the vulnerability was still working when they published.

There is no patch available. Atlassian has not issued a public CVE or advisory for this issue.

What Data Is at Risk

Rovo has access to everything it needs to do its job as an AI assistant. That includes Jira tickets across your projects, Confluence pages including private spaces, SharePoint documents in connected tenants, Outlook emails and calendar data in connected accounts, and API keys or tokens stored in accessible locations.

An organisation running Rovo with broad workspace permissions, which is the default configuration for a fully deployed AI assistant, is giving an attacker access to anything Rovo can see.

The content-borne injection requires no special access or user error. An attacker who can create a document your team members will open, or who can submit a support ticket, an invoice, or any content that gets loaded into Jira or Confluence, can trigger the exfiltration.

Who Is Affected

Rovo is enabled by default for all Atlassian Standard, Premium, and Enterprise plan customers. If your organisation uses Jira or Confluence and has not explicitly disabled Rovo, you are potentially running the affected product.

Both research teams noted that neither disclosure has been assigned a CVE identifier, which means standard vulnerability tracking tools will not flag this as a known risk.

What This Means for Business

This is a useful illustration of a problem that goes beyond Atlassian. When you give an AI assistant broad access to your business systems, that assistant becomes a new attack surface. The assistant itself does not need to be compromised. Attackers can instruct it, through ordinary-looking content, to act against your interests using its legitimate permissions.

The governance question for any AI deployment is not just “what can this AI do for us” but “what could someone instruct this AI to do with the access we’ve given it.”

A few immediate steps worth taking regardless of what tools your business uses:

• Audit AI assistant permissions. For Rovo specifically, review which spaces, projects, and external integrations Rovo has access to. Least-privilege matters for AI agents as much as it does for human users.
• Disable Rovo temporarily if the content-borne risk is not acceptable for your environment. Until Atlassian patches the PromptArmor disclosure, enterprises with particularly sensitive Jira or Confluence content should weigh whether the productivity benefit justifies the unpatched exposure.
• Treat AI assistant access as a governance item. Any AI tool with access to sensitive business data needs to be tracked in your security policies alongside human identities and service accounts.

The Bigger AI Security Picture

Atlassian Rovo is not unique in having this type of vulnerability. Prompt injection has been documented in AI assistants from Google, Microsoft, and other major vendors over the past year. What makes this disclosure notable is the breadth of data accessible through Atlassian products in a typical enterprise, and the fact that the more dangerous of the two attack paths remains open.

Atlassian’s AI tools are useful. But “useful” and “safe by default” are different things, and right now Rovo is in a state where every enterprise should verify their exposure before assuming the AI is working entirely on their behalf.

---

Enterprise DNA perspective: AI security governance is not a separate workstream from AI adoption — it is part of the same conversation. If your organisation is deploying AI agents and assistants across business systems and you do not yet have a clear picture of what those tools can access and what they can be instructed to do, Omni Advisory can help you map that exposure before it becomes a problem.