Sat, 25 Jul 2026
← VoltarPesquisadores de segurança publicaram pela primeira vez um código de exploração funcional em 24 de julho para uma falha do GitLab que o GitLab corrigiu seis semanas antes, em 10 de junho.
Pesquisadores de segurança publicaram pela primeira vez um código de exploração funcional em 24 de julho para uma falha do GitLab que o GitLab corrigiu seis semanas antes, em 10 de junho. Ele executa comandos como git em qualquer servidor 18.11.3 autogerenciado que não tenha recebido a atualização. Qualquer usuário autenticado que possa enviar para um projeto pode executá-lo. O invasor confirma um notebook Jupyter criado e abre seu diff de commit, que vaza um ponteiro de heap.
Chega disso e uma investigação automatizada pode localizar as bibliotecas na memória. Mais dois notebooks disparam a carga útil. Sem direitos de administrador, sem acesso de CI ou executor, sem interação com a vítima, sem acesso ao projeto de outra pessoa. O GitLab não registrou a correção como uma correção de segurança.
Uma análise do The Hacker News encontrou o problema do Oj 3.17.3 listado nas correções de bugs no lançamento do patch de 10 de junho, não na tabela de correções de segurança. Não há CVE, pontuação CVSS e nenhuma menção à cadeia de diferenças de notebook. Os operadores que fizeram a triagem dessa liberação em relação à tabela de segurança não tinham motivos para tratá-la como urgente. Dois bugs de corrupção de memória no Oj, um analisador Ruby JSON implementado em grande parte em C nativo, fazem a cadeia funcionar.
deepfirst diz que seu sistema os sinalizou de forma autônoma e os pesquisadores os acorrentaram manualmente. O renderizador de notebook do GitLab, uma gema na árvore chamada ipynbdiff, passa JSON .ipynb controlado pelo repositório para Oj::Parser.usual.parse dentro de um trabalhador Puma de longa duração, para que os bytes controlados pelo invasor alcancem a memória C gerenciada manualmente de Oj dentro do processo do aplicativo. Um bug grava uma pilha de aninhamento fixa de 1.024 bytes até controlar o retorno de chamada inicial do analisador. O outro trunca uma chave de objeto de 65.565 bytes para 29 em um campo assinado de 16 bits e retorna um ponteiro de heap ativo, que o GitLab renderiza no diff.
O vazamento localiza libc e a gravação aponta o retorno de chamada para system(). Todos os níveis são afetados, CE e EE, Gratuito até Ultimate. Ruby em si não é. Oj 3.17.2 trouxe outras correções da mesma revisão, mas não essas duas.
Atualize para 18.10.8, 18.11.5 ou 19.0.2. Nem o GitLab nem o deepfirst oferecem uma solução alternativa para quem não consegue. O pesquisador do deepfirst, Yuhang Wu, disse ao The Hacker News que não tem conhecimento de uma opção documentada do GitLab que desative totalmente o caminho vulnerável do notebook-diff, e que o deepfirst não validou uma solução alternativa apenas de configuração que possa recomendar. Manter usuários não confiáveis longe da renderização de diferenças de notebook removeria esse ponto de entrada em princípio, disse ele, mas as operadoras que não podem atualizar devem pedir ao GitLab orientação específica para sua implantação.
A armadilha é Helm e Operador: verifique a versão do GitLab dentro da imagem do Webservice executando o Puma, não o gráfico ou a versão do Operador. Qualquer coisa entre 15.2 e 18.9 não tem backport, porque essas linhas ficam fora dos trens de patch mantidos pela segurança do GitLab, então essas instalações precisam migrar para uma versão com suporte. Os comandos são executados como git, a conta por trás do Puma. Até onde isso vai depende de como a instalação é isolada.
Ao alcance: código-fonte, segredos do Rails, credenciais de serviço, dados de CI/CD e serviços internos com os quais o aplicativo pode se comunicar. A exploração pública foi criada para GitLab 18.11.3 em x86-64. As compensações do gadget, o estado do registro e o comportamento do jemalloc vieram todos dessa imagem, e uma base de biblioteca recuperada é mantida apenas até que o mestre do Puma seja reiniciado, portanto, isso não ocorre em um alvo arbitrário. Os bugs do Oj são gerais e a exploração vai além do que a imagem sugere.
Wu disse que o caminho de exploração não é específico para 18.11.3, e que redirecionar outra versão do GitLab na mesma arquitetura geralmente precisaria apenas de pequenos ajustes, principalmente gadgets atualizados ou compensações de símbolos. Essas compensações geralmente não mudam em versões próximas, porque os gadgets vêm de Ruby e de bibliotecas de sistema, em vez do próprio código do GitLab. A arquitetura é a verdadeira barreira. Mudar para ARM64 significaria diferentes convenções de chamada, gadgets, uso de registro e possivelmente comportamento de heap diferente, e o ambiente de compilação, libc, alocador e compilação do Ruby são mais importantes do que a versão GitLab.
primeira medida de profundidade de cinco a dez minutos para a pesquisa de memória em uma instalação nova de dois trabalhadores e projeta de uma a duas horas em instalações de execução mais longa. Sua redação contém a cadeia completa. O deepfirst relatou os bugs do Oj em 21 de maio, o mantenedor fundiu as correções em 27 de maio e o Oj 3.17.3 foi enviado em 4 de junho. A cadeia GitLab foi para o GitLab em 5 de junho, foi confirmada em 8 de junho e corrigida em 10 de junho.
Wu disse que o deepfirst não solicitou identificadores CVE para nenhum dos problemas. A cadeia do GitLab passou pelo programa HackerOne do GitLab, que não atribuiu ao deepfirst nenhum identificador separado para ele, e os dois bugs do Oj foram direto para o mantenedor sem nenhuma solicitação de CVE e nenhum atribuído ao conhecimento do deepfirst. A ausência, disse ele, reflete como as divulgações foram coordenadas, e não algo sobre a gravidade. deepfirst diz que não está ciente da exploração em estado selvagem e que o GitLab reproduziu o RCE de forma independente.
Wu disse que isso se baseia na ausência de relatórios e na profundidade de não ver nada fora de seu próprio ambiente de pesquisa, e não na telemetria. A empresa não tem acesso aos dados internos ou ambientes de clientes do GitLab, disse ele, e o GitLab é a fonte certa para qualquer conclusão tirada deles. Sua revisão mais ampla do OJ produziu mais nove comunicados CVE, nenhum deles nesta cadeia. O GitLab não respondeu às perguntas do The Hacker News sobre por que a correção não foi classificada como um problema de segurança e se um CVE será atribuído.
Esta história será atualizada se isso acontecer. Corrigido em 26 de julho de 2026: uma versão anterior dizia que portar o exploit é um trabalho real. deepfirst diz que redirecionar outra versão do GitLab na mesma arquitetura geralmente requer apenas pequenas atualizações de deslocamento; o trabalho substancial está mudando para uma arquitetura diferente. Saiba como 300 líderes empresariais estão gerenciando riscos de código aberto orientados por IA, remediação de dívidas e governança em escala.
Aprenda como controlar riscos, proteger software criado por IA e manter o controle à medida que o desenvolvimento avança na velocidade da máquina. Receba as últimas notícias, insights de especialistas, recursos exclusivos e estratégias de líderes do setor, tudo gratuitamente.