Is Atlassian Rovo currently vulnerable?

The two routes have different statuses and should be tracked separately. Varonis states the rovoChatPrompt route it disclosed was fixed, presented through Bugcrowd and shown at DEF CON 34. PromptArmor described its content-injection route as unresolved when it published on August 5, 2026, after more than two months without further contact from Atlassian, and its status since then is unconfirmed in the coverage reviewed here. Check Atlassian's own advisories rather than relying on a summary, including this one, for the current state of either route.

Was a CVE assigned to either finding?

Neither write-up names a CVE. That absence matters for triage workflows that key off CVE identifiers, because a vulnerability management pipeline built around CVE feeds will not surface either of these. Disclosures against AI assistant behaviour frequently arrive without CVEs, since the affected component is a hosted product feature rather than a versioned artifact a customer installs. Teams tracking AI product risk need an intake path that does not depend on a CVE existing.

Does disabling web search protect a connected assistant?

PromptArmor's finding is that it did not, in the case tested. The organizational setting was disabled and the exfiltration still ran, because per PromptArmor the setting "fails to remove the tool for opening the search results." The broader lesson holds beyond this one product: a feature toggle in a vendor's admin console describes intent, and the enforcement of that intent lives in code you cannot inspect. Where the outcome matters, verify it at the network boundary rather than trusting the toggle.

How is this different from a normal data exfiltration risk?

The collection is performed by a trusted component using the legitimate entitlements of a real user, so every access looks correct in the underlying systems. Jira sees an authorized user reading tickets. Confluence sees an authorized user reading pages. The anomaly exists only at the AI request layer, in the combination of untrusted instruction content arriving in a prompt and internal content departing toward an external destination in the same session. Systems that audit their own access logs in isolation have no signal to fire on.

What should a security owner do this week?

Inventory which assistants are connected to which systems, and write down the union of what each can reach for a typical user. Establish whether you hold any record of assistant sessions independent of the vendor's console. Then decide whether outbound requests originated by assistants are authorized against the originating user's task or against the assistant's standing capability, because that single distinction determines whether a successful injection reads a page or empties a knowledge base.

Do the two routes need different defenses?

The delivery differs and the exfiltration does not. One route pre-fills a session through a link, the other hides instructions in content the assistant reads, and defending the delivery side means treating both user-supplied links and retrieved content as untrusted provenance. Both routes then converge on the same exit: internal content moving outward in a response or an outbound fetch. Inspecting that exit covers both, which is why response-side enforcement is worth more than trying to enumerate every way an instruction can arrive.

Atlassian Rovo Prompt Injection: One Link, One Assistant, 50-Plus Connected Systems

Varonis Threat Labs researcher Dolev Taler published on August 7, 2026 that Atlassian's Rovo assistant accepts a prompt supplied in a URL query parameter. The link carries rovoChatPathway=chat and rovoChatPrompt=<attacker-supplied prompt> on home.atlassian.com/chat.

A user who is already signed in clicks it, and the chat window opens pre-filled with the attacker's text inside that user's session. No jailbreak, no confirmation step. Varonis named the finding RovoBlast, and the exfiltration in its chain ran through Rovo's own built-in ResearchAgent, a capability advertised for multi-step browsing across arbitrary websites.

Two days earlier, on August 5, 2026, PromptArmor published a different route into the same assistant. The Hacker News pulled the two together on August 10. Two teams finding two independent doors into one assistant inside 48 hours tells you something about how many doors there were to begin with.

Two disclosures, two remediation statuses

The coverage tends to blur these into a single vulnerability. They are separate findings by separate teams, and their statuses differ, so I want to keep them apart before going anywhere near the architecture.

The Varonis route is the rovoChatPrompt parameter. Varonis states it disclosed the issue responsibly to Atlassian and that it was fixed, published through Bugcrowd, and presented at DEF CON 34. The Varonis write-up does not put a date on the server-side remediation, so any specific fix date circulating in secondary coverage is worth checking against Atlassian's own advisory before you rely on it.

PromptArmor's route is indirect prompt injection delivered through content Rovo reads, in this case an uploaded file. Those instructions steer Rovo into constructing and requesting URLs with sensitive data appended as query parameters, so the data lands in the attacker's access logs. Jira tickets and Confluence documents that the acting Rovo agent could reach were the material exfiltrated in the demonstration. PromptArmor reported that the organizational web-search setting was disabled and the attack worked anyway, because "the web search setting fails to remove the tool for opening the search results." Per PromptArmor's own account, that route remained unresolved when it published on August 5.

No CVE is named in either write-up. The coverage reviewed here contains no statement from Atlassian on either finding.

There is a disclosure-process thread worth reporting plainly. PromptArmor says it notified Atlassian on May 23, 2026, received a case number on May 25, followed up on June 4 and again on July 29, and published on August 5 after no further contact. That is a coordination breakdown between a researcher and a vendor, and it is the reason the second route reached the public with its status unresolved.

The blast radius is the union of the connectors

The number that turns this from a product story into an enterprise story is reach.

Varonis describes Rovo Connectors as allowing more than 50 different platforms to be connected. In a typical deployment that list runs through Jira, Confluence and Bitbucket, and out into Slack, Microsoft 365 and Google Workspace. Each connector is added by someone solving a real problem: the assistant is more useful when it can see the ticket, the design doc, the thread and the spreadsheet at once.

The security consequence of that usefulness is arithmetic. A connected assistant's reach equals the union of everything it is wired to, evaluated with the permissions of whoever it is acting for. One injection point anywhere in that union reaches the whole of it. An engineer who can read the security-incident Confluence space, the unreleased-pricing Jira project and the finance folder in Google Drive has an assistant that can read all three, and a single successful injection inside that session inherits the full set.

Nothing here requires the attacker to escalate privilege in the traditional sense. The user's own entitlements do the collecting, which is why access reviews and least-privilege work on the underlying systems remain necessary and remain insufficient on their own.

What sits outside an AI policy gateway

Several of the fixes these disclosures call for belong to Atlassian, and it is worth naming them rather than implying a gateway covers them.

Accepting a prompt from a URL query parameter and pre-filling a session with it is an input-validation decision in Atlassian's application. The connector permission model, including how an assistant's reach is scoped relative to the acting user, is likewise Atlassian's design. Whether disabling organizational web search also removes the tool that opens results turned out to be a product bug, and PromptArmor's finding is that it does not. Constraining ResearchAgent's internal design, including what destinations it may browse, sits with the vendor too.

An enforcement layer sitting between your users and LLM endpoints changes none of those. Saying otherwise would be selling past the architecture.

What the AI request and response path does see

Three things in these chains cross the boundary where inline inspection operates.

The injected instruction arrives as prompt content. Whether it came from a URL parameter or from text inside an uploaded file, it becomes model input, and content that arrives with untrusted provenance can be classified as such before the model acts on it. The general mechanism is covered in indirect prompt injection.

The collected data leaves in a response or an outbound request, and this is what response inspection is for, with one prerequisite stated plainly: an inspection point only sees traffic that is routed through it, and Rovo's own calls run inside Atlassian's infrastructure. For the AI surfaces an organization does route through a boundary it operates, a response carrying internal ticket text, or an outbound fetch whose query string carries content classified as internal toward an external destination, is a visible, enforceable pattern. Watching only the inbound prompt misses the entire exfiltration half of both chains.

The outbound fetch is an authorization decision. When an assistant requests a URL on a user's behalf, evaluating that call against the identity that originated the session rather than against whatever standing capability the assistant holds is what separates "the assistant browsed a page" from "the assistant sent your Confluence content to an unknown host." For Rovo itself that evaluation belongs to Atlassian; for agents whose traffic crosses a boundary you operate, it is enforceable per request. This is the same gap described in the post-authentication gap for AI agents, and the detection side of it is covered in prompt injection monitoring.

The question a security owner actually gets asked

Within a day of a disclosure like this one, the security owner who approved a company-wide assistant gets one question from their CISO, and it has nothing to do with the vendor's patch timeline. The question is whether it happened here.

Answering it requires records the deploying organization holds. Which identities ran assistant sessions in the exposure window. What content classifications appeared in those prompts. Which outbound destinations were requested, and which of those requests carried internal content. A vendor's audit log answers a version of this, filtered through what the vendor chose to record and released on the vendor's schedule. Hold a per-decision record at your own request boundary and the same questions get answered the morning you are asked.

Nothing in a default assistant deployment produces those records, so the first time the question gets asked is usually the moment the gap becomes visible, and it takes a disclosure like RovoBlast to prompt the asking.

DeepInspect

This is the problem DeepInspect was built to solve. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and the model endpoints they call. Prompt content is classified on the way in, responses and outbound calls are evaluated on the way out, and each decision is recorded against the identity that originated the request. Enforcement is per request and fails closed.

The scope is narrow on purpose. DeepInspect does not patch Atlassian's URL parameter handling, does not reconfigure connector permissions, and does not alter how ResearchAgent browses. What it covers is the traffic between your users or agents and the models behind them, which is where injected instructions become input and where collected data becomes an outbound request.

If an assistant is connected across your knowledge base and you have no record of what its sessions sent where, start with the connector inventory. Let's talk today.