Varonis researchers demonstrated an attack at DEF CON 34 that turns a single click into full enterprise data access through Atlassian Rovo, the company's AI assistant. The technique, named RovoBlast, abuses Rovo's rovoChatPrompt parameter to drop attacker-written instructions straight into a user's Rovo Chat session. Atlassian has since fixed the flaw after it was reported through a Bugcrowd bug bounty program. Details in this article come from analysis published by CSO Online.
Rovo sits inside Atlassian's product family, so if your teams run Jira for ticketing and Confluence for internal documentation, Rovo is the assistant answering questions across that content. It also reaches outward. Varonis found Rovo could enumerate and search Bitbucket, Slack, Google Workspace, Microsoft 365, relational databases, uploaded files, webpages, and archives, with connectors extending to more than 50 platforms.
"A single click on a link triggers the attacker's embedded instructions and forces Rovo to accept externally supplied parameters as trusted inputs within a user's session," said Varonis researcher Dolev Taler.
The operational problem with one-click is that nothing else has to go wrong. There is no credential theft, no malware, no jailbreak of the model, and no multi-turn prompt manipulation. The victim clicks a crafted link, and the injected instructions run with whatever permissions that user's Rovo session already holds.
That matters for how the activity appears in your logs. Because the assistant is performing the requests, the data access looks like ordinary work carried out on the user's behalf. Attackers reach information protected behind credentials without ever compromising an account, which is the kind of access that does not trip the alerts built around failed logins or unusual endpoints.
Taler also noted that Rovo cannot be fully uninstalled, so organizations trying to remove the risk outright may not be able to eliminate the assistant's presence or the attack surface that comes with it. Varonis then tested whether that reach could be converted into an actual path out of the environment, and it could.
How Prompt Injection Turns Rovo Into an Unauthorized Data Gateway
The core defect is a trust boundary failure: Rovo Chat accepted prompt content supplied in a URL parameter and processed it as if the logged-in user had typed it. That means the attacker's text never has to defeat authentication. It arrives inside an already-authenticated session and inherits whatever the user is permitted to see.
Delivery is a single crafted link. No document macro, no malicious attachment, no compromised connector. The victim must be signed in to their Atlassian tenant when they click, which is the normal state for anyone working through Jira or Confluence during the day, so the prerequisite is trivially met in practice.
The instructions embedded in that link then execute with the victim's identity. Varonis was explicit that no jailbreak, double-request trick, or elaborate prompt surgery was needed, meaning the delivery mechanism itself bypassed the guardrails. In ATT&CK terms the entry maps to T1566.002 (Spearphishing Link) paired with T1204.001 (User Execution: Malicious Link), and the follow-on access resembles T1078 (Valid Accounts) because the session is legitimate.
What the injected prompt can reach is defined by the user's own permissions, since it runs with the victim's identity. Internal ticket bodies, comments and attachments, wiki spaces, source repository contents, connected mail and file storage, records in linked relational databases, and uploaded documents all sit within scope, which corresponds to T1213 (Data from Information Repositories) and its Confluence and code-repository sub-techniques. A single click against a senior engineer or a finance lead therefore returns a materially different data set than the same click against a contractor.
The second half of the chain is what turns read access into loss. The ResearchAgent component performs multi-source web research and navigates across external sites over several autonomous steps. Once attacker instructions are seated in the session, that browsing capability provides an outbound path: the agent retrieves internal content, then moves it toward a destination the attacker controls. This is T1567 (Exfiltration Over Web Service), carried out by a sanctioned first-party feature over ordinary HTTPS.
Two properties make this hard to spot after the fact. First, every action is recorded as the assistant working on behalf of the user, so the audit trail shows expected AI activity. Second, the built-in automation means the retrieval and outbound steps do not require the attacker to stay on the keyboard issuing follow-up prompts. The sequence completes on its own.
There is also no clean removal path. Rovo cannot be fully uninstalled from an environment, so the component that parsed the untrusted parameter is present whether or not your teams chose to adopt the assistant. Any organization running affected Atlassian products carried the exposure by default.
On identifiers: the flaw was handled through a bug bounty submission and a vendor fix rather than a public advisory, and no CVE reference or affected build range has been published for it. Treat "fixed in the current cloud release" as the operative status, and note that the same pattern (untrusted input reaching an agent that holds broad read access and outbound network capability) has now appeared across several separately disclosed AI assistant flaws, including SearchLeak, EchoLeak, ShadowLeak, and Antigravity.
Data Exposure Scope and Business Impact for Atlassian Deployments
The data at risk is whatever your Rovo user can already reach, which in most Atlassian deployments is far more than that person opens in a given week. Varonis found Rovo could enumerate and search across relational databases, uploaded files, archives, and webpages in addition to Atlassian's own products. The assistant's job is breadth, and that breadth becomes the exposure.
In practical terms, a single click by one signed-in employee puts the following classes of content in play:
- Credentials and secrets pasted into tickets - API keys, service account passwords, and connection strings that developers drop into Jira comments during troubleshooting and never clean up.
- Source code references and repository structure from Bitbucket, including branch names, commit messages, and file paths that describe how your product is built.
- Internal roadmaps and unreleased plans held in Confluence spaces, along with pricing discussions, vendor negotiations, and board material.
- Customer records attached to support tickets, which frequently include names, contact details, account identifiers, and free-text descriptions of a customer's own systems.
- Content from connected workspaces such as shared drives and mailboxes, reachable through the assistant rather than through the underlying application's own access path.
Varonis specifically flagged legal, HR, finance, and incident response as areas that should stay out of an assistant's scope. If your Confluence tenant holds employment investigations, severance terms, or write-ups from your last security incident, those pages are readable by the same session the attacker is steering.
What makes the exposure hard to bound is that the attacker never touches a credential. Varonis noted that data protected behind credentials was reachable without a compromise, and that the resulting activity looks like legitimate work the assistant performed on the user's behalf. Your access logs will show an authorized employee's identity doing assistant queries, so the reconstruction work after the fact falls on you rather than on obvious anomalies.
The exfiltration path is what converts reading into loss. Rovo's ResearchAgent performs multi-source web research and navigates across websites over multiple autonomous steps, which in testing produced a chain where internal content was retrieved and moved toward an external destination. As Taler put it, Rovo includes built-in automation that accelerates exfiltration once misused. Volume is therefore a function of how long the session runs, not how fast a human operator can copy and paste.
On the compliance side, treat this as an unauthorized access event affecting whatever regulated data your tickets and pages contain. If customer personal data moved to an external destination, GDPR notification timelines apply and you will need to describe the categories of data and the affected data subjects. Healthcare and healthcare-adjacent firms with PHI in support tickets face HIPAA breach assessment on the same facts. For SOC 2, your auditors will ask how logical access to a system with reach across more than 50 connected platforms was governed, and a truthful answer of "through the assistant's inherited permissions" tends to generate a finding.
Operationally, the disruption lands on the teams that live in these tools. Confirming what an assistant session touched means reviewing prompt and agent activity for every user who may have clicked, and secrets found in tickets have to be rotated across every service that consumed them.
Detection and Immediate Response for Rovo Prompt Injection Attacks
Start by confirming your Atlassian tenant is running the fixed Rovo release. The flaw was reported through Bugcrowd and Atlassian has shipped the fix, but no public advisory or CVE reference exists to check against. What you can verify directly is your tenant's Rovo release state, and whether a URL carrying the rovoChatPrompt parameter still pre-populates a Rovo Chat session. Following the NIST Cybersecurity Framework, the remaining work splits into what you scope down, what you look for in logs, and what you tell users while both are underway.
Scoping is the part you control regardless of patch state. Pull a list of every connector currently attached to Rovo and compare it against what your teams actually use, since connectors reach more than 50 platforms and each one widens what a single injected prompt can request. Remove legal, HR, finance, and incident response content from Rovo's scope outright. These are the spaces where a retrieval request costs you the most and where an AI assistant adds the least day-to-day value.
Then turn off the agent capabilities you do not need. Disabling browsing and multi-step automation removes the ResearchAgent path that Varonis used to move internal content toward an external destination, which breaks the chain between data access and data egress even if instruction injection succeeds again through some other parameter.
For log review, look for specific artifacts rather than general anomalies:
- Web proxy and browser history containing Atlassian URLs with the
rovoChatPromptparameter present. Any hit means a user clicked a link that pre-loaded chat content, and the referrer often reveals where the link was delivered. - Atlassian audit events showing one account performing broad search and enumeration across Jira, Confluence, and Bitbucket within a short window, particularly against spaces that user has no working history with.
- Rovo chat transcripts for prompts the user did not type, including instructions to summarize, collect, or forward content, and requests naming credential or secrets-bearing tickets.
- Egress records showing assistant-initiated fetches to domains outside your normal vendor and documentation set, which is what agent-driven exfiltration looks like on the wire.
The detection problem is that all of this is authorized activity performed on the user's behalf, so it will not fail an access check. Adlumin supports ingesting Atlassian audit logs alongside identity events, which is what surfaces a single account suddenly reading across products it never touches. Without that correlation, the queries look like a productive afternoon.
If you find a suspect click, revoke that user's active Atlassian sessions, preserve the chat transcript before it ages out, and treat the event as a data exposure investigation rather than a malware case. There is no payload to remove from an endpoint. The output you need is a list of what the assistant retrieved and whether any of it left your tenant, because that list determines your notification obligations.
Run user communication in parallel. Tell staff to report links that open a pre-filled Rovo chat to your security team without clicking them, and to flag an assistant that volunteers unexpected research or offers to send content outward. Where patching timelines slip and the deployment touches regulated data, temporarily disabling Rovo access for high-privilege accounts is a reasonable interim step. Note that Rovo cannot be fully uninstalled, so scope reduction and connector removal are your durable controls.
Preventing Prompt Injection in Atlassian AI Integrations
The most effective control available to you is scope reduction inside Atlassian's own permission model. Rovo answers within the permissions of whoever is asking, so restricting which Confluence spaces and Jira projects it can index directly limits what any injected instruction can retrieve. Start with the areas Varonis called out as off-limits candidates: legal, HR, finance, and incident response content.
Do this at the space and project level with role-based restrictions instead of relying on individual page permissions. Page-level exceptions drift as teams reorganize, and one inherited-permission mistake puts a sensitive space back in scope for every signed-in user.
Next, turn off agent capabilities your teams do not actually use. The exfiltration path in this research depended on autonomous web browsing and multi-step navigation, so disabling browsing and multi-step automation removes the outbound leg even when injected instructions execute successfully.
For any integration your own developers build against Rovo or adjacent Atlassian APIs, apply validation at the API boundary and treat every externally supplied parameter as untrusted:
- Reject prompt content arriving in URL parameters. Prompt text should originate from authenticated user input in the interface, not from a query string that anyone can craft and send in a link.
- Separate instructions from data. Content pulled from tickets, uploaded files, archives, and fetched webpages should be passed to the model as data to summarize, with system instructions established server-side.
- Log the full prompt payload. If you cannot reconstruct what instructions a session received, you cannot investigate a suspected injection afterward.
- Enforce allow-listed destinations for any agent permitted to fetch external content, so a retrieval step cannot reach an attacker-controlled host.
Test adversarial prompts before you widen Rovo access, not after. Build a non-production tenant with synthetic records that mimic your real sensitive content, then plant injection payloads in the places the assistant reads: Jira comments, Confluence pages, attached files, and linked webpages. Ask the assistant a normal question and see whether the planted instructions change its behavior.
Record the results as a baseline. When Atlassian ships new AI capabilities, rerun the same payloads against the new feature rather than assuming the earlier fix generalizes across the product family.
That release cadence is the governance problem worth naming to your leadership. Vendor-shipped assistants arrive enabled, inherit user permissions by design, and expand their connector reach through routine product updates. Your review process needs a standing step for AI features that appear without a procurement decision, covering what data the feature can read, whether it can act autonomously, and whether it can reach the internet.
Apply least privilege to agents the same way you apply it to service accounts. Each agent should hold its own scoped identity with access to the specific projects it supports, no shared administrative tokens, and a documented owner who reviews that scope on a schedule. When an agent's function ends, revoke the identity instead of leaving it attached to a connector nobody monitors.
Varonis grouped RovoBlast with SearchLeak, EchoLeak, ShadowLeak, and Antigravity as instances of the same pattern, where untrusted input, autonomous behavior, and trusted communication channels combine. Treat this class of finding as recurring, and keep your assistant's data scope small enough that the next disclosure costs you a configuration change rather than an incident response engagement.
Key Takeaway: Confirm Your Rovo Release and Audit Access Logs
The detail worth carrying forward is how little skill this took. Varonis needed no jailbreak, no double-request technique, and no complicated prompt surgery to make RovoBlast work. A crafted link and one click inside an authenticated session was the whole attack chain, which puts it within reach of anyone who can send your staff a URL.
That low barrier is why version confirmation comes first and log review comes second. Atlassian has shipped the fix, so your first item is establishing that your tenant is on the remediated release, and your second is reviewing Rovo query and agent activity across the period before that fix landed. Because the assistant's actions appear as work performed on a user's behalf, unauthorized retrieval in that window will not look like an intrusion in your logs. It looks like an employee asking a question.
Keep one structural fact in view as you plan: Rovo cannot be fully uninstalled. Whatever posture you settle on, the assistant stays part of your Atlassian footprint, so it belongs in your asset and data-flow documentation permanently rather than as a temporary item tied to this disclosure.
RovoBlast sits alongside SearchLeak, EchoLeak, ShadowLeak, and Antigravity, and Varonis identifies the shared pattern as untrusted inputs combined with autonomous behavior and trusted communication channels. As you add more AI assistants across Slack, Microsoft 365, and your development tooling, treat every parameter that feeds a model the way you already treat a query string in a web application: as attacker-controllable until validated. Prompt injection has become a standard class of input-handling defect, and it deserves the same review depth you give your web-facing code.
