White-on-white PDF makes Atlassian's Rovo leak Jira and Confluence data; the org switch does not help

The security firm PromptArmor has documented an indirect prompt injection in Rovo, the AI agent Atlassian wires into Jira and Confluence, in which a PDF carrying white-on-white text at 1 point is enough to send internal tickets and documents to an external server ^[1][2]. No confirmation dialog appears and nothing is left behind in the conversation, which means the first evidence of the theft sits in the attacker's own server logs, not in your audit trail ^[2][6].

The chain, as the researchers reconstructed it, has four steps ^[6]. A user attaches the PDF and asks Rovo to tidy up their tickets. To answer, the agent pulls context from Jira and Confluence: descriptions, assignees, priorities, labels, internal pages. The hidden instruction takes over and tells the agent to build a URL with the collected data stacked into the query parameters. The agent then calls its URL-fetch tool on that address, and the request carries the payload out. PromptArmor describes a second exit of the same kind: Rovo renders images that its answers reference, and rendering an image is already a request to wherever that image lives ^[7].

Nothing here is an access control bypass. Rovo is entitled to read its user's Jira tickets and Confluence pages, because that broad reach across the suite is the product ^[8]. No credentials were stolen; an agent that already held them was borrowed ^[8]. The practical consequence is that the agent's permission scope is the blast radius, and any text it ingests is a candidate instruction. The PDF is one door among several: a support ticket filed by a third party, a web page the agent reads, or data returned by an external connector work the same way ^[10]. That is what makes this worth reading if you do not run Atlassian: the twenty-year-old assumption that data is inert and only code executes does not survive an agent plugged into internal tools ^[11].

The control most administrators would reach for is the org-level toggle that disables the agent's web search. PromptArmor tested it, and according to the firm it is not sufficient: the setting removes the search function while the URL-fetch tool stays active, which is the tool the exfiltration actually uses ^[3][9]. That is the sharpest operational finding in the write-up. A tenant admin can flip the switch, log the change, tell an auditor the agent cannot reach the internet, and still be wrong, because outbound HTTP is reachable through a second path that the toggle does not name.

The disclosure timeline is the other uncomfortable part. The write-up dates the initial report to 23 May 2026, with follow-ups on 4 June and 29 July, and says the flaw was still open on 5 August with no response from the vendor ^[4][5]. That is 74 days from first report to still-unfixed, across three contacts ^[12].

What to watch: whether Atlassian separates the URL-fetch capability from the web search setting, or exposes per-tool switches that an admin can verify rather than infer; whether egress from the agent can be pinned to an allowlist of domains; and whether the same fetch and image-render tools sit under other agents in the suite, since a shared tool means a shared exposure. Until a control can be tested rather than trusted, treat any document an agent reads as attacker-controlled input to a system holding your Jira and Confluence rights ^[8][11].