Exfiltração de dados no Atlassian Rovo: o que aconteceu e o que administradores do Jira devem verificar

Resposta rápida: a exfiltração de dados no Atlassian Rovo é um ataque indireto de injeção de prompt que a PromptArmor divulgou à Atlassian em 23 de maio de 2026 e tornou público em 5 de agosto de 2026. Uma instrução oculta em um arquivo enviado diz ao Rovo para empacotar o conteúdo do Jira e do Confluence em uma URL e abri-la. O invasor lê os dados nos logs do próprio servidor. Desativar a pesquisa na web não impede o ataque.

Se a sua equipe utiliza o Jira e o Confluence com o Rovo ativado, vale a pena dedicar vinte minutos do tempo de um administrador a isso. O ataque não exige cliques, telas de confirmação nem contas comprometidas. Basta um único arquivo enviado e uma solicitação rotineira.

Abaixo: o ataque passo a passo, por que a opção de configuração mais óbvia não o impede, o status da correção até 27 de outubro de 2026 e um checklist que você pode aplicar hoje mesmo. Nós desenvolvemos o Sharkly, um workspace onde agentes de programação recebem tarefas de um quadro compartilhado, portanto enfrentamos o mesmo desafio. A injeção de prompt é um problema não resolvido em todo lugar. A questão é o que cada ferramenta permite que um agente sequestrado alcance.

O que aconteceu: a injeção de prompt no Rovo passo a passo

A análise da PromptArmor descreve uma cadeia em cinco etapas:

1. O arquivo envenenado. A vítima faz o upload de um documento chamado “Backlog Guide”. Ele contém uma instrução oculta direcionada ao modelo, e não ao leitor humano.
2. A solicitação rotineira. Mais tarde, a vítima pede ao Rovo para organizar seus tickets do Jira.
3. A busca. O Rovo busca tickets do Jira e páginas do Confluence, lendo o arquivo envenenado durante o processo.
4. O vazamento. A instrução orienta o Rovo a anexar esse conteúdo à URL de um invasor e abri-la usando sua ferramenta de busca de URLs. O servidor do invasor registra a requisição, incluindo os dados.
5. O disfarce. A vítima vê sugestões perfeitamente normais para os tickets, sem qualquer indício de que algo foi vazado.

Nenhum humano precisa aprovar a requisição externa, razão pela qual a PromptArmor classifica o ataque como zero-click. O resumo do alcance: quaisquer dados que o agente possa acessar no Atlassian, inclusive conteúdos recebidos por meio de conectores.

O arquivo é apenas um ponto de entrada. A PromptArmor também cita tickets de suporte vindos de fora da empresa, resultados da web quando a pesquisa online está ativada e conectores de terceiros. Qualquer coisa lida pelo Rovo se torna um local onde uma instrução maliciosa pode se esconder.

Por que desativar a pesquisa na web não resolve

A Atlassian oferece aos administradores uma opção de configuração de “Pesquisa na web” para o Rovo, e muitas equipes a desativaram por precaução. A PromptArmor relata que o ataque continua funcionando mesmo com ela desativada, pois a chave não desabilita a ferramenta que abre URLs. Essa ferramenta, além disso, não realizava nenhuma validação nas URLs geradas pelo próprio agente.

Uma configuração com o nome de um recurso nem sempre remove a capacidade subjacente desse recurso.

A página de administração de acesso e pesquisa na web da Atlassian agora lista duas opções. O “Acesso à web” controla se o Rovo pode acessar páginas públicas da web; a “Pesquisa na web” depende dele. Ambas vêm ativadas por padrão. A página também alerta que “mesmo que o acesso à web esteja desativado, uma ferramenta conectada pode não ser bloqueada”. [VERIFICAÇÃO 27/10/2026: nenhuma fonte pública confirma se desativar o Acesso à web fecha o canal de busca de URLs usado pela PromptArmor. Não afirme aos leitores que isso resolve.]

Existe um segundo canal de exfiltração?

Sim. A PromptArmor observa que o Rovo renderiza imagens em Markdown na sua resposta. Uma URL de imagem apontando para o servidor de um invasor vaza todos os dados codificados nela no instante em que o navegador a carrega. A PromptArmor alerta sobre esse canal, mas não detalha uma cadeia completa de exploração no Rovo para ele.

Linha do tempo da divulgação e status da correção

Até 27 de outubro de 2026, não encontramos nenhum comunicado, alerta de segurança ou correção confirmada da Atlassian para essa rota de ataque. A discussão no Hacker News sobre a análise (306 pontos, 138 comentários) também não traz resposta da Atlassian. [VERIFICAR antes de publicar: checar novamente os alertas de segurança da Atlassian e a página da PromptArmor em busca de notas de atualização.]

Qual a diferença em relação ao RovoBlast?

Trata-se de falhas distintas. A Varonis Threat Labs divulgou o RovoBlast, no qual um link manipulado explorava o parâmetro de URL rovoChatPrompt para injetar instruções no Rovo Chat da vítima. A Varonis reportou o problema por meio do programa da Atlassian no Bugcrowd e afirmou que ele foi corrigido. O RovoBlast exigia um clique. Já o ataque relatado pela PromptArmor precisa apenas que a vítima realize seu trabalho habitual. A correção de uma falha não se aplica à outra.

O padrão por trás da falha: a tríade letal

Simon Willison batizou esse padrão de a tríade letal: um agente com acesso a dados confidenciais, exposição a conteúdo controlado pelo invasor e um canal para se comunicar externamente. Reunindo os três fatores, um invasor consegue induzi-lo a enviar seus dados para fora.

O Rovo em um ambiente Jira e Confluence possui esses três elementos por design. É exatamente isso que o torna útil.

A discussão no Hacker News convergiu para algumas possíveis soluções:

• Buscar apenas URLs digitadas por uma pessoa ou retornadas por uma ferramenta confiável. Nunca uma URL montada pelo próprio agente. Simon Willison destacou que, com DNS coringa (wildcard DNS), dados podem vazar apenas por meio do subdomínio.
• URLs pré-indexadas ajudam, mas o vazamento ocorre de forma gradual. Johann Rehberger (wunderwuzzi) observou que um invasor ainda consegue vazar dados na proporção de um caractere por requisição.
• Listas de permissão (allowlists) de domínios funcionam bem para agentes de escopo restrito. Se um agente precisa de três domínios, dê a ele acesso a apenas três.

Nenhuma dessas abordagens corrige o modelo em si. Elas restringem a rota de saída, já que os modelos ainda executam textos injetados em determinadas situações. É por esse motivo que a OWASP coloca a injeção de prompt no topo da lista de riscos de LLMs, como LLM01.

Checklist de segurança do Rovo: o que os administradores do Jira devem verificar hoje

Cada etapa reduz um dos pilares da tríade.

1. Mapeie o que o Rovo consegue alcançar. Liste todos os aplicativos, projetos, Spaces e conectores. O Rovo respeita as permissões do usuário, logo, uma sessão comprometida alcança tudo o que o usuário solicitante tem permissão para visualizar. A Atlassian informa que o Rovo em si não pode ser desativado por completo, mas os administradores podem bloquear o acesso do Rovo por aplicativo.
2. Identifique conteúdos vindos de fora. Tickets de service desk, e-mails convertidos em tarefas (email-to-issue), anexos e documentos sincronizados contêm textos que a sua equipe não escreveu. Essas são as suas superfícies de injeção.
3. Audite os conectores. Desconecte os que não estiverem em uso. No caso do Google Drive e do SharePoint, utilize as listas de bloqueio ou de permissão do conector. Mantenha conteúdos jurídicos, de RH, financeiros e de resposta a incidentes fora do alcance, como também orienta a Varonis.
4. Verifique as duas opções de configuração da web. Desative a Pesquisa na web e o Acesso à web se ninguém precisar deles. Não considere nenhuma dessas opções como uma solução definitiva para esse ataque até que a Atlassian confirme isso oficialmente.
5. Monitore o tráfego de saída (egress). Sinalize domínios externos inesperados de links e imagens nos logs do seu proxy.
6. Faça um teste com um prompt induzido. Insira uma instrução inofensiva em um ticket de teste solicitando que o Rovo acesse uma URL sob o seu controle. Se a requisição chegar ao seu servidor, você já terá a resposta.
7. Avise a sua equipe. Um simples comando de “Organize meus tickets” pode executar instruções ocultas em um anexo.

Se o Jira também é o local onde agentes de programação recebem tarefas, confira como atribuir tickets do Jira a um agente de IA.

As mesmas perguntas se aplicam aos agentes de programação

Agentes de programação leem textos não confiáveis o dia todo: descrições de issues, comentários em pull requests, READMEs de dependências, documentações buscadas na web. Eles têm acesso ao seu código-fonte e, normalmente, à rede. Essa é a tríade letal em um terminal em vez de um painel de chat. Já abordamos por que um modelo melhor não substitui a definição de escopo em injeção de prompt e barreiras de proteção para agentes.

O Sharkly não torna um agente imune a injeções — nenhuma ferramenta pode prometer isso atualmente. Ele oferece um espaço para delimitar o escopo antes do início de uma execução. Os agentes rodam nos Computers que você conecta, por meio de um serviço local que estabelece a conexão para fora; assim, uma configuração típica não exige portas de entrada abertas. Convidados só podem acessar os Spaces aos quais forem adicionados explicitamente. Ações de terceiros em fluxos de automação passam por conectores autorizados por você. A documentação recomenda nunca armazenar senhas, tokens ou chaves em instruções de Skill e conceder aos repositórios apenas o privilégio mínimo necessário para a Task.

Os agentes pesquisam, executam e reportam. Os humanos concedem permissões e aprovam os resultados. Para ver os detalhes, leia o que um agente de programação deve e não deve ter permissão para fazer e onde posicionar portões de aprovação.

Conclusão

O ataque ao Rovo não tem nada de mirabolante. Um arquivo, uma requisição rotineira e uma ferramenta de URL sem limites para o que pode abrir foram suficientes — e a opção de configuração que a maioria das equipes adotou não cobria essa ferramenta. Até o momento em que este texto foi escrito, a rota transmitida por conteúdo não tem correção confirmada.

Encare a delimitação de escopo como o controle que está em suas mãos. Mapeie o que o Rovo lê, elimine conectores não utilizados e teste você mesmo a rota de saída. Em seguida, faça três perguntas para cada agente utilizado pela sua equipe: o que ele pode ler? Que textos não confiáveis chegam até ele? E para onde ele pode enviar dados? Para reunir seus agentes de programação em um único quadro com o escopo claramente definido por tarefa, o Sharkly é gratuito para organizações de até 5 pessoas.

Perguntas frequentes

O que é o ataque de exfiltração de dados no Atlassian Rovo?

É um ataque indireto de injeção de prompt publicado pela PromptArmor em 5 de agosto de 2026. Instruções ocultas fazem com que o Rovo anexe dados do Jira e do Confluence à URL de um invasor e a abra.

Desativar a pesquisa na web do Rovo protege meus dados?

Não, segundo a PromptArmor. A opção de configuração não remove a ferramenta que realiza a abertura de URLs.

A Atlassian já corrigiu a injeção de prompt no Rovo?

Não encontramos nenhum comunicado oficial nem correção confirmada pela Atlassian para a falha apontada pela PromptArmor até 27 de outubro de 2026. A vulnerabilidade separada do RovoBlast já foi corrigida.

O Rovo Dev foi afetado?

O Rovo Dev é o agente de programação da Atlassian, um produto diferente do Rovo integrado ao Jira e ao Confluence, e a análise da PromptArmor não abrange essa ferramenta. Consulte nosso guia sobre o plano gratuito do Rovo Dev.

Agentes de programação são vulneráveis ao mesmo ataque?

Sim. Qualquer agente que leia textos não confiáveis e tenha acesso à rede apresenta o mesmo risco. Limite o que ele pode ler, quais credenciais possui e para onde pode enviar dados.