PoC público expõe RCE silencioso no GitLab: falha sem CVE deixa servidores corporativos descobertos
Pesquisadores da depthfirst publicaram em 25 de julho código de exploração funcional para RCE no GitLab, corrigido seis semanas antes sem CVE e sem nota de segurança. Qualquer usuário com acesso push pode comprometer o servidor.
O exploit e o que ele faz
Pesquisadores da depthfirst publicaram em 25 de julho de 2026 código de exploração funcional para uma vulnerabilidade de execução remota de código no GitLab. O exploit roda comandos como o usuário git em qualquer servidor self-managed na versão 18.11.3 que não tenha aplicado o patch de 10 de junho. Não requer direitos de administrador, acesso a pipelines de CI/CD, permissões de runner nem interação de um mantenedor: qualquer usuário autenticado com permissão de push para um único projeto, o nível de acesso que qualquer desenvolvedor em um repositório aberto já possui por padrão, tem o suficiente para disparar a cadeia completa.
O atacante faz o commit de um Jupyter notebook especialmente construído e abre o diff de revisão no GitLab, operação que vaza um ponteiro de heap do servidor. Repetições controladas permitem que uma sonda automatizada mapeie as bibliotecas carregadas na memória. Dois notebooks adicionais disparam a payload. A técnica não depende de falhas no kernel ou no sistema operacional host, apenas de comportamento previsível da biblioteca Oj ao processar o diff de conteúdos JSON aninhados específicos. A ausência de interação do lado da vítima, sem clicar em link, aprovar merge request ou abrir arquivo, é o atributo que eleva o risco em ambientes corporativos com muitos colaboradores externos.
Por que não há CVE e o que isso significa
O GitLab corrigiu a biblioteca Oj para a versão 3.17.3 no release de 10 de junho, mas registrou a mudança como correção de bug comum, não como atualização de segurança. Nenhum CVE foi emitido. A atualização não constou da tabela de security fixes das versões 18.11.4 e 18.11.5. O resultado prático: equipes de patch management que dependem exclusivamente de alertas com CVSS score tiveram 45 dias para aplicar uma correção que não sinalizava urgência, enquanto a depthfirst preparava o proof-of-concept funcional.
A empresa optou por publicar o exploit sem coordenação prévia com o fornecedor. A justificativa é direta: o patch estava disponível há seis semanas e a janela de remediação razoável havia expirado sem que o GitLab classificasse o risco publicamente. O GitLab não havia emitido nota de segurança específica sobre o exploit da depthfirst até o fechamento desta matéria, o que também significa que scanners de vulnerabilidade baseados em CVE não identificam o servidor desatualizado como vulnerável.
Dimensão do risco global
Mais de 40 mil servidores GitLab self-managed estão acessíveis diretamente na internet, segundo pesquisa da Cycode com dados do Shodan. Esse número representa apenas as instâncias expostas publicamente; o universo de servidores protegidos por VPN, redes internas e proxies reversos é consideravelmente maior. O modelo self-managed é predominante em setores regulados, como financeiro, saúde e defesa, onde políticas internas proíbem o uso de instâncias SaaS. Esses ambientes tendem a ter ciclos de patching medidos em semanas, atrelados a janelas de manutenção mensais, não em horas.
O risco não se restringe a organizações americanas. Consultoras de TI na Índia, na Alemanha e no Brasil frequentemente hospedam instâncias self-managed para projetos de clientes, muitas vezes em ambientes de desenvolvimento compartilhado. Um servidor comprometido nesse modelo pode expor simultaneamente código-fonte, variáveis de ambiente e tokens de CI/CD de múltiplos projetos e múltiplos clientes. O baixo limiar de acesso, permissão de push para qualquer repositório da instância, amplia significativamente a superfície de ataque em organizações com centenas de colaboradores externos.
O que fazer agora
A correção existe e é objetiva: atualizar para 18.10.8, 18.11.5 ou 19.0.2. As três versões incluem o fix da biblioteca Oj 3.17.3. Ambientes protegidos por proxy reverso, VPN ou Web Application Firewall continuam vulneráveis se um atacante dispuser de credenciais válidas de qualquer usuário com permissão de push, seja por phishing ou por credential stuffing sobre repositórios com contribuições externas.
A ausência de CVE não pode servir de justificativa para postergar o patch. O exploit da depthfirst é público desde 25 de julho e funciona contra qualquer instância desatualizada. A janela entre a publicação de um PoC e o início de exploração ativa por atores menos sofisticados costuma ser medida em dias, não semanas. Equipes com ciclos de manutenção mensais ou trimestrais devem avaliar patching de emergência fora do calendário padrão.