Beyond the News
Sign in
Web DevelopmentCloud & InfrastructureDeployment & DevOpsDeveloper Tools Active dossier

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.

Reviewed and published by Lars Jansen Updated 4 min read
Comment
First published

Key details

  1. Announced October 29, 2026.
  2. New `hooks` prefixes: 9.234.98.160/28, 9.234.98.176/28, 9.234.106.48/28.
  3. These are additions to GitHub webhook delivery IP ranges, not replacements.
  4. Affects github.com webhook deliveries on all plans, including GitHub Enterprise Cloud.
  5. Static inbound allowlists must add the ranges to avoid possible delivery rejection.
  6. Meta API-driven automatically refreshed allowlists need no manual special-case update.
  7. GitHub has not claimed that webhook signatures or event schemas changed.
  8. No specific outage or exploitation incident was established.

What builders should take away

  1. Check whether your webhook ingress uses a static source-IP allowlist or automatically imports GitHub's Meta API `hooks` list.
  2. Add the three announced CIDRs alongside existing entries; don't replace the entire list with only these three.
  3. Verify delivery status after updating, especially for CI/deploy and billing/event-driven workflows.
  4. Validate `X-Hub-Signature-256` webhook signatures with a secret even when source-IP filtering is enabled.
  5. Consider scheduled Meta API synchronisation and alerting on webhook delivery failures.

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.

What to watch next

  • 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.

Still unclear

  • 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

Direct reading behind this dossier.

3 sources
GitHub Meta API
GitHub primary_live_api

Canonical `hooks` field for current webhook delivery CIDR ranges.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment
Continue reading