Pular para conteúdo
Voltar aos artigos
security9 min

Atlassian CVE-2026-21589: falha crítica sem login no Jira, Confluence e Bitbucket Data Center já tem tentativas de exploração

Atlassian CVE-2026-21589: critical no-login flaw in Jira, Confluence and Bitbucket Data Center already draws exploitation attempts

KGA IT
2026-10-129 min
SecurityAtlassianCVE-2026-21589JiraConfluenceBitbucketVulnerabilityPatch Management
Ilustração abstrata: rack de servidores com documentos escapando por uma brecha em uma barreira de segurança

Introdução

Em 5 de outubro de 2026, a Atlassian publicou um alerta fora do calendário normal para a CVE-2026-21589, uma falha de acesso arbitrário a arquivos que atinge todas as versões de oito produtos self-hosted: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo e Crowd (todos na edição Data Center), além de Crucible e Fisheye. A própria Atlassian classifica a falha como crítica (CVSS 4.0: 9,3). Um atacante sem login consegue ler arquivos dentro do diretório raiz da aplicação web.

O que tornou o caso urgente foi a velocidade. Um dia depois do alerta, a watchTowr Labs publicou a análise técnica. Poucas horas depois, a empresa de inteligência de ameaças Previdian informou que tentativas de exploração já apareciam na sua rede de honeypots.

Se a sua empresa, ou um fornecedor que trabalha para você, mantém Jira, Confluence ou Bitbucket em servidor próprio ou em nuvem própria (AWS, Azure etc.), este artigo é para você. Resumimos o que foi confirmado, quais versões corrigem o problema, o que fazer se não der para atualizar hoje e como procurar sinais de ataque nos logs. Não publicamos código de exploração nem passo a passo de ataque. Todas as informações vêm das fontes listadas no final.

O que a Atlassian confirmou

Segundo o alerta oficial:

  • A falha permite que um atacante não autenticado acesse arquivos específicos dentro do diretório raiz da aplicação web.
  • Para explorar, é preciso saber o nome e o caminho exatos do arquivo. A falha não permite listar o conteúdo de diretórios.
  • "Em algumas configurações, pode haver arquivos sensíveis presentes que aumentam o seu risco", diz a empresa.
  • Os produtos Atlassian Cloud afetados já foram corrigidos, e a investigação da Atlassian não encontrou evidência de exploração. Clientes Cloud não precisam fazer nada.
  • A Atlassian afirma que não consegue confirmar se as instâncias de um cliente foram afetadas e recomenda que a equipe de segurança verifique todas as instalações.

Por que "só ler arquivos" virou nota 9,3

À primeira vista, ler arquivos da pasta da aplicação parece menos grave do que executar código. A análise da watchTowr mostra por que não é bem assim:

  1. Causa comum. Os oito produtos compartilham a mesma biblioteca, a atlassian-plugins-webresource. A lógica de tratamento de caminhos dessa biblioteca permitia contornar as proteções contra path traversal. Por isso a mesma falha aparece em produtos tão diferentes.
  2. Alcance. Nos testes da watchTowr com Jira, Confluence e Bitbucket, foi possível ler qualquer arquivo dentro do servidor de aplicação (sem sair do contexto do Tomcat), incluindo arquivos normalmente protegidos da pasta WEB-INF.
  3. O elo com o Crowd. Quando o Jira usa o Atlassian Crowd (o serviço central de identidade e SSO da Atlassian), a configuração fica em WEB-INF/classes/crowd.properties. Segundo a watchTowr, esse arquivo guarda o nome e a senha da aplicação em texto puro. Com essas credenciais, um atacante pode falar direto com o Crowd, listar usuários, criar contas e colocá-las em grupos de administração. No laboratório da watchTowr, isso levou a acesso de administrador do Jira.

A watchTowr observa que, se o Crowd aceita conexões só de uma lista de IPs autorizados, esse cenário fica bem mais difícil. A empresa criou uma prova de conceito completa, mas não a publicou. Divulgou apenas uma ferramenta que verifica se uma instância de Jira, Confluence ou Bitbucket está vulnerável.

A escala também preocupa. Segundo a watchTowr, uma busca na internet mostra pouco menos de 700 mil instâncias só do Confluence.

Linha do tempo

  • 5 de outubro: a Atlassian publica o alerta e as versões corrigidas.
  • 6 de outubro: a watchTowr publica a análise técnica. Horas depois, a Previdian relata tentativas de exploração nos seus honeypots, segundo a Help Net Security.
  • 7 de outubro: a VulnCheck coloca a CVE-2026-21589 na sua própria lista de vulnerabilidades exploradas (KEV), após observar atividade contra o Bamboo Data Center, segundo a Infosecurity Magazine.
  • 12 de outubro (hoje): a falha ainda não está no catálogo KEV da CISA. Conferimos a versão 2026.10.08 do catálogo.

Um ponto importante: os relatos públicos falam de tentativas de exploração vistas em honeypots. Não encontramos relato público de vítimas confirmadas. Isso não é motivo para esperar. Instâncias expostas na internet devem ser tratadas como alvo.

Versões corrigidas

A Atlassian recomenda atualizar cada instalação para uma das versões abaixo, ou para a mais recente. Todas as versões anteriores estão afetadas.

ProdutoVersões corrigidas
Jira Software Data Center9.12.40 / 10.3.26 / 11.3.12
Jira Service Management Data Center5.12.40 / 10.3.26 / 11.3.12
Confluence Data Center9.2.26 / 10.2.19
Bitbucket Data Center9.4.26 / 10.2.8 / 10.5.1
Bamboo Data Center10.2.24 / 12.1.12
Crowd Data Center6.3.7 / 7.0.3 / 7.1.7 / 7.2.4
Crucible4.9.15
Fisheye4.9.15

A recomendação da Atlassian é ir para a versão LTS corrigida ou para uma posterior. A política atual da empresa é publicar novas versões de manutenção em vez de patches binários.

Se não der para atualizar hoje

A Atlassian lista medidas temporárias. A primeira e mais simples é tirar a instância da internet até aplicar a correção ou a mitigação. Isso vale também para instâncias com login, porque a falha não exige autenticação.

Se a instância precisa continuar acessível, há três opções oficiais:

  1. Regra no WAF ou no proxy reverso (todos os produtos): bloquear URLs com o padrão de expressão regular publicado pela Atlassian, que barra .. imediatamente ao lado de /, \ ou ::, inclusive nas formas codificadas em URL. Depois de aplicar, teste se o bloqueio funciona.
  2. RewriteValve do Tomcat (Confluence, Jira, JSM, Bamboo e Crowd): uma regra no rewrite.config, aplicada nó a nó do cluster, com backup antes.
  3. Regra no urlrewrite.xml (só Bitbucket): aplicada em todos os nós, mirrors e mirror farms.

Use o texto exato do alerta da Atlassian para configurar essas regras e não copie versões de terceiros. Lembre que mitigação é ponte, não solução. A meta continua sendo atualizar.

Como verificar se houve tentativa de ataque

A Atlassian orienta procurar evidências nos logs de acesso:

  • decodificar cada linha de requisição (até duas passagens de decodificação de URL) e procurar .. imediatamente ao lado de /, \ ou ::; ou
  • buscar nas linhas brutas, sem decodificar, usando a mesma expressão regular do alerta.

Na prática, recomendamos aos nossos clientes:

  1. Levante o inventário. Liste todas as instâncias Data Center, Crucible e Fisheye, incluindo as de teste e as que um fornecedor mantém para você.
  2. Analise os logs desde 5 de outubro, e de preferência antes disso. Se os logs giram rápido, copie-os já para um local central.
  3. Se usa Crowd, troque as senhas de aplicação configuradas no crowd.properties e em integrações parecidas, principalmente se encontrar requisições suspeitas. Revise usuários e grupos de administração criados ou alterados recentemente.
  4. Restrinja o Crowd a uma lista de IPs autorizados, como a própria watchTowr indica.
  5. Verifique outros segredos que possam estar em arquivos de configuração dentro da pasta da aplicação.
  6. Se encontrar indícios de comprometimento, preserve os logs antes de mexer no servidor e acione a sua equipe ou um parceiro de resposta a incidentes.

Conclusão

A CVE-2026-21589 junta três fatores que costumam terminar mal: não exige login, atinge todas as versões de produtos muito usados e virou alvo de tentativas de exploração horas depois de a análise técnica sair. Quem usa Atlassian Cloud não precisa agir. Quem mantém Jira, Confluence, Bitbucket, Bamboo ou Crowd em servidor próprio deve atualizar agora, ou ao menos tirar a instância da internet e aplicar a mitigação oficial, e revisar os logs e as credenciais do Crowd.

Vamos atualizar este artigo se a CISA incluir a falha no KEV ou se a Atlassian divulgar novos fatos.

Fontes


Quer levar isso para o seu negócio?

A KGA IT ajuda pequenas e médias empresas a implantar assistentes de IA, automações e sites. A consulta é gratuita e respondemos em até 24 horas. Planos a partir de ¥5.000/mês.

Vamos resolver seus desafios técnicos juntos?

A KGA IT Solutions tem times especializados em AI, cloud e DevOps para entregar a solução ideal para seu problema.

Fale Conosco