Falha crítica no GitLab permite execução de código sem autenticação
O GitLab publicou, em 21 de outubro, atualizações de segurança para corrigir uma vulnerabilidade crítica que pode permitir a execução remota de código em instalações próprias da plataforma. Identificada como CVE-2026-110264, a falha recebeu pontuação CVSS 10.0 – o nível máximo de gravidade – e não conta com uma medida alternativa capaz de substituir a atualização.
O problema está relacionado a um estouro de inteiro durante a compilação de expressões regulares. Um invasor pode enviar uma expressão especialmente construída para provocar o erro. Em determinadas condições, a falha permite que instruções sejam executadas no servidor que hospeda o GitLab.
O ataque pode ser realizado pela rede e não exige uma conta válida nem qualquer ação de um usuário. Por isso, organizações que mantêm instâncias próprias da plataforma devem tratar a correção como prioridade, sobretudo quando o serviço está acessível pela internet.
A vulnerabilidade afeta versões do GitLab a partir da 7.0, lançada em 2014, nas edições Community e Enterprise. As versões com a correção são 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13. Administradores devem verificar qual ramificação utilizam e instalar a atualização correspondente.
A aplicação do pacote crítico divulgado em 12 de outubro não resolve este novo problema. Aquele conjunto corrigiu a CVE-2026-97229, também classificada com CVSS 10.0 e igualmente ligada ao processamento de expressões regulares, mas cobriu apenas as versões 19.2 e posteriores. As correções mais recentes avançam um patch além das versões daquele pacote.
O GitLab.com já opera com a versão corrigida. Clientes do GitLab Dedicated também receberam as atualizações a partir das versões 19.3.5-internal0 e 19.4.2-internal0. Já as instalações autogerenciadas precisam ser atualizadas pelos próprios responsáveis pela infraestrutura.
A instalação inclui migrações de banco de dados e pode causar interrupção do serviço em ambientes de nó único. Antes de iniciar o procedimento, é recomendável planejar uma janela de manutenção, confirmar a disponibilidade de cópias de segurança e seguir o processo de atualização apropriado à versão instalada. Em ambientes com vários nós, a sequência de aplicação também deve ser organizada para reduzir o impacto operacional.
O pacote de segurança reúne correções para 12 vulnerabilidades. A CVE-2026-110264 foi comunicada por um pesquisador por meio do programa de recompensas do GitLab. A gravidade do caso é especialmente relevante porque plataformas de CI/CD podem armazenar credenciais de serviços em nuvem, tokens de acesso e materiais usados para assinar artefatos destinados à produção.
Uma invasão desse tipo não se limita ao próprio servidor do GitLab. Caso um invasor consiga executar código no ambiente, poderá tentar acessar dados e credenciais disponíveis para a aplicação, interferir em pipelines ou comprometer etapas do processo de desenvolvimento. O alcance efetivo dependerá das permissões configuradas e dos segredos armazenados na instância.
Até 22 de outubro, não havia relatos de exploração da falha. Naquele momento, ela também não constava no NVD nem na relação de vulnerabilidades exploradas mantida pela CISA. A ausência de registros conhecidos, porém, não elimina o risco nem dispensa a aplicação do patch, especialmente diante da possibilidade de ataque sem autenticação.
Para organizações que não conseguem atualizar imediatamente, o GitLab disponibilizou duas regras de detecção: uma voltada a identificar travamentos do compilador de expressões regulares e outra destinada a apontar erros repetidos durante a renderização de marcação. Esses mecanismos podem ajudar a identificar sinais suspeitos, mas não corrigem a vulnerabilidade e não substituem a atualização.
Enquanto a instalação não for corrigida, equipes de segurança podem reforçar o monitoramento de logs, observar reinicializações ou falhas inesperadas do serviço e revisar acessos à infraestrutura. Também é prudente limitar a exposição da instância à rede sempre que possível e verificar se credenciais sensíveis estão protegidas e têm permissões restritas.
A prioridade imediata é confirmar a versão em execução e aplicar o pacote correspondente. Depois da atualização, os responsáveis devem validar o funcionamento dos pipelines, revisar alertas e avaliar se houve atividade anormal no período anterior à correção. Como o GitLab pode concentrar recursos importantes para o desenvolvimento e a implantação de software, a resposta deve envolver tanto as equipes de infraestrutura quanto as de segurança.