Um webhook pode deixar de funcionar mesmo quando o código do receptor não mudou. Em 29 de outubro de 2026, o GitHub anunciou três novas faixas de IP para entregas de webhooks de github.com, exigindo revisão de listas estáticas de endereços permitidos.
A atualização não muda o formato do payload nem exige recriar todos os webhooks. O risco aparece quando o servidor aceita apenas os endereços antigos: eventos legítimos podem ser recusados antes de chegar à aplicação, causando falhas em integrações e automações.
Três faixas CIDR que precisam entrar na lista estática
| Bloco divulgado | Uso |
|---|---|
| 9.234.98.160/28 | Entrega de webhook do github.com |
| 9.234.98.176/28 | Entrega de webhook do github.com |
| 9.234.106.48/28 | Entrega de webhook do github.com |
A nota oficial do GitHub afirma que os blocos se aplicam aos planos de github.com, inclusive GitHub Enterprise Cloud. Não confunda essas faixas com o endereço de saída de runners de Actions ou com endereços usados por outros serviços da plataforma.
Equipes que consultam periodicamente a Meta API e atualizam a allowlist automaticamente não precisam acrescentar esses blocos manualmente. Já configurações fixas em WAF, proxy, balanceador ou regras de rede devem ser revistas.
Risco técnico: uma regra de firewall desatualizada pode rejeitar eventos legítimos sem que a aplicação registre o pedido.
Como distinguir erro de rede de erro de código
Analise primeiro os registros do proxy e só depois os logs da aplicação.
- Verifique regras de CDN.
- Compare faixas CIDR vigentes.
- Monitore erros 403 e 5XX.
Passo a passo para conferir o campo hooks na Meta API
- Localize onde o tráfego HTTPS do webhook é filtrado: firewall, CDN, WAF ou reverse proxy.
- Consulte a resposta atual do endpoint público de metadados do GitHub.
- Compare o campo hooks com a allowlist efetivamente carregada no ambiente.
- Adicione os blocos ausentes sem retirar faixas ainda válidas.
- Faça um teste de entrega e monitore códigos HTTP e rejeições na borda.
A documentação da Meta API explica como obter os intervalos de endereços. O endpoint retorna outras categorias, como serviços de Git e API; usar indiscriminadamente todas as faixas ampliaria o escopo de confiança além do necessário.
Allowlist dinâmica precisa de validação, auditoria e rollback.
O que fazer quando a entrega retorna erro
Primeiro separe falhas de rede de falhas da aplicação. Um bloqueio na borda pode não gerar registro no serviço receptor; já um erro 500 indica que a requisição alcançou a aplicação, mas não foi processada corretamente. Logs do WAF e registros de entrega do webhook ajudam a identificar a camada afetada.
- Rejeição por IP: revisar a allowlist e o endereço de origem observado.
- Falha de TLS: conferir certificado e cadeia de confiança.
- Resposta lenta: confirmar processamento assíncrono e tempo de resposta.
- Erro de assinatura: validar segredo e corpo bruto recebido.
- Eventos perdidos: examinar histórico e redelivery no GitHub.
O GitHub recomenda responder rapidamente com código 2XX e colocar tarefas pesadas em fila. A orientação oficial de boas práticas também recomenda HTTPS e validação de segredo, porque permitir o IP correto não substitui autenticação da origem do evento.
É seguro usar somente os novos três blocos?
Não. A mudança adiciona intervalos à lista existente, sem afirmar que os anteriores deixaram de ser usados. Uma regra que mantém apenas os novos blocos pode interromper entregas originadas de endereços ainda ativos.
Para ambientes com múltiplos projetos, a revisão pode ser feita em duas etapas: primeiro identificar quais serviços expõem endpoints de webhooks ao público; depois localizar a regra de rede correspondente a cada endpoint. Não é suficiente atualizar a configuração de um ambiente de testes se a produção usa outro WAF. Equipes que terceirizam a borda para um provedor de CDN precisam confirmar se a alteração deve ocorrer no painel do fornecedor ou no firewall de origem.
O uso de listas dinâmicas também requer cautela. Uma rotina automática não deve aceitar qualquer conteúdo sem validação de formato, registro de mudanças e possibilidade de reversão. A política de segurança pode exigir revisão humana antes de aplicar alterações na produção. Quando a entrega falhar, diferencie ausência de requisição, bloqueio de IP, erro de autenticação e indisponibilidade da aplicação para não atribuir tudo à atualização anunciada.
- Exporte a configuração atual.
- Aplique a alteração controlada.
- Teste um evento real de webhook.
Por que a atualização dinâmica reduz incidentes futuros
A manutenção manual funciona em ambientes pequenos, mas depende de alguém acompanhar mudanças de infraestrutura. Uma rotina controlada que consulta a API, compara diferenças e aplica a configuração após validação reduz o risco de bloqueio silencioso.
A automação deve registrar quando a lista foi consultada, quais entradas mudaram e se o firewall aceitou a configuração. Em produção, é prudente testar primeiro em ambiente de homologação e manter um mecanismo de reversão para alterações inesperadas.
O panorama do GitHub Universe 2026 ajuda a contextualizar outras mudanças recentes da plataforma. Para webhooks, a prioridade operacional é atualizar a lista de IPs, verificar assinatura e acompanhar a taxa de entregas bem-sucedidas.
