GitHub Webhook IP Ranges: Meta API and Allowlist Guide

GitHub announced on October 29, 2026 that it added three IP ranges for github.com webhook deliveries: 9.234.98.160/28, 9.234.98.176/28 and 9.234.106.48/28. The current set appears in the hooks field of GitHub’s Meta API. Organizations with a static inbound allowlist must add the prefixes or risk rejecting legitimate deliveries.

The change affects github.com webhook delivery across plans

GitHub says the ranges apply to webhook deliveries on github.com, including GitHub Enterprise Cloud. A team that already refreshes its network rules from the Meta API does not need a one-off change, provided that automation is working and the returned prefixes are actually applied.

Self-hosted GitHub Enterprise Server has its own delivery path and configuration. Teams should identify the origin in use before copying cloud ranges into a firewall. Record the fetch time and resulting rule set so a failed refresh is visible rather than silently leaving stale access.

Static allowlists trade simplicity for maintenance risk

A hard-coded list can be appropriate for a tightly controlled environment, but GitHub’s range change demonstrates the operational cost: new senders may be blocked until every relevant firewall, load balancer or cloud security group is updated. Roll out the additions before removing anything and watch failed-delivery logs during the transition.

The Meta endpoint is unauthenticated and reports several service-specific address groups. Parse the hooks field rather than trusting an copied list or permitting every GitHub range. Validate the JSON shape, handle a failed fetch conservatively and avoid deleting the last known-good rules on a transient error.

An allowed source address does not authenticate a webhook payload

GitHub’s webhook guidance recommends validating the secret-based signature before processing a delivery. Source IP controls reduce unwanted network traffic, but addresses can change and infrastructure layers can obscure the connecting address. A signed payload establishes a separate integrity check tied to the configured secret.

Use a constant-time signature comparison, reject unsupported algorithms and keep secrets out of logs. Prevent replay or duplicate work by recording delivery identifiers where the operation is consequential. The receiver should also validate event type and repository or organization identity before changing production state.

Test from delivery history before declaring the migration complete

After changing network rules, use GitHub’s delivery history and redelivery controls to confirm the request reaches the intended endpoint and receives a successful response. A 2xx response only proves the receiver accepted the request; application logs should show that signature and authorization checks also passed.

For Canadian teams operating across regions, review every ingress layer rather than assuming one central firewall covers all endpoints. This is a reliability and security maintenance task, not evidence of a broader GitHub outage. The exact ranges should always be read from the current Meta API rather than from this dated article.

Sources and editorial method

We use the linked original statements and reports to distinguish documented facts from our analysis. Company announcements describe their authors’ plans and claims; they are not independent verification of future outcomes. This article is dated and will be revised if material evidence changes. Read our editorial standards and corrections process.

GitHub: webhook IP ranges added ↗ — Official October 29 change notice with the three CIDR prefixes and affected plans.
GitHub Docs: webhook delivery best practices ↗ — Official guidance on current IP ranges, signature validation, HTTPS and delivery handling.