Atlassian Fixed One of the Two Ways to Make Rovo Leak Your Jira. The Other One Was Still Open When It Went Public — and Turning Off Web Search Does Not Help.

PromptArmor published research on 5 August showing two ways to make Atlassian's Rovo assistant hand over Jira and Confluence content to an attacker. Atlassian fixed one of them server-side on 8 July. The other was still open when the research went public.

Neither one is an exploit in the sense most security programmes are built around. Nothing escalates privilege. No token is stolen. No memory is corrupted. No malware runs anywhere.

They work by asking the assistant to do its job while it is holding your access.

Vector one: a link, one click, and the assistant thinks you asked

Rovo accepted a URL parameter that preloaded arbitrary text into a user's chat. An authenticated user opens a crafted link and the assistant treats the attacker's text as a question the user typed.

The researchers tested it against Jira, and against data reachable through the SharePoint and Outlook connectors. That last part is the bit worth pausing on: the reach is not bounded by Atlassian. It is bounded by whatever you connected.

Atlassian closed this one server-side on 8 July. There is nothing for you to patch, and credit where it is due — that is a reasonable turnaround for a parameter that needed removing from a live product.

Vector two: the one that was still open

A document carries a hidden instruction. Someone uploads it and asks Rovo something entirely ordinary — organise my tickets.

Rovo searches Jira and Confluence, exactly as asked. It also does what the document said: appends what it found to an attacker-controlled URL and opens it. The attacker reads your ticket contents and page contents out of their own web server logs.

There is no command and control channel. No beacon. No implant. The data arrives as a query string in an access log, which means the entire detection problem is "notice an outbound request that looks like every other outbound request."

At the time of publication this vector was unaddressed.

Why turning off web search does not save you

This is the detail that generalises, and it is the reason we are writing this up rather than reposting a headline.

The intuitive mitigation is to stop the assistant reaching the internet. Administrators can disable web search. It does not prevent this.

The exfiltration is not a web search. It is the assistant following or rendering a link as part of producing an answer. Web search is a feature with a toggle. Following a URL is closer to how the thing fundamentally operates. A control that assumes "no web search means no egress" is guarding a door the data is not walking through.

If you take one thing from this: enumerate every way your assistant can cause an outbound request, not just the ones that have a settings toggle. The feature list and the egress surface are not the same list, and only one of them is written down.

This is the same shape as the Metabase story we published this morning

We published a piece a few hours ago about a Metabase zero-day where an unauthenticated attacker becomes an administrator and reads the stored credentials for every connected database. Different vendor, different technology, no relationship between the two.

Same structure, though, and it is worth naming.

In both cases the product had to be given broad standing access to be useful at all. Metabase cannot draw a chart without live credentials to your warehouse. Rovo cannot answer a question about your tickets without the ability to read your tickets. That access is not a misconfiguration — it is the value proposition.

And in both cases the breach is the access being used, not the access being broken. Metabase's attacker connects to your database as your reporting user. Rovo's attacker reads your Confluence as you. Every downstream control sees an authorised party behaving normally, because that is precisely what is happening.

The uncomfortable version: we have spent two decades building controls that detect unauthorised access, and we are now deploying a category of software whose entire function is to exercise authorised access on someone else's behalf. The controls are not wrong. They are looking at the wrong verb.

What to actually do

Scope the agent to the task, not to the user. Rovo inheriting everything a user can see is convenient and it is the whole blast radius. If it only needs to summarise one project's tickets, give it one project.

Log every outbound URL your assistant constructs, and treat a long query string on an unusual host as an incident, not as telemetry. This is the only place vector two is visible, and it is visible there.

Treat every ingested document as untrusted input, because it is. A file uploaded by an employee is not trusted content merely because the employee is trusted — they were phished, or the file came from a customer, or it is a supplier's invoice with white text at the bottom.

Stop counting "web search disabled" as a mitigation for prompt injection generally. It closes one egress path and leaves the ones built into rendering.

The accounting

PromptArmor found this, reported it to Atlassian on 23 May, and published on 5 August after Atlassian fixed one of the two vectors. That is a 74-day disclosure window with a partial fix at the end of it, handled publicly and with detail. We did none of this research and our contribution here is the analysis and the argument, not the finding.

There are no indicators to publish and nothing for us to add to the feed — no attacker infrastructure has been released and there is no CVE to correlate. Saying so is more useful than inventing a receipt.

One thing we will flag as ours to watch: this is our beat, the question of which agent held and which one did not. We have argued before that "the AI is getting more sophisticated" is unfalsifiable and that demonstrated evolution — two dated observations of the same actor changing method — is the claim you can actually check. The same discipline applies to defence. The checkable question is not whether prompt injection is scary. It is which assistants, on which dates, refused which injection. We intend to keep score.

We guarantee five percent of what we publish is wrong. The likeliest five percent here is the current status of vector two — Atlassian may have shipped a fix between the disclosure and this post, and if so we will say so plainly rather than leave a stale warning standing.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.