GitHub's New Webhook IP Ranges: An Allowlist Is Not a Signature

Your app stops receiving GitHub events. An AI assistant spots a changed network range and suggests opening the webhook endpoint to more traffic. That may solve the connection problem. It does not answer whether your app should trust each message that arrives.

This article was prepared with AI assistance. The examples below are proposed review exercises, not reports of a production system I tested.

On October 29, GitHub announced additional webhook IP ranges. Teams maintaining static allowlists need to include the additions; systems already refreshing from the Meta API do not need a separate change for this update. The announcement applies to webhook deliveries on github.com, including Enterprise Cloud.

The practical lesson for a first app is bigger than updating a list. Separate three questions: can this request reach the handler, is the body authentic, and is this event allowed to trigger the requested action?

Three checks, three different answers

Imagine a small app that creates a preview task when a repository receives a pull request. This is a hypothetical design, not a description of an existing service.

Its network filter decides which connections can reach the webhook route. Its signature check decides whether the received bytes match a message authenticated with the configured shared secret. Its application logic decides whether this repository, event, and action belong in the preview workflow.

A pass at the first step should not silently count as a pass at the other two.

For example, a correctly signed event from the wrong repository is still the wrong input for that project's preview workflow. And a delivery from an allowed network address with an invalid signature should not create a task merely because it got through the firewall.

That separation is useful when reviewing AI-generated code: ask the assistant to point to the exact check that answers each question. My $3 Starter Prompts offer a guided starting point for that kind of review, but you can use the exercise below without buying anything.

Fix the network layer without removing the next check

GitHub's announcement lists three added CIDR ranges: 9.234.98.160/28, 9.234.98.176/28, and 9.234.106.48/28. Treat those as the dated announcement, not a permanent complete allowlist.

The Meta API documentation describes the endpoint used to retrieve GitHub's address information. For webhook filtering, use the current hooks collection. A copied documentation example is not a promise that your firewall has today's complete list.

For a practice project, I would ask for a short operational note with four facts: where the configured list lives, who updates it, when it was last refreshed, and how a rejected connection becomes visible. The note should not contain secrets or private payloads.

If events disappear again, that gives you a specific first check. Did the request reach your application at all? If not, changing the signature validator will not repair the network path. Keep the layers separate while investigating.

Validate the bytes you actually received

GitHub's signature-validation guide uses HMAC-SHA256 with a webhook secret and the X-Hub-Signature-256 header. Validation needs the original payload bytes, with a constant-time comparison rather than ordinary string equality. Its JavaScript example uses @octokit/webhooks.

This is where I would resist a convenient-looking shortcut. Parsing JSON and then serializing it again can change the representation. A semantically equivalent object is not necessarily the exact byte sequence that was signed. Review middleware ordering so the verifier gets the original body before transformations.

Prefer a maintained validation library and the framework's documented raw-body handling over an improvised cryptography helper. Then test the integration around that library. A correct dependency cannot compensate for passing it the wrong body or selecting the wrong secret.

Never put the secret in a screenshot, article comment, log message, or URL while debugging. You need evidence that verification succeeded or failed, not a copy of the credential that makes it work.

Write the rejection cases before the happy path

Here is the review exercise I would give an AI assistant for the hypothetical preview app:

1. A valid test delivery from the intended repository creates exactly one preview task.
2. A request with no signature creates no task.
3. A request whose body changes after signing creates no task.
4. A correctly signed event for a different repository creates no task for this project.
5. An event with an unsupported action is ignored without starting preview work.
6. Reprocessing the same accepted delivery does not create a second task.

These are proposed acceptance criteria. A generated test file is not evidence that they passed. Run the tests and inspect both the result and the side effect, including the absence of a task in rejection cases.

For the final case, two simultaneous workers are more revealing than two sequential requests. Ask what prevents both workers from deciding that the same delivery is new. The answer should identify the durable uniqueness check or transaction, not only a comment saying duplicates are handled.

A successful response needs a precise meaning

GitHub's webhook best practices recommend checking event type and action, responding within ten seconds, and considering asynchronous processing. They also explain that a requested redelivery keeps the original X-GitHub-Delivery value.

For the example app, I would make an acknowledgment mean the accepted work was durably recorded, not that every downstream step finished. Otherwise a fast success response could hide lost work, or a slow build could make delivery appear to fail even though processing started.

That is a design decision to test, not a reason to build a large queueing system for every toy project. Keep the implementation small enough to explain. Document what is stored before acknowledgment and what happens if the worker stops afterward.

The next useful question

Open one webhook handler and ask: which line admits the request, which verifies its contents, and which authorizes the side effect? If the answer is one vague statement that the request is trusted, the review is not finished.

For a guided first build, the $3 Starter Prompts help turn questions into concrete tasks. The $9 standalone e-book provides the organized path from idea through testing and publication; the $10 learning bundle includes both resources.

Bootcamp Bundle (Review Radar) is coming soon, with a public preview and email waitlist; checkout remains closed.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim