GitHub Enterprise Server tem SSRF crítica que expõe credenciais internas (CVE-2026-9312)

A GitHub corrigiu uma falha crítica de server-side request forgery no GitHub Enterprise Server, a edição auto-hospedada que bancos, fintechs e órgãos públicos rodam dentro do próprio data center para manter o código sob controle. Catalogada como CVE-2026-9312 e divulgada pela própria GitHub em 27 de maio, a vulnerabilidade recebeu nota 9,2 no CVSS 4.0 e permite que um atacante sem nenhuma autenticação obrigue o servidor a disparar requisições contra serviços internos, com potencial de expor credenciais.

Como a falha funciona

O ponto de entrada é um endpoint de upload que valida mal os dados recebidos. Injetando sequências de path traversal nos parâmetros da requisição, o atacante quebra o fluxo previsto e redireciona chamadas internas de API para destinos sob seu controle, o padrão clássico de SSRF registrado como CWE-918. A partir daí, segundo o registro publicado pela GitHub, é possível alcançar serviços internos e expor credenciais sensíveis.

O vetor CVSS conta o resto. A falha dispensa privilégios (PR:N) e interação do usuário (UI:N), o que a torna alcançável da borda da rede, mas exige condições específicas no ambiente: a string marca complexidade alta (AC:H) e requisitos de ataque presentes (AT:P). Quando essas condições estão dadas, o impacto sobre confidencialidade, integridade e disponibilidade do sistema é alto nos três eixos (VC:H/VI:H/VA:H). É a soma de acesso sem credencial com impacto total que sustenta o 9,2.

Falhas de SSRF são a praga recorrente das aplicações corporativas expostas à internet porque transformam o servidor em um procurador do atacante: quem fala com o sistema externo passa a falar, por tabela, com tudo o que o sistema enxerga por dentro. Num produto que orquestra código-fonte, essa "visão interna" inclui justamente o que ninguém quer ver vazado.

Quais versões precisam de patch

Quatro linhas de release estão afetadas: da 3.16.0 à 3.16.19, da 3.17.0 à 3.17.16, da 3.18.0 à 3.18.10 e da 3.19.0 à 3.19.7. As correções saíram nas versões 3.16.20, 3.17.17, 3.18.11 e 3.19.8, listadas nas notas de release de administração da plataforma. Instalações em qualquer build anterior dentro dessas faixas seguem expostas.

Aqui está o detalhe operacional que separa o GitHub Enterprise Server da nuvem pública da GitHub: a atualização é responsabilidade do cliente. Não há patch silencioso aplicado pelo fornecedor durante a madrugada. O relógio de remediação começa a correr no time de infraestrutura de cada empresa, e cada dia de atraso é um dia a mais de janela.

O que muda para o Brasil

A leitura brasileira passa por onde o GHES costuma ser instalado. Empresas que não podem ou não querem entregar o repositório à nuvem da GitHub, caso de bancos, seguradoras, integradores de governo e consultorias de TI que custodiam código de clientes regulados, mantêm a versão auto-hospedada para reter o repositório dentro do perímetro e atender exigências de residência de dados sob a LGPD e as normas do Banco Central. O efeito colateral é que muitas dessas instâncias ficam acessíveis pela internet para permitir trabalho remoto e integração com pipelines de entrega.

Uma SSRF sem autenticação nesse contexto pesa mais do que a média. O GitHub Enterprise Server fica encostado em segredos de CI/CD, runners de build e registries internos de artefatos. Uma credencial vazada por esse caminho não abre apenas um repositório: abre a esteira que compila e empacota o software que vai para produção. Para uma consultoria que hospeda o código de dezenas de clientes na mesma instância, a conta de raio de impacto é imediata, e o incidente de um vira incidente de todos.

A recomendação prática não depende de haver exploração observada. Brechas pré-autenticação alcançáveis pela rede entram no topo da fila por definição, e a janela entre a publicação do aviso e a varredura em massa de servidores expostos costuma ser medida em dias. Quem opera GHES voltado para a internet deveria tratar a subida para a build corrigida como tarefa da semana e, em paralelo, revisar quais tokens de serviço estiveram ao alcance do endpoint vulnerável. Patch fecha a porta; rotação de credenciais responde pela pergunta que o patch não responde, a de quem já passou por ela.