GitHub adds three webhook delivery IP ranges to its Meta API
Victoria Shinder1 min readGitHub said on 29 October that webhook deliveries from github.com can now come from three additional address ranges, and that the hooks field of its Meta API (https://api.github.com/meta) has been updated to include them. The new prefixes are 9.234.98.160/28, 9.234.98.176/28 and 9.234.106.48/28.
The change applies across all plans, GitHub Enterprise Cloud included. For anyone who already pulls the list from the Meta API on a schedule, nothing needs doing. The risk is for a static allowlist on a firewall, reverse proxy or security group that was copied by hand at some point: GitHub's advice is to add the three prefixes alongside the existing ones, or deliveries arriving from the new addresses will be rejected.
The changelog entry does not say when deliveries from the new ranges begin, and it does not announce the removal of any existing range.
What it means
A rejected webhook usually fails quietly: GitHub records the failed delivery and retries for a while, while the CI job, deployment or bot on the receiving end simply never fires. If a pipeline that depends on webhooks starts missing events, the Recent Deliveries tab of the webhook settings will show the failed attempts. The durable fix is to generate the allowlist from the API rather than maintain it by hand, and to verify the signature header on each delivery, which does not depend on source addresses at all.