GitHub adds 48 webhook IP addresses: an allowlist still needs signatures
A pull request opens, but the deployment bot stays silent. Looking only at application code can hide a simpler explanation: the request never passed the receiving firewall. GitHub’s October 29 announcement adds webhook delivery ranges, making the inbound network path the first place to examine in this particular change.
Three additional ranges belong on the receiving side
The new CIDRs are 9.234.98.160/28, 9.234.98.176/28 and 9.234.106.48/28. They cover webhook deliveries from github.com on every plan, including GitHub Enterprise Cloud. If you maintain a static allowlist, add them alongside the existing webhook ranges rather than replacing the old entries.
Each /28 contains 16 addresses, for 48 in total. The image below shows an actual local calculation with Python’s ipaddress module. This counts addresses in the prefixes, not accounts or delivery servers. GitHub says no separate change is needed if your allowlist already stays current through the hooks field returned by GET /meta.
Network admission and signatures answer different questions
An allowlist decides which source networks may reach the receiver. Use hooks for this purpose; actions describes a different path involving Actions runners. A deployment service receiving events and a CI job calling an external API do not share the same network direction merely because both involve GitHub.
After admission, verify X-Hub-Signature-256 with the secret configured for that webhook. GitHub produces an HMAC-SHA256 signature from the secret and payload. Calculate the expected value from the original request bytes and compare it with a constant-time facility such as hmac.compare_digest or crypto.timingSafeEqual. An allowed source address is no reason to skip this check.
Equivalent JSON can still mean different bytes
Parsing {"action":"opened"} and serializing it as {"action": "opened"} introduces a space. The JSON meaning survives; the original signature may not. Our local example uses a public demonstration secret: identical bytes produce True, while the extra space produces False. It is a locally executed example, not an observed GitHub webhook delivery.
Capture the raw body before transformations. If verification fails, examine whether a proxy or framework changed the body. Putting a secret in the payload URL would create another disclosure path instead of solving the problem. Keep it in secure server configuration and use it for verification there.
A recovered delivery should not repeat completed work
After restoring connectivity, inspect failed deliveries and redeliver what needs recovery. Track processing with X-GitHub-Delivery. A requested redelivery retains the original ID, so distinguish successfully completed work from work that failed and can resume. Dropping every previously seen ID could also discard the recovery you intended to perform.
GitHub recommends a 2XX response within ten seconds and a queue for longer processing. Connect signature verification to durable acceptance and retryable processing state. The announcement starts with three CIDRs, but tracing arrival, validation and completion as one path explains why an apparently quiet bot may need attention outside its application code.