Jira e Confluence sob ataque: a falha 9.3 que lê ficheiros sem palavra-passe

Bastaram poucas horas entre a publicação de uma análise técnica detalhada e o aparecimento das primeiras tentativas de exploração. A vulnerabilidade crítica CVE-2026-21589, divulgada pela Atlassian a 5 de outubro de 2026, afeta todas as versões de oito produtos auto-alojados — entre eles Jira Software, Jira Service Management, Confluence e Bitbucket — e permite a um atacante sem credenciais ler ficheiros guardados na raiz da aplicação web. Investigadores demonstraram que, em cenários específicos com o Atlassian Crowd, essa leitura pode acabar em acesso administrativo ao Jira. As organizações portuguesas que mantêm instâncias Data Center no próprio centro de dados têm aqui uma correção urgente para aplicar.

Resposta rápida: A CVE-2026-21589 é uma falha de acesso arbitrário a ficheiros com CVSS 9.3 que afeta todas as versões anteriores às correções de oito produtos Atlassian Data Center auto-alojados. Depois de a watchTowr publicar detalhes técnicos e uma prova de conceito, foram detetadas tentativas de exploração em redes de honeypots. Atualize já cada instalação para uma versão corrigida (ou aplique as mitigações temporárias da Atlassian em todos os nós de cluster), retire do acesso público as instâncias expostas e reveja os registos de acesso. Os clientes de Atlassian Cloud não precisam de agir.

O que é a CVE-2026-21589 e porque é tão grave

No aviso publicado a 5 de outubro de 2026, a Atlassian descreve a falha como uma vulnerabilidade de acesso arbitrário a ficheiros que permite a um atacante não autenticado aceder a ficheiros específicos dentro do diretório raiz da aplicação web, em todas as versões de Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center, Crowd Data Center, Crucible e Fisheye. O fabricante atribuiu-lhe uma pontuação CVSS 4.0 de 9.3, calculada através da sua avaliação interna.

Há dois atenuantes importantes, que não devem ser confundidos com segurança. A Atlassian sublinha que a exploração exige conhecimento prévio do nome e do caminho exatos do ficheiro-alvo e que a vulnerabilidade não permite enumerar ou listar conteúdos de diretórios, mas acrescenta que, em algumas configurações, podem estar presentes ficheiros sensíveis que aumentam o risco. Por outras palavras: quem souber onde procurar — e os caminhos de instalações padrão são públicos — consegue extrair ficheiros de configuração sem qualquer credencial.

Segundo a empresa, os produtos cloud afetados já foram corrigidos, a investigação inicial não encontrou provas de exploração e os clientes que usam essas versões não precisam de tomar qualquer ação. O problema concentra-se, portanto, nas instalações geridas pelas próprias organizações.

Dois pontos e uma barra: a raiz técnica do problema

A análise técnica que mudou o cenário foi publicada pela watchTowr Labs. A 6 de outubro, os investigadores divulgaram uma análise da CVE-2026-21589 obtida por comparação entre pacotes Atlassian vulneráveis e corrigidos, identificando uma falha de travessia de diretórios em que sequências de dois pontos duplos (::) podem ser tratadas como separadores de caminho, permitindo ler ficheiros a partir da raiz web da aplicação. O relatório demonstrou ainda como a falha poderia ser usada para obter acesso de nível administrativo a Jira, Confluence e Bitbucket em determinadas instalações integradas com o Atlassian Crowd — o componente que fornece gestão centralizada de identidade, single sign-on, autenticação e autorização às aplicações Data Center ligadas.

Num ambiente de teste com Crowd e Jira, os investigadores conseguiram ler o ficheiro crowd.properties, que expunha credenciais aplicacionais, e usaram-nas depois para criar um utilizador e adicioná-lo ao grupo jira-administrators; a restrição de acesso ao Crowd por listas de IP permitidos pode bloquear este caminho de ataque. A ferramenta divulgada publicamente identifica instâncias vulneráveis através de pedidos de deteção seguros, sem criar utilizadores nem modificar os sistemas-alvo.

Cronologia: da correção à exploração em dois dias

Data (2026)Acontecimento
2 de outubroA Atlassian anexa o ficheiro de mitigação rewrite.config ao ticket público que acompanha o problema no Jira Data Center
5 de outubroPublicação do aviso de segurança crítico para a CVE-2026-21589, cobrindo oito produtos auto-alojados, com versões corrigidas e mitigações
6 de outubroA watchTowr Labs publica a análise técnica da falha
7 de outubroA empresa de segurança Previdian deteta atividade na sua rede de honeypots, poucas horas após a publicação do relatório técnico

De acordo com a Previdian, os detalhes técnicos foram suficientes para ajudar agentes de ameaça a procurar instâncias vulneráveis expostas e a sondá-las, tendo a rede de honeypots começado a observar atividade no espaço de duas horas após a divulgação do relatório e da prova de conceito. A telemetria da empresa terá registado 15 tentativas de exploração a partir de três endereços IP no Japão e nos Estados Unidos. Até ao momento da publicação deste artigo, a vulnerabilidade não constava do catálogo de vulnerabilidades exploradas conhecidas (KEV) da CISA.

Versões afetadas e correções

ProdutoVersões afetadasVersões corrigidas
Bitbucket Data CenterTodas9.4.26, 10.2.8, 10.5.1
Confluence Data CenterTodas9.2.26, 10.2.19
Jira Software Data CenterTodas9.12.40, 10.3.26, 11.3.12
Jira Service Management Data CenterTodas5.12.40, 10.3.26, 11.3.12
Bamboo Data CenterTodas10.2.24, 12.1.12
Crowd Data CenterTodas6.3.7, 7.0.3, 7.1.7, 7.2.4
CrucibleTodas4.9.15
FisheyeTodas4.9.15

A Atlassian recomenda que cada instalação afetada seja atualizada para uma versão corrigida ou para a versão mais recente, de preferência para a versão LTS corrigida.

O que fazer agora: mitigação e verificação

  • Inventariar todas as instâncias auto-alojadas dos oito produtos, incluindo ambientes de teste e sistemas esquecidos — a falha afeta todas as versões anteriores às correções.
  • Atualizar primeiro o que está exposto à Internet. O CERT-EU recomenda atualizar todas as instalações afetadas para uma versão corrigida o mais depressa possível, começando pelas instâncias acessíveis a partir da Internet, e verificar os registos de acesso em busca de sinais de exploração.
  • Se não for possível corrigir de imediato, restringir o acesso externo. A Atlassian indica que as instâncias acessíveis a partir da Internet pública, mesmo as que exigem autenticação do utilizador, devem ficar restringidas ao acesso externo até ser possível agir.
  • Aplicar as mitigações temporárias. Estas incluem uma regra de WAF ou de proxy que bloqueie os padrões de travessia indicados em todos os produtos afetados, regras RewriteValve do Tomcat para Confluence, Jira Service Management, Jira, Bamboo e Crowd, ou uma regra de reescrita de URL para o Bitbucket — e as alterações têm de abranger todos os nós do cluster, incluindo os mirrors do Bitbucket e os nós de mirror farm.
  • Procurar indícios de abuso. A Atlassian pede aos administradores que revejam os registos de acesso à procura dos padrões de travessia, com especial atenção a pedidos que contenham sequências :: em caminhos de recursos. A empresa avisa que não consegue determinar se instâncias individuais de clientes foram comprometidas.
  • Rodar segredos presentes em ficheiros de configuração (credenciais de integração com o Crowd, tokens de serviço, chaves de API) sempre que exista suspeita de leitura não autorizada. Atualizar o software não anula credenciais já expostas.

Porque é que isto importa em Portugal

Jira, Confluence e Bitbucket não são sistemas periféricos: concentram documentação interna, planos de projeto, código-fonte, bilhetes de suporte com dados de clientes e, frequentemente, credenciais em texto simples deixadas em páginas de equipa. Um acesso administrativo a estes ambientes é, na prática, um mapa detalhado da organização — exatamente o tipo de reconhecimento que precede ataques de ransomware e extorsão de dados.

Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a gestão de vulnerabilidades e a resposta atempada a avisos críticos deixaram de ser boas práticas opcionais: fazem parte das obrigações de gestão de risco, com deveres de notificação de incidentes significativos ao CNCS/CERT.PT. Se os ficheiros lidos contiverem dados pessoais — de colaboradores, clientes ou utilizadores de portais de suporte —, acrescem as obrigações do RGPD, incluindo a avaliação da necessidade de notificar a CNPD no prazo de 72 horas.

Para as PME, a lição é mais simples e igualmente dura: software auto-alojado traz responsabilidade de manutenção. Quem optou por manter o Jira ou o Confluence num servidor próprio — por custo, por requisitos de soberania de dados ou por inércia — assume o encargo de aplicar correções críticas em dias, não em trimestres. Este caso mostra o que isso significa na prática: entre a disponibilização da correção e as primeiras sondagens automatizadas passaram cerca de 48 horas.

Perguntas frequentes

A minha instância em Atlassian Cloud está em risco?

Não. De acordo com a Atlassian, os produtos cloud afetados já foram corrigidos e os clientes que os utilizam não precisam de tomar qualquer ação. A urgência aplica-se às instalações auto-alojadas Data Center e Server.

A falha permite executar código no servidor?

Não diretamente. Trata-se de acesso arbitrário a ficheiros, explorável sem autenticação para aceder a ficheiros específicos no diretório raiz da aplicação web, exigindo conhecimento prévio do nome e caminho exatos. O risco está no que esses ficheiros contêm: credenciais que permitam escalar privilégios noutros sistemas.

Basta aplicar a mitigação temporária em vez de atualizar?

Não é o recomendado. As regras de WAF, RewriteValve ou reescrita de URL servem para ganhar tempo, mas a Atlassian recomenda a atualização para a versão LTS corrigida ou posterior. Se usar mitigações, verifique que são aplicadas em todos os nós do cluster.

Como sei se já fui atacado?

Reveja os registos de acesso em busca de pedidos com padrões de travessia, nomeadamente sequências :: em caminhos de recursos, e procure contas de administrador criadas recentemente sem justificação. A Atlassian avisa que não consegue determinar se instâncias individuais de clientes foram comprometidas, pelo que a verificação cabe a cada organização.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Atlassian, pelo CERT-EU, pela watchTowr Labs e por outras empresas de investigação em segurança.