GitHub הוסיפה שלושה טווחי IP חדשים למשלוחי Webhook ב-github.com. ארגונים שמאפשרים כניסת Webhooks רק מרשימת CIDR קבועה צריכים לעדכן את חומת האש או את ה-allowlist; אחרת, אירועים תקינים עלולים להידחות.
הטווחים החדשים
הטווחים שנוספו לשדה hooks ב-Meta API של GitHub הם:
9.234.98.160/289.234.98.176/289.234.106.48/28
העדכון חל על משלוחי Webhook מ-github.com בכל התוכניות, כולל GitHub Enterprise Cloud.
מי צריך לפעול?
ההשפעה העיקרית היא על ארגונים שמתחזקים רשימת IP סטטית ב-WAF, בחומת אש, ב-load balancer או בשער API. אם הרשימה אינה כוללת את הטווחים החדשים, GitHub יכולה לשלוח אירוע מכתובת תקינה — אך התשתית בצד הלקוח תחסום אותו לפני שיגיע ליישום.
מי שמעדכן את הרשימה אוטומטית מתוך Meta API אינו נדרש לשינוי ידני, בתנאי שתהליך הסנכרון פועל ומעדכן בפועל את רכיב האכיפה.
מה כדאי לבדוק עכשיו?
- לזהות allowlists סטטיות בכל נקודות הכניסה שמקבלות Webhooks.
- להוסיף את שלושת הטווחים לצד הטווחים הקיימים — לא במקומם.
- להעדיף סנכרון אוטומטי מול השדה
hooksב-Meta API, עם בקרה על שינויי CIDR. - לבדוק משלוחי Webhook אחרונים ולחפש שגיאות חסימה, timeout או קודי 4xx/5xx חריגים.
- להמשיך לאמת חתימות של Webhooks באמצעות secret; allowlist של כתובות אינה תחליף לאימות קריפטוגרפי.
למה רשימת IP לבדה אינה מספיקה?
כתובת מקור מסייעת לצמצם תעבורה לא רצויה, אך היא אינה מוכיחה שהתוכן לא שונה או שהאירוע שייך לארגון שלכם. שכבת ההגנה הנכונה משלבת allowlist מעודכן, TLS ואימות חתימת ה-Webhook. כך גם טעות בתצורת הרשת וגם בקשה מזויפת אינן נשענות על מנגנון יחיד.
המלצה תפעולית
כדאי להפוך את עדכון הטווחים לתהליך מדיד: משיכה מתוזמנת מה-Meta API, השוואה לגרסה הקיימת, שינוי מבוקר של כללי הרשת והתראה אם הסנכרון נכשל. בנוסף, מומלץ להחזיק בדיקת בריאות שמוודאת שאירוע ניסוי מ-GitHub אכן מגיע למקבל ומעובד בהצלחה.
מקור: GitHub Changelog, 29 באוקטובר 2026.
צילום: Rafael Minguet Delgado / Pexels — דף המקור. רישיון Pexels Free מתיר שימוש באתר, בסושיאל ובשיווק.
