Incidente de Segurança do GitLab: Tentativa de Exploração do CVE-2026-97229

Artigo original ↗ Discussão no Hacker News ↗

Um incidente de segurança envolvendo o GitLab no Alpine Linux destaca como uma vulnerabilidade crítica na verdade veio do motor de expressões regulares do Ruby, e não do próprio código do GitLab. Comentadores argumentam que isso expõe problemas sistêmicos ao depender de builds personalizados, dependências fixadas e bibliotecas em C, além de mostrar como o scanning tradicional baseado em CVE pode deixar passar problemas quando componentes upstream corrigem silenciosamente. O debate se amplia para se ferramentas auto-hospedadas complexas como o GitLab deveriam ficar diretamente na internet pública, os limites de SaaS e garantias de residência de dados, e a necessidade de patching mais automatizado e contínuo, além de linguagens mais seguras para software exposto à rede.

Natureza da Vulnerabilidade e Problemas na Cadeia de Suprimentos

  • O problema do GitLab decorre de bugs no motor de regexp do Ruby, e não no próprio código do GitLab.
  • Os pacotes oficiais do GitLab distribuem o Ruby com um patch fora da árvore; a imagem do GitLab no Alpine usava o Ruby “normal” e permaneceu vulnerável mesmo após atualizar o próprio GitLab.
  • Como o Ruby não solicitou CVEs para suas correções, scanners de vulnerabilidades que se baseiam em versões do GitLab (ou em CVEs do Ruby) considerariam falsamente algumas imagens como seguras.

Práticas de Upgrade, Dependências e Build

  • Construir imagens localmente e fixar dependências cria “caches locais” que precisam ser mantidos ativamente; caso contrário, eles deixam passar correções críticas.
  • Muitos ecossistemas (Ruby, PHP, Python, JS, Lua etc.) veem upgrades lentos de runtime porque as versões ficam rigidamente travadas nas aplicações.
  • Comentadores argumentam que rebuilds automatizados quase constantes, rastreamento de dependências e upgrades contínuos estão se tornando inevitáveis.

Exposição: VPN, Zero Trust e Serviços Públicos

  • Vários defendem que ferramentas auto-hospedadas deveriam ficar atrás de VPNs ou proxies sensíveis à identidade; apenas organizações com equipes de segurança de verdade deveriam expô-las publicamente.
  • Outros observam que “zero trust” não significa “acessível publicamente”, mas sim forte controle de acesso na borda da aplicação.
  • Levanta-se a questão de saber se esse tipo de exploit poderia ocorrer dentro de uma VPN; a implicação é que sim, se o serviço vulnerável estiver acessível.

SaaS vs Auto-Hospedagem e Preocupações com Dados na UE

  • Há debate sobre se empresas da UE podem hospedar legalmente dados sensíveis com provedores SaaS fora da UE (por exemplo, devido ao GDPR e ao CLOUD Act).
  • Alguns dizem que fornecedores de SaaS oferecem opções de residência de dados na UE; outros desconfiam de alegações sobre soberania dos dados e treinamento de IA com dados de clientes.
  • Criar substitutos internos para SaaS por “vibe-coding” é visto como atraente em termos de custo, mas arriscado se ninguém assumir a segurança e a manutenção de longo prazo.

Linguagens, Segurança de Memória e Regex a Partir de Entrada Não Confiável

  • Há frustração com bugs recorrentes em bibliotecas C (estouro de inteiros, double free) e pedidos para mover código voltado à rede para fora de C.
  • Contra-argumentos: reescrever tudo não é realista; até reescritas em Rust (como análogos de sudo/coreutils) têm bugs.
  • Linguagens com segurança de memória, como Rust, não conseguem impedir todos os bugs lógicos (por exemplo, blowups de regex, wraparounds de inteiros), mas ajudam a evitar vetores típicos de RCE.
  • Alguns insistem que compilar regex a partir de entrada não confiável é inerentemente perigoso; outros questionam até onde esse argumento deve ir.

Containers, Tags e Scanning

  • O Alpine republicou a imagem 19.3.6 com Ruby atualizado; alguns defendem que deveriam ter mudado a tag, enquanto outros dizem que tags denotam a versão do app, não a imutabilidade da imagem.
  • A recomendação é fixar imagens por digest (SHA) e usar ferramentas (por exemplo, Renovate) para acompanhar mudanças.
  • Um aspecto “ruim” é que scanners baseados em versão classificam erroneamente a imagem vulnerável como corrigida, porque a versão do GitLab já passou do limite corrigido enquanto o patch oculto do Ruby não tem um CVE.

Alternativas ao GitLab e Resposta a Incidentes

  • Há sugestões de mudar para forges mais simples, como Forgejo ou Gitea, para reduzir a superfície de ataque; outros observam que elas também acumulam CVEs, apenas menos que o GitLab até agora.
  • Alguns acreditam que grandes stacks open source amplamente usados poderiam ser sistematicamente endurecidos com financiamento suficiente e ferramentas avançadas (incluindo IA).
  • O postmortem transparente do Alpine e sua resposta conservadora (tratar “ausência de evidência” como não sendo prova suficiente de segurança) são elogiados como comportamento responsável.