Rovo Exfiltrates Data Even When Web Search Is Turned Off
The interesting part of the Atlassian Rovo disclosure published this week is not the prompt injection. Prompt injection in an enterprise agent is expected at this point, close to a given.
The interesting part is that turning off web search across the entire organisation does not stop it.
That is a different category of problem. A vulnerability is something an attacker exploits. A security control that reports a protection it does not deliver is something your own architecture diagram lies to you about — and you will not find it by patching, because nothing in your dashboard says it is wrong.
Executive summary
- Zero-click data exfiltration in Atlassian Rovo via indirect prompt injection. No human approval step anywhere in the chain.
- The attack succeeds with web search disabled organisation-wide, by exploiting Rovo’s URL retrieval tool — a separate path from the toggled feature.
- Exfiltration rides Markdown image rendering of model output, a long-established vector.
- Scope is anything the agent can access, explicitly including data reachable via connectors. Researcher server logs contained real Jira tickets and Confluence documents.
- Disclosed to Atlassian 23 May 2026; reported as no significant progress after 75+ days.
- A separate one-click exfiltration via the
rovoChatPromptURL parameter is documented on Bugcrowd.
Why “zero-click” is the load-bearing word
Most agent security discussion assumes a human somewhere in the loop, and most mitigations are built on that assumption: show the user what the agent is about to do, and let them decline.
This attack has no such point. The attacker writes malicious instructions into content the agent will read in the ordinary course of its work — a ticket, a page, a comment. The victim does nothing unusual. They do not click a link, approve a tool call, or open an attachment. They use the product as intended, the agent reads the poisoned content as part of its normal context gathering, and the instructions execute.
There is no user error to train away here, which means user training is not a mitigation.
The control that does not control
Set the injection aside and consider the administrative failure on its own, because it generalises further than this product.
An administrator disables web search across the organisation. That is a deliberate, correctly-motivated decision, taken by someone doing their job properly: the agent should not reach the open internet. The setting applies. The dashboard confirms it. In any reasonable audit, that organisation has closed the outbound path.
It has not. Rovo’s URL retrieval tool is a different code path, and the toggle does not govern it. The agent still fetches remote content, so the exfiltration channel remains open — behind a control that says it is closed.
This is worse than an unprotected system, because an unprotected system is at least accurately represented in your risk register. Here, the security review passed. The compensating control was documented. The finding was closed. And the channel was open the whole time.
The general lesson for anyone deploying an agent product: a feature toggle is a claim about a feature, not a claim about a capability. If “web search off” and “the agent cannot make outbound requests” are the same statement in your threat model, verify that they are the same statement in the vendor’s implementation. Test the control, do not read it.
Markdown images, again
The exfiltration mechanism itself is not novel and that is precisely the complaint.
Rendering Markdown images from model output means any URL the model emits becomes a request the client makes automatically. Put data in the URL’s path or query string, point it at a server you control, and the victim’s own browser delivers the payload. No exploit chain, no memory corruption — the rendering pipeline is the exploit.
This vector has been documented across multiple AI products for a while now. It has a known shape and a known fix: do not auto-fetch remote images from model-generated content, or proxy and strip them. That it remains live in an enterprise product handling Jira and Confluence data in mid-2026 is a statement about how quickly agent features shipped relative to the review of what those features render.
Connectors are the blast radius
The scope line deserves separate attention: the injection can exfiltrate any data the agent can access, including data reachable via connectors.
Connectors are the whole commercial argument for an enterprise agent. An agent confined to Jira is a search box. An agent wired into the ticketing system, the wiki, the CRM, the code host and the document store is a product worth paying for. Every integration increases the value proposition and increases the blast radius by exactly the same amount, because they are the same quantity measured twice.
Which means the exposure here is not bounded by Atlassian. It is bounded by whatever an individual organisation connected to Rovo, and that varies enormously between deployments — and is almost certainly larger than whoever approved the deployment now remembers.
If you run this product, connector inventory is the first thing to pull. Not because the inventory is the fix, but because you cannot scope an incident you cannot enumerate.
Seventy-five days
The disclosure timeline is 23 May, with multiple follow-ups and, per the researchers, no significant progress by early August.
Reasonable people disagree about disclosure windows, and there are legitimate reasons a fix takes time: architectural changes are slower than patches, and this one plausibly requires reworking how tool access relates to administrative policy rather than filtering a string. That is real work.
But the reported gap is not primarily about the fix. Even before a code change lands, an administrator who has disabled web search organisation-wide is entitled to know that the setting does not close the outbound path — because that single sentence would change how they scope connector access today, at no engineering cost. Withholding it while the fix is engineered leaves customers defending a boundary that is not there.
The absence of that notice is the part of this timeline worth criticising.
What to do this week
Concretely, and in order:
Enumerate connectors. Every system Rovo can reach, per instance. This is scoping, not remediation, and everything else depends on it.
Assume reachable means exposed. Not “was exposed” — no evidence of that exists for any specific organisation. Assume it as the planning baseline until you can show otherwise from logs.
Reduce scope. Connector breadth is the one variable entirely under your control. An agent with access to two systems has a smaller worst case than one with access to nine, regardless of what the vendor fixes.
Check egress. Look for outbound requests originating from Rovo content rendering, particularly image fetches to domains you do not recognise.
Retire the toggle as a boundary. Whatever compensating control cited “web search disabled,” that control is void. Update the risk register to reflect what is actually true.
The verdict
This is a well-executed piece of research on a genuine bug, and it will be fixed. That part is ordinary.
What should outlast the specific CVE is the shape of the failure: an agent with broad data access, reading untrusted content, rendering model output into network requests, behind an administrative control that governed a feature while the capability it was meant to constrain lived somewhere else entirely.
Every one of those four properties is present in most enterprise agent products shipping today. Only one vendor has been publicly tested on all four this week.