# GitHub adds three webhook IP ranges — static firewall allowlists need updating GitHub's October 29 update adds three CIDR blocks to webhook delivery IPs. Teams using manually maintained inbound firewall allowlists need to include them to avoid rejecting legitimate GitHub events; dynamically refreshed Meta API lists already include the new ranges. Three new GitHub webhook CIDR blocks can break deliveries to tightly firewalled endpoints unless static allowlists are updated. - Status: Active - Published: 2026-10-30T18:01:35+13:00 - Updated: 2026-10-30T18:01:35+13:00 - Categories: Web Development, Cloud & Infrastructure, Deployment & DevOps, Developer Tools - Tags: GitHub, IP allowlisting, network security, webhooks - Canonical HTML: https://beyondthe.news/dossiers/github-webhook-delivery-new-cidr-ranges-meta-api-october-2026 ## What changed On October 29, 2026, GitHub announced three additional IPv4 CIDR prefixes for webhook deliveries on github.com, exposed in the `hooks` array of the GitHub Meta API: 9.234.98.160/28, 9.234.98.176/28 and 9.234.106.48/28. The additions apply across all GitHub plans, including Enterprise Cloud. GitHub instructs operators with static inbound webhook IP allowlists to add these ranges alongside existing prefixes. Teams already refreshing allowlists from the Meta API need no special change. ## Why it matters Webhooks often trigger CI, deployments, issue synchronisation and customer-facing integrations. A receiving firewall that permits only older GitHub webhook CIDRs may reject legitimate deliveries from the newly added ranges, creating silent operational gaps or failed automations. The affected group is narrow but important: operators who deliberately restrict inbound webhook traffic by source IP and maintain that list manually. GitHub's notice describes an allowlist update, not a change to webhook payloads, secrets or signatures, and does not establish any confirmed production outages. ## The three new CIDR prefixes GitHub lists 9.234.98.160/28, 9.234.98.176/28 and 9.234.106.48/28. These are additions, not replacements. They appear in the `hooks` field returned by the GitHub Meta API. Operators should compare the current API list with the firewall or reverse-proxy allowlist protecting each webhook endpoint and add the missing prefixes without deleting existing ranges. ## Who needs to act Manual IP allowlists on a cloud firewall, WAF, load balancer or reverse proxy may need a configuration change. Integrations that already synchronise the `hooks` array from the GitHub Meta API do not need a special update for these three prefixes. The announcement applies to webhook deliveries from github.com across plans, including Enterprise Cloud; it does not establish equivalent changes for self-hosted GitHub Enterprise Server. ## Don't rely on source IP alone GitHub's webhook security guidance recommends validating webhook delivery signatures using a configured secret. Source IP allowlisting is an additional network control, not a substitute for payload authentication. After updating, operators should test delivery from GitHub, monitor failed/retried deliveries and consider automating regular Meta API allowlist refreshes to reduce future maintenance surprises. ## Key details - Announced October 29, 2026. - New `hooks` prefixes: 9.234.98.160/28, 9.234.98.176/28, 9.234.106.48/28. - These are additions to GitHub webhook delivery IP ranges, not replacements. - Affects github.com webhook deliveries on all plans, including GitHub Enterprise Cloud. - Static inbound allowlists must add the ranges to avoid possible delivery rejection. - Meta API-driven automatically refreshed allowlists need no manual special-case update. - GitHub has not claimed that webhook signatures or event schemas changed. - No specific outage or exploitation incident was established. ## Builder takeaways - Check whether your webhook ingress uses a static source-IP allowlist or automatically imports GitHub's Meta API `hooks` list. - Add the three announced CIDRs alongside existing entries; don't replace the entire list with only these three. - Verify delivery status after updating, especially for CI/deploy and billing/event-driven workflows. - Validate `X-Hub-Signature-256` webhook signatures with a secret even when source-IP filtering is enabled. - Consider scheduled Meta API synchronisation and alerting on webhook delivery failures. ## What to watch - Further additions or removals from the GitHub Meta API `hooks` range list. - Whether GitHub documents a transition period or reports webhook delivery failures. - Changes to webhook delivery infrastructure or network allowlisting recommendations. ## Uncertainties - GitHub did not publish a firm cutover date or report confirmed failures from these prefixes in the announcement. - Actual impact depends on each receiving network's firewall configuration and whether it already refreshes IP ranges. - This announcement concerns github.com; no equivalent change to self-hosted Enterprise Server was established. ## Sources - [Webhook IP ranges added to the Meta API](https://github.blog/changelog/2026-10-29-webhook-ip-ranges-added-to-the-meta-api/) — GitHub Changelog · primary_operational_announcement · 2026-10-29T00:00:00+13:00. Three exact CIDR prefixes, affected scope and static versus dynamic allowlist guidance. - [GitHub Meta API](https://api.github.com/meta) — GitHub · primary_live_api. Canonical `hooks` field for current webhook delivery CIDR ranges. - [Best practices for using webhooks](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks) — GitHub Docs · primary_security_documentation. Webhook signature validation, delivery handling and operational recommendations.