NotíciasO GitHub acrescentou três faixas de IP usadas para entregar webhooks. Se sua infraestrutura filtra conexões recebidas por uma allowlist fixa, inclua os novos prefixos agora; caso contrário, um proxy ou firewall pode começar a recusar eventos enviados pelo GitHub. A alteração foi registrada no changelog em 29 de outubro e vale para entregas de webhook em github.com em todos os planos, inclusive GitHub Enterprise Cloud.
Os novos prefixos são 9.234.98.160/28, 9.234.98.176/28 e 9.234.106.48/28. O GitHub os incluiu no campo hooks da API de metadados. Na consulta que fizemos durante a preparação desta pauta, os três já apareciam na lista. A API é a fonte para conferir a relação atual; uma allowlist permanente precisa acompanhar mudanças futuras também.
Quem precisa agir
O aviso importa para equipes que recebem webhooks do GitHub em servidores, gateways ou aplicações próprios e restringem o tráfego de entrada por endereço IP. Pode ser um serviço que dispara uma implantação quando há um push, cria notificações de pull requests ou encaminha eventos para uma ferramenta interna.
Se o endpoint é público e não há regra de allowlist por IP, não é necessário alterar a aplicação apenas por causa deste anúncio. Se a equipe usa um proxy ou firewall mantido por outra área, confirme quem atualiza as regras. A entrega do webhook é uma requisição HTTP de entrada; ela não altera os eventos assinados, o formato do payload nem a configuração do webhook dentro do repositório.
A nota oficial de 29 de outubro informa que os três prefixos foram adicionados à lista hooks do Meta API. O guia do GitHub sobre entregas de webhook a sistemas privados recomenda liberar no proxy apenas requisições HTTPS POST originadas do conjunto de IPs usado para webhooks. Isso reduz o tráfego que pode chegar ao serviço, mas não substitui a validação criptográfica do evento.
O que fazer com uma allowlist fixa
Primeiro, descubra onde a regra vive: firewall de nuvem, reverse proxy, gateway, ferramenta de segurança de rede ou configuração mantida como código. Compare a relação atual de endereços com o campo hooks retornado pela API e acrescente os três prefixos novos sem apagar os intervalos existentes que o sistema ainda utiliza. Evite copiar toda a lista de endereços do GitHub para uma regra de webhooks: o Meta API contém faixas destinadas a serviços diferentes, enquanto hooks é o campo específico para entregas de webhook.
Depois, valide a mudança em um ambiente de teste ou com uma entrega de teste. Confirme nos logs do proxy que a requisição chegou ao endpoint e que a aplicação registrou o evento esperado. Se não houver entrega, investigue primeiro a allowlist e os logs de bloqueio; a documentação de solução de problemas do GitHub lista restrições de rede entre as causas possíveis de falha de conexão.
Se a lista é gerada por código, prefira buscar periodicamente a fonte oficial e atualizar a regra a partir do campo hooks, com revisão e trilha de auditoria. O GitHub diz que pode alterar seus endereços e recomenda monitorar a API; mudanças manuais sem responsável costumam virar pontos cegos. A lista publicada também não é apresentada como inventário exaustivo de todos os IPs de todos os serviços do GitHub, então não a use como uma lista universal para liberar qualquer tráfego da plataforma.
Allowlist não autentica o payload
Um endereço de origem permitido demonstra apenas que a conexão veio de uma faixa liberada na camada de rede. Ele não prova, por si só, que o corpo recebido não foi alterado nem que a aplicação está processando o evento correto. O guia de boas práticas de webhooks do GitHub recomenda o uso de segredo, HTTPS com verificação SSL e tratamento do tipo de evento antes de executar uma ação.
Configure um segredo aleatório para o webhook e valide o cabeçalho X-Hub-Signature-256 com HMAC-SHA256 antes de disparar deploys, publicar conteúdo ou alterar dados. O GitHub detalha o processo na documentação de validação de entregas de webhook. Isso protege a integridade do payload e complementa o filtro de IP. Para entender o papel de uma API em integrações entre sistemas, veja também o guia da Pump sobre o que é uma API e quando uma empresa precisa de integração.
A atualização da allowlist resolve uma camada específica da conexão; não transforma a regra de firewall numa autenticação completa. Se a equipe também mantém workflows conectados ao repositório, este artigo sobre lockfiles para dependências do GitHub Actions cobre outro controle útil para reduzir mudanças inesperadas no pipeline.
Resumo prático
- Se há uma allowlist fixa para entregas GitHub, adicione os três prefixos e confirme o responsável pela regra.
- Se a regra é automatizada, atualize-a a partir do campo
hooksdo endpoint oficialGET /meta, preservando os endereços necessários a outros serviços. - Teste uma entrega e monitore os logs do proxy.
- Mantenha HTTPS, segredo e validação HMAC-SHA256; IP permitido não substitui essas verificações.
A alteração não exige que todos os projetos mudem seu código. Ela pede uma revisão objetiva de quem restringe a entrada dos webhooks por IP — e um processo que mantenha essa regra atualizada quando o GitHub mudar seus intervalos novamente.
