Als je server GitHub-webhooks alleen accepteert vanaf toegestane IP-adressen, voeg dan drie nieuwe prefixen toe aan de allowlist. Op 29 oktober 2026 maakte GitHub bekend dat er nieuwe bereiken voor leveringen aan github.com zijn toegevoegd aan het veld hooks van de Meta API. De wijziging geldt voor webhookleveringen aan github.com bij alle abonnementen, inclusief GitHub Enterprise Cloud.

Welke bereiken moet je toevoegen?
Voor een handmatige update noemt GitHub de volgende CIDR-prefixen:
9.234.98.160/289.234.98.176/289.234.106.48/28
Voeg ze toe naast de IP-adressen van GitHub die al zijn toegestaan en behoud de bestaande bereiken. Als de allowlist al via de Meta API wordt bijgewerkt, is een aparte wijziging voor deze prefixen niet nodig: de actuele lijst met webhookadressen wordt teruggegeven in het veld hooks. De documentatie van de Meta API waarschuwt dat de waarden in het voorbeeldantwoord alleen ter illustratie dienen; vraag voor een werkende configuratie de actuele gegevens rechtstreeks op.
Controleer hoe de allowlist wordt opgebouwd
Ga eerst na waar de lijst met toegestane adressen is ingesteld: in de netwerkfirewall van de applicatie, een reverse proxy, een cloudbeleid of een bedrijfsfirewall. Controleer vervolgens of het systeem de volledige set uit GET /meta bijwerkt, of alleen handmatig ingevoerde regels bewaart. Bevestig in het eerste geval dat het veld hooks wordt gesynchroniseerd; voeg in het tweede geval de drie prefixen toe zonder de bestaande te verwijderen.
De openbare gegevens van GET /meta zijn zonder authenticatie beschikbaar. GitHub raadt aan de allowlist regelmatig bij te werken, omdat de adressen van services kunnen veranderen. Haal voor automatisering het veld hooks uit het antwoord en vergelijk de volledige set met de lokale configuratie voordat je de netwerkregels toepast.
Wat controleer je na de update?
Controleer of de nieuwe CIDR-prefixen in de actieve configuratie staan en of de oude regels behouden zijn. Bekijk daarna het logboek met webhookleveringen en de netwerklogs om te zien of er na de wijziging verzoeken zijn geweigerd. Het is verstandig IP-filtering te combineren met andere controles: de aanbevelingen van GitHub omvatten HTTPS met certificaatcontrole, een webhookgeheim en controle van het gebeurtenistype voordat de verwerking begint.
GitHub adviseert om binnen 10 seconden met een 2xx-statuscode op een levering te reageren; langdurige verwerking kun je naar een wachtrij verplaatsen. De header X-GitHub-Delivery helpt de unieke levering bij te houden en beschermt tegen het opnieuw afspelen van verzoeken.
Voeg bij een statische allowlist alle drie de gepubliceerde prefixen handmatig toe. Als de configuratie automatisch wordt beheerd, werk dan het veld hooks bij via de Meta API en vergelijk de huidige waarden ervan regelmatig met de lokale lijst. Zo blijven nieuwe adressen niet buiten de regels die inkomende webhooks filteren.