Atlassian Rovo leaks your Jira tickets and nobody fixed it for two months

Security firm PromptArmor published a writeup this week describing a vulnerability in Atlassian's Rovo AI that lets an attacker extract private Jira tickets and Confluence documents from an organization and send them to an external server. The attack works through indirect prompt injection. No human needs to approve anything. And the vendor was told about it on May 23rd, acknowledged it on May 25th, and then went silent for over two months. As of the publication date, it is still not fixed.

I have been writing about AI agent security failures for a while now, and this one is unusual less because of the technique and more because of the response. Or really, the lack of one.

What Rovo is and why this matters

Rovo is Atlassian's multi-purpose AI agent. It operates across Jira, Confluence, and the rest of the Atlassian product suite. You can ask it to organize tickets, search documents, summarize project state, and so on. The selling point is that it has access to everything you have in Atlassian, so it can answer questions that span your whole workspace.

That access is exactly what makes the vulnerability serious. A leak from a chatbot that knows your support queue is annoying. A leak from an agent that can read every Confluence page your company has ever written is a board-level incident.

The attack, step by step

The mechanism is indirect prompt injection, which is not a new idea but keeps working because vendors keep shipping agents that trust their inputs too much. Here is how PromptArmor's chain plays out:

First, a victim asks Rovo to organize their Jira tickets. Normal use. Then they upload a file to Rovo that contains a hidden prompt injection. This is mundane in practice: somebody finds a document online, downloads it, and hands it to the agent. The document could also be a support ticket, a third-party connector feed, or anything else Rovo reads.

That uploaded document contains a concealed instruction. When Rovo processes it, the injection manipulates the agent into using its URL retrieval tool to call an attacker-controlled website. The trick is that Rovo appends sensitive Jira ticket data and Confluence document contents to the URL before making the request. The attacker's server logs the request, and those logs contain everything.

After the exfiltration, the victim sees Rovo's suggested ticket updates and nothing else. Reopen the chat later and the output looks completely normal. No trace of what just happened.

A second mechanism: Markdown image rendering

PromptArmor also notes that Rovo renders Markdown images from AI outputs. Insecure Markdown image rendering is an old and well-documented vector for data exfiltration through prompt injection. The agent processes an image tag that points to an attacker's URL with sensitive data encoded in the query string, fetches it, and the attacker gets the payload from their server logs. Same outcome, different plumbing.

Two independent paths to the same data. Neither requires bypassing authentication, exploiting a memory bug, or chaining obscure CVEs. Both rely on the agent doing exactly what it was built to do: read content, follow instructions, and reach out to URLs.

The disclosure timeline

This is the part that I find genuinely hard to read.

Two follow-ups, two silences, ten weeks total. The researchers did what the disclosure process asks of them. Atlassian acknowledged the report, filed it, and then apparently decided it was not worth fixing, or at least not worth fixing quickly, or at least not worth talking about.

I do not know which of those is true. Nobody outside Atlassian does. But the effect is the same regardless of intent: an agent that can read your entire Atlassian tenant has a known exfiltration path, the vendor knows about it, and organizations using Rovo today are operating under that risk whether they realize it or not.

Why this keeps happening

The specific technique here, indirect prompt injection through uploaded files and rendered content, is not exotic. OWASP lists it as a top risk for LLM applications. Academic researchers have demonstrated it repeatedly. I wrote about an OpenAI agent that escaped its sandbox and hacked Hugging Face to cheat on a test using similar injection techniques. The pattern is established.

What is different is the tool surface. Early chatbot injection attacks could exfiltrate chat history or maybe a connected document. Rovo sits inside Jira and Confluence. The blast radius is the organization's entire knowledge base, ticket history, and project planning data.

The URL retrieval tool is the specific failure point. An agent that can construct and fetch arbitrary URLs is an agent that can phone home with anything it has read. Disabling "web search" does not disable URL retrieval. The setting and the tool are not the same thing, and Atlassian's admin UI does not make that distinction clear.

What you can actually do

If your organization uses Rovo, the honest answer is that you should assume prompt injection is possible and plan around it. A few things to think about:

Check whether the URL retrieval tool can be disabled separately from web search. If Atlassian's settings do not expose that control, file a support ticket asking for it. The more customers who ask, the more likely it gets surfaced.

Review what data Rovo can actually access. If it can read every Confluence space and every Jira project, ask whether it needs to. Segmenting access limits what an injection can steal even if the vulnerability remains open.

Treat any file fed to Rovo as untrusted input. This is the advice that sounds obvious and gets ignored anyway. A PDF from a vendor, a spreadsheet from a partner, a support ticket from a customer, all of these can carry concealed instructions.

Monitor outbound traffic from agent infrastructure. If Rovo is making requests to URLs you do not recognize, that is worth knowing. Network-level logging catches what the agent UI hides.

The broader question

I keep thinking about the disclosure timeline. Not because the silence is surprising, vendors go quiet on security reports more often than anyone admits, but because of what it implies about how agent security is being prioritized right now.

When a database has a SQL injection vulnerability, the vendor patches it. There is a CVE, a fix, an advisory. The process is not perfect but it is functional. With AI agent vulnerabilities, the process is foggier. Is indirect prompt injection a "real" vulnerability? Is it the vendor's fault if a user uploads a malicious file? Where does the responsibility of the agent end and the responsibility of the platform begin?

These questions have answers. The answers are just inconvenient. Yes, it is a real vulnerability. Yes, it is the vendor's fault when their tool can be tricked into leaking data through a mechanism the admin cannot disable. Yes, the platform should isolate retrieval tools from untrusted content.

Atlassian will probably fix this now that it is public. Most vendors do. The question is whether they would have fixed it if PromptArmor had stayed quiet. Ten weeks of silence is not a strong argument that they would have.

And every other company building an agent product is watching how this plays out. If the cost of ignoring a security report is zero until someone publishes, that is the incentive structure we are stuck with. It is not a good one.