Git
4 artigos com esta tag
GitLab CVE-2026-110264 (CVSS 10.0) e a CVE-2026-97229 explorada: como verificar e atualizar um GitLab self-managed
Em 21 de outubro de 2026, o GitLab lançou as versões de correção crítica 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13 para a Community Edition (CE) e a Enterprise Edition (EE). A falha mais grave, a CVE-2026-110264 (CVSS 10.0), é um estouro de inteiro ao compilar uma expressão regular especialmente elaborada que, sob certas condições, poderia permitir que um usuário não autenticado executasse código arbitrário no servidor GitLab. Quase todas as versões a partir da 7.0 são afetadas. Em 29 de outubro, a CISA incluiu uma falha irmã, a CVE-2026-97229 (CVSS 10.0, CWE-190), em seu catálogo de Vulnerabilidades Exploradas Conhecidas (KEV), com prazo até 1º de novembro. É o mesmo tipo de bug (um estouro de inteiro no compilador de expressões regulares de CI/CD, alcançável por um usuário não autenticado); o GitLab a corrigiu antes, em 12 de outubro, nas versões 19.4.2, 19.3.5 e 19.2.8, e ela afeta apenas 19.2.0 a 19.2.7, 19.3.0 a 19.3.4 e 19.4.0 a 19.4.1. Quem ainda está abaixo da 19.4.2, 19.3.5 ou 19.2.8 está exposto a uma falha explorada. Atualizar para as versões recomendadas aqui (19.5.1, 19.4.3, 19.3.6, 19.2.9) também corrige a CVE-2026-97229. O GitLab.com já está corrigido; instalações self-managed precisam ser atualizadas. A mesma versão de 21 de outubro corrige duas falhas de gravidade Alta (CVSS 8.2 e 7.5) e outras, mas essas correções só chegam nas linhas 19.3.6, 19.4.3 e 19.5.1. A causa raiz está no motor de expressões regulares do Ruby (Onigmo), e o Ruby lançou 4.0.9, 3.4.12 e 3.3.13 em 23 de outubro. Aplicações que compilam uma regexp a partir de strings controladas pelo atacante são afetadas, e o Regexp.timeout não protege contra os bugs. Os avisos do GitLab não dizem que a CVE-2026-110264 tenha sido explorada, e ela não consta no KEV em 30 de outubro. A Alpine Linux relatou uma tentativa de ataque contra o seu próprio GitLab pela CVE-2026-97229 em 20 e 21 de outubro, e que atualizar apenas o GitLab (para a 19.3.6) não fechou a falha porque a correção também exigia um Ruby corrigido; reconstruiu a instância e não encontrou evidência de que código do invasor tenha sido executado. Conclusão deste site: atualize o GitLab self-managed hoje, após verificar as paradas obrigatórias de atualização, chegue à 19.3.6 ou posterior e, se você mesmo compila o GitLab ou usa seu próprio Ruby, confira que esse Ruby também seja 3.3.13, 3.4.12 ou 4.0.9 ou posterior. Aplicações Ruby devem migrar para um Ruby corrigido e parar de montar regexps a partir de entrada do usuário.
Configurando a autenticação de dois fatores (2FA) no GitHub: app autenticador, passkeys, códigos de recuperação e o que fazer se perder o celular
Um guia para configurar a autenticação de dois fatores (2FA) no GitHub e evitar ficar trancado fora da conta. Desde março de 2023, o GitHub vem exigindo o 2FA, grupo por grupo, de usuários que contribuem com código no GitHub.com; depois de selecionado, você tem um prazo de 45 dias para se inscrever e um período de carência de 7 dias, após o qual não pode usar o GitHub.com até ativar o 2FA. O GitHub Docs recomenda um app autenticador TOTP como método principal, com uma passkey ou chave de segurança como reserva (passkeys, chaves de segurança e o GitHub Mobile só podem ser adicionados depois que o TOTP ou o SMS estiver configurado). A visão deste site: a falha comum de 2FA no GitHub não é a invasão da conta, mas você mesmo ficar trancado fora, e o Suporte do GitHub não consegue restaurar uma conta cujas credenciais de 2FA e métodos de recuperação foram todos perdidos. Guarde os 16 códigos de recuperação num gerenciador de senhas e registre um segundo método no mesmo dia. Aproveite para migrar para tokens fine-grained com validade, limpar apps autorizados e chaves SSH e conferir a proteção de push e os alertas do Dependabot.
Detenha segredos antes do commit com o gitleaks: pegue vazamentos de chave de API antes do push
Segredos não podem ser 'apagados depois que vazam'. Uma vez comitado, um segredo fica no histórico do Git, e uma vez enviado deve ser tratado como vazado — a chave precisa ser revogada/rotacionada. O gitleaks é uma ferramenta gratuita que varre todo o repo e o histórico de commits com regex/entropia para encontrar chaves de API, chaves privadas e tokens. O cerne da defesa são duas verificações: um hook de pre-commit que o detém localmente antes do push e CI/cron que pega o que escapa. O .gitignore só evita novo rastreamento — ele não detecta, então você ainda precisa de um scanner.
Git auto-hospedado vs. GitHub: qual é de fato mais seguro?
Auto-hospedar o Git não te torna 'mais seguro' — realoca o risco. A classe de exposição pública acidental desaparece, mas aplicar patches no servidor, backups e detecção de segredos pré-commit passam para você. A escolha certa se você continua fazendo esse trabalho; pior que o GitHub se você o negligencia. A visão deste site: a auto-hospedagem só funciona junto com seus controles compensatórios.