TL;DR - A proof-of-concept attack class called RoVoblast turned up on r/netsec this week and it targets the AI features inside every Atlassian Cloud tenant. The trick is a single click on a Jira ticket or Confluence page that triggers Rovo or Atlassian Intelligence to summarise content, and the content has been poisoned to make the AI do something the user did not ask for. It is a one-click attack, it rides on the AI features Atlassian ships turned on, and it is exactly the kind of thing that slips past a "we are on the cloud, we are fine" posture. What you need to do: confirm which Rovo and Atlassian Intelligence features are enabled in your tenant, turn off the ones your teams are not using, restrict the rest to named security groups, and treat any Jira issue or Confluence page with a recent AI summary as evidence to check.
If you look after an Atlassian Cloud tenant, this is the week to check your AI settings. The same instinct that says "look at what the AI is reading" applies at home too, where a phishing email is just an attacker asking your brain to summarise a poisoned document. Same idea, smaller blast radius.
Get my Personal Security Quick-Start Guide - the practical handbook for the controls that actually change your day. 193 pages, no jargon.
Plus: Join 158+ Australians getting one 5-minute security briefing every Friday.
What RovoBlast actually does
The disclosure that turned up on r/netsec this week, tagged RovoBlast, shows what happens when that trust breaks. The attack is a single click on a Rovo or Atlassian Intelligence action inside Jira, Confluence or Bitbucket Cloud. The click triggers the AI assistant to read the content in front of it, and the content has been structured so the AI reproduces it in its output. The published write-up describes the assistant leaking data it was not asked to surface, because the poisoned content told it to.
That is the same shape as a prompt injection, planted in the body of a page, a ticket, or a comment thread so the AI carries it into whatever it produces. The single click is "Summarise this page", or "Use AI to triage this issue", or "Ask Rovo about this work item". The poisoned content is a Jira issue description, a Confluence page body, or a comment thread. The action the AI takes is whatever the poison tells it to take, ranging from the annoying (the wrong answer) to the dangerous (leaking a token, an internal note, or a record the user never asked for).
The reason this matters is that the AI features ship turned on. Most admins I work with have not opted out.
RoVoblast By The Numbers
| Thing | Figure |
|---|---|
| What the click is | One click on a Rovo or Atlassian Intelligence action inside Jira, Confluence, or Bitbucket Cloud |
| What the user sees | The normal AI summary, the normal AI suggestion, the normal Rovo answer |
| What the attacker sees | Whatever the poisoned instruction told the AI to surface, post, or act on |
| Default state of the AI features | On, for the bulk of Atlassian Cloud tenants I have audited this year |
| Where the poison lives | Inside the content the AI reads - Jira issue body, Confluence page body, comment, attachment, custom field |
| The hard part of the attack | Almost none - the public PoC runs in a research setting |
| The hard part of the defence | Knowing which AI features you have turned on, and for whom |
What the AI features actually do, in plain language
Atlassian ships three categories of AI feature in Cloud, and every category is in scope for a RoVoblast-style attack.
Atlassian Intelligence in Confluence and Jira. The "Summarise this page" button, the "Use AI to write a description" button, the "Suggest acceptance criteria" button in Jira, and the family of small AI assists next to longform fields. They read the content the user is looking at and the related content the feature is allowed to read, then produce text.
Rovo, the chat-style assistant. The "Ask Rovo" box in the Atlassian navigation bar. Rovo reads whatever it is told to read, which by default is the content the asking user has access to, and it returns text or actions. Rovo can act on a user's behalf through Rovo agents, which is where the blast radius gets interesting. A Rovo agent with permission to create Jira issues, post to Confluence, or pull records from a connected data source will follow the instructions in the content it reads.
Bitbucket Cloud AI features. AI assists for code review and pull request descriptions. The same content-injection shape applies, with the input being a pull request description or a code comment, and the output being a review comment that may include text the attacker wanted the reviewer to read.
The shape of every one of those features is the same. The AI reads content the user can see, and produces output the user can act on. If the content is poisoned, the output is poisoned.
The audit you can run this week
The fix is not "turn off all the AI" and it is not "wait for Atlassian to patch it." The fix is to know which AI features your tenant has, who can use them, and which content the AI is reading on their behalf. Five steps, sized for an afternoon.
1. Inventory the AI features that are on. In the Atlassian Cloud admin console, list which AI features are enabled at the org level, which are enabled per product, and which features have a per-product sub-toggle. Most tenants I look at have more AI features turned on than the admin realised, because each product's sub-toggle defaults to on independently.
2. Inventory which Rovo agents are deployed. The agent list shows every Rovo agent that has been installed, including the ones the Atlassian Marketplace shipped by default. For each, the question is the same: what is this agent allowed to do, and which security group can invoke it. The defaults are permissive in a way that surprises most admins.
3. Restrict AI features to the security groups that actually need them. This is the step most teams skip because the per-group toggles are nested three levels deep. Take the org-level "on" switch and turn it off, then turn it back on for the specific security groups whose work genuinely benefits from the AI. The default group is "all licensed users." The realistic group is the people who actually use the AI features.
4. Audit recent AI-generated content for the prompt-injection pattern. In Confluence, surface it from the page history view with the AI edit filter turned on. In Jira, it is the issue history with the AI-suggestion field exposed. The pattern you are looking for is an AI-generated block that contains a sentence that does not match the rest of the page, that asks the reader to do something, or that references an action the user did not initiate.
5. Make the audit recurring. A 90-minute audit, once a quarter, with a one-page runbook of where the toggles are, holds the cadence.
What not to do this week
- Do not turn off every AI feature and call it a strategy. Some of these features are genuinely useful. Keep the features that earn their place, turn off the ones that do not, then scope the rest to the groups that need them.
- Do not assume an Atlassian Cloud patch will land this month. This is not a CVE-shaped bug. The AI features are working as designed. The fix is a content-trust and permission-scoping problem, and the fix lives in your tenant.
- Do not let a junior PM be the only person whose "AI said so" judgement is in the loop. The cheapest mitigation is a five-minute team briefing: if the AI summary contains an action that looks out of place, treat it as untrusted text and check with the page owner before acting on it.
FAQ
Is this a Confluence-only bug?
No. RoVoblast covers Jira, Confluence, Bitbucket Cloud, and any other Atlassian Cloud product with an AI assist or a Rovo integration.
What is the safest single change I can make today?
Turn off the AI features at the org level in the Atlassian Cloud admin console, then re-enable them only for the security groups whose work product the AI is allowed to see. The change takes about two minutes, and it is reversible.
Will Atlassian's built-in content sanitisation stop the attack?
The content sanitisation Atlassian ships reduces some of the low-effort prompt-injection patterns, but the published RoVoblast research describes a technique that hides the injection in the structure of the content rather than in a literal "ignore previous instructions" string. Treat the built-in sanitisation as a backstop, not as the fix.
How do I tell if we have already been hit?
Look at the page history of your highest-traffic Confluence spaces for AI-summarised blocks that contain sentences the page does not contain. Look at the issue history of any Jira project with external contributors for AI-suggested fields whose content does not match the rest of the issue. The absence of a hit is a conclusion you reach from evidence, not from not looking.
My take
The boring answer is the right one. Know which AI features your tenant has, know who can use them, know which content the AI is reading, and run that audit on a recurring cadence. That is the same shape of answer we have been giving for every other SaaS feature that turned into a privileged action surface, and it still works.
The less boring answer is that prompt injection is the new SQL injection. The IT-pro posture that holds across every embedded AI assistant (Atlassian, Microsoft, Google, Slack, Notion) is the same: scope the AI features to the people who need them, restrict what the AI is allowed to read on their behalf, and treat any AI-generated output as untrusted text.
The audit list above is what I hand every Atlassian Cloud admin I talk to, and the response is consistent: more AI features enabled than the admin realised, and most of them scoped to everyone by default. Working through the list and scoping the features to the groups that actually use them is the fix.
Mathew Clark Founder, SecureInSeconds Currently: walking a North Sydney Atlassian admin through a Rovo agent permissions list that should not have been this permissive by default.
Further reading
- RoVoblast: how one click triggered Atlassian's AI (r/netsec) - the proof-of-concept class this post is built around
- Atlassian: Manage Atlassian Intelligence in your organisation - the admin console reference for the AI feature toggles
- Atlassian: Rovo product page - the vendor's own page for what Rovo can do
- Atlassian: Trust and security - the vendor's security posture for the AI feature set
- ACSC: Artificial intelligence guidance - the Australian framework angle on AI feature governance
- SecureInSeconds: Swiss government lost 200 accounts in a SharePoint breach - the same week, the same SaaS-permission-sprawl shape on a different platform
- SecureInSeconds: Metabase SQLi zero-day: the five-minute check for self-hosted BI - the same week, the same self-hosted-tool-that-became-an-attack-surface pattern
- SecureInSeconds: MFA Fatigue and the Playbook for IT Teams - the identity-side cousin of this week's "AI said so" trust pattern
