• O prazo de 14 de setembro da CISA para corrigir a vulnerabilidade CVE-2026-85706 do GitLab, explorada ativamente, já terminou
  • A correção do GitLab exige migrações de banco de dados, deixando instalações de nó único indisponíveis, enquanto implantações com vários nós atualizadas corretamente podem evitar interrupções

O fato

O prazo de 14 de setembro estabelecido pela CISA para corrigir a CVE-2026-85706 já terminou. A vulnerabilidade do GitLab está sendo explorada ativamente e, em determinadas condições, pode permitir que um usuário não autenticado leia arquivos de um servidor. A CISA adicionou a falha ao seu catálogo Known Exploited Vulnerabilities em 11 de setembro. O prazo federal se aplica às agências civis federais dos Estados Unidos sujeitas à exigência.

O GitLab lançou as versões corrigidas 19.3.2, 19.2.6 e 19.1.8 em 10 de setembro e recomendou que os clientes afetados com instalações autogerenciadas fizessem a atualização imediatamente. O GitLab.com já recebeu a correção, enquanto os clientes do GitLab Dedicated não precisam tomar nenhuma medida.

A atualização inclui migrações de banco de dados. Segundo o GitLab, uma instalação de nó único ficará indisponível até a conclusão dessas migrações. Instalações com vários nós podem ser atualizadas sem interrupção quando os operadores seguem o procedimento da empresa para evitar tempo de inatividade.

A avaliação

Para uma equipe que opera seu próprio servidor GitLab, a parte difícil desta correção não é decidir se deve instalá-la. É encontrar uma janela para uma migração urgente de banco de dados em uma plataforma que os desenvolvedores talvez estejam usando para gerenciar lançamentos já em andamento. Uma instância de nó único precisa parar enquanto esse trabalho é concluído.

Esperar por uma janela de manutenção mais tranquila mantém uma falha explorada ativamente sem correção por mais tempo. Atualizar imediatamente pode interromper o trabalho em repositórios, solicitações de mesclagem e outras atividades de desenvolvimento. Instalações com vários nós oferecem mais flexibilidade, mas o GitLab ainda exige a sequência correta de atualização; ter várias máquinas não elimina a alteração no banco de dados.

Para os leitores da BTW, este incidente torna visível um custo operacional da infraestrutura de desenvolvimento autogerenciada. A organização é responsável tanto pela janela emergencial de manutenção quanto pelos servidores. No GitLab.com e no GitLab Dedicated, esse trabalho de segurança já foi realizado para os clientes, enquanto os operadores de instâncias autogerenciadas precisam encaixar a mesma correção no próprio calendário de lançamentos e restabelecer o serviço corretamente depois.

O que acompanhar

Acompanhe se os operadores de instâncias autogerenciadas confirmam tanto a instalação de uma versão corrigida quanto a conclusão bem-sucedida da migração do banco de dados. Atualizações atrasadas, migrações malsucedidas ou novas orientações do GitLab mostrariam em que pontos o trabalho emergencial de segurança está colidindo com os cronogramas de desenvolvimento. Evidências de exploração antes da correção acrescentariam uma tarefa separada de resposta a incidentes.