מתקפת הסייבר הענקית שהפכה את GitHub Actions לבוטנט מבוזר

583 קבצי Workflow זדוניים

ליבת המתקפה לא הייתה בקוד ה-PHP עצמו; הספריות נותרו תמימות ללא הוקי התקנה או פעילות רשת זדונית . במקום זאת, התוקפים החדירו 583 קבצי GitHub Actions workflow זדוניים (קובצי .github/workflows/*.yml) לתוך מאגרי המקור של המפתח. כל גרסת חבילה מושפעת הכילה בין 55 ל-62 קובצי workflow כאלה . GitHub Actions workflows הם קובצי YAML המגדירים משימות אוטומטיות, כמו הרצת בדיקות או פריסת קוד. התוקפים ניצלו את תשתית האוטומציה הלגיטימית הזו למטרותיהם.

המנגנון הזדוני

ברגע שעותק (fork) או העתק של המאגר שנפרץ הפעיל workflow (למשל, באירוע push), קובץ ה-.yml הזדוני הורה לשרת Ubuntu המארח של GitHub לבצע את הפעולות הבאות :

1. זיהוי ארכיטקטורת המעבד של השרת.
2. הורדת payload לסריקה וניצול משרת פיקוד ושליטה (C2) בכתובת ה-IP 43[.]228[.]157[.]68.
3. סריקת האינטרנט לאיתור מערכות המפעילות שירותי cPanel ו-WHM.
4. ניצול אוטומטי של המערכות שזוהו באמצעות הפגיעות המפורטת להלן.
5. הוצאת הנתונים הגנובים בחזרה לשרת ה-C2.

זה הפך למעשה כל workflow שהופעל לצומת סריקה וניצול, תוך שימוש בתשתית החינמית של GitHub כפלטפורמה מבוזרת למתקפה .

הפגיעות: CVE-2026-41940

מטרת המתקפה הייתה CVE-2026-41940, פגיעות קריטית ב-cPanel וב-WebHost Manager (WHM) .

• סוג: עקיפת אימות לפני הזדהות (Pre-authentication authentication bypass) .
• חומרה: CVSS 9.8 (קריטי) .
• גורם שורש: פגיעות הזרקת CRLF (Carriage Return Line Feed) במנגנון אימות הבסיסי של cpsrvd . תוקף לא מאומת יכול היה לשלוח כותרת Authorization מהונדסת המכילה תווי שורה חדשה גולמיים. זה איפשר לו להזריק מאפיינים שרירותיים לקובץ סשן, כגון user=root ו-hasroot=1, ובכך להעניק לו גישת ניהול מלאת הרשאות (root) לממשק WHM ללא סיסמה תקפה .
• תאריך תיקון: cPanel פרסמה עדכון אבטחה ב-28 באפריל 2026 . משמעות הדבר היא שלתוקפים היה תיקון עובד לניתוח במשך מספר חודשים לפני שהחלה מתקפה זו.

מה נגנב

לאחר שהניצול הצליח בשרת cPanel/WHM שנפרץ, ה- payload שלאחר הניצול תוכנן לאסוף מגוון רחב של אישורים וסודות. היעדים העיקריים כללו :

• אישורי ענן: מפתחות Amazon Web Services (AWS).
• טוקנים לניהול גרסאות: טוקנים של GitHub, טוקנים של GitLab.
• מפתחות API: OpenAI, מפתחות Google API.
• עיבוד תשלומים: מפתחות Stripe.
• אישורי שירות דוא"ל: (למשל, Mailgun, SendGrid).
• תשתית: מפתחות פרטיים של SSH, אישורי מסד נתונים.
• נתוני תצורה: תצורות Git מרוחקות.

גניבת מגוון כה רחב של אישורים מעידה על חטיפה אופורטוניסטית וחסרת הבחנה של כל טוקן גישה בעל ערך שנמצא בשרת שנפרץ .

היקף המתקפה: אלפי מאגרים נוספים נפרצו

583 קבצי ה-workflow בעשר חבילות Packagist היו רק תגלית ראשונית. על ידי מעבר לאינדיקטורים של התוקף, כגון דומיין Callback DNSHook משותף ודפוסי שימוש חוזר בקוד, חוקרים חשפו פעולה רחבה הרבה יותר :

• כ-6,100 קבצי workflow היו מקושרים ישירות לאותה תשתית תוקף ראשונית .
• כ-15,000 עד 16,000 קבצי workflow ב-GitHub נמצאו תואמים לדפוסים קשורים מהמתקפה .

הפער העצום הזה מצביע מאוד על כך שהתוקפים פרצו לחשבונות מפתחים ומאגרים רבים נוספים מעבר לחשבון dinushchathurya הבודד . המתקפה לא הייתה כשל נקודתי בודד, אלא פעולה מתואמת ורב-חשבונות. The Hacker News דיווח על מתקפת שרשרת אספקה נפרדת ומוקדמת יותר על Packagist במאי 2026, שפגעה ב-8 חבילות עם אלמנטים זדוניים קשורים , מה שמדגיש עוד יותר את הפגיעות של המערכת האקולוגית.

סיכון מתמשך: מדוע המתקפה ככל הנראה עדיין פעילה

המתקפה מהווה איום מתמשך מכיוון שהתשתית של התוקף לא נוטרלה לחלוטין. ייתכן שהמתקפה תימשך באמצעות :

• עותקים מפוצלים (Forks) ומראות (Mirrors): קבצי workflow זדוניים עשויים להתמיד בעותקים מפוצלים או משועתקים של המאגרים שנפרצו.
• תמונות מצב במטמון: המטמון של GitHub עצמו עשוי להכיל את גרסאות ה-workflow הזדוניות.
• אישורים גנובים: האישורים שכבר הוצאו נותרו ברשות התוקף, וניתן להשתמש בהם לתנועה רוחבית או למתקפות עתידיות.
• תשתית C2 שורדת: ייתכן ששרת ה-C2 (43[.]228[.]157[.]68) עדיין פעיל ומקבל נתונים באופן פעיל .

בעוד שחשבון Packagist של המפתח המקורי הושעה, היקף קבצי ה-workflow התואמים (עד כ-16,000) פירושו שלמבצע יש טביעת רגל רחבה שקשה לחסל לחלוטין .

פעולות הגנה נדרשות

בהתבסס על הניתוח שפורסם, ארגונים ומפתחים צריכים לנקוט בפעולות הבאות באופן מיידי :

1. תיקון cPanel/WHM מיידי: CVE-2026-41940 תוקנה ב-28 באפריל 2026. כל התקנת cPanel או WHM (גרסאות אחרי 11.40) שאינה מעודכנת ניתנת לניצול בקלות על ידי תוקפים מרוחקים לא מאומתים. זהו הצעד החשוב ביותר.
2. בדיקת כל Workflows של GitHub Actions: סקור כל קובץ workflow YAML במאגרים שלך, במיוחד אלה ש:
   • מורידים ומבצעים קבצים בינאריים חיצוניים.
   • מבצעים חיבורי רשת יוצאים.
   • פועלים על טריגרים של push או workflow_dispatch ללא בדיקה ידנית.
   • קיימים בענפי פיתוח או תכונה שעשויים להיות מסונכרנים אוטומטית על ידי מנהל חבילות.
3. סיבוב (Rotation) כל האישורים החשופים: הנח שכל אישור שהיה קיים בשרת cPanel/WHM שנפרץ נגנב. זה כולל, אך לא מוגבל ל:
   • מפתחות ספק ענן (AWS, GCP, Azure).
   • טוקני API (OpenAI, Google, Stripe).
   • מפתחות SSH וסיסמאות מסד נתונים.
   • טוקנים לניהול קוד מקור (GitHub, GitLab).
4. בדיקת אינדיקטורים ידועים לפגיעה (IOCs): חפש ביומנים שלך חיבורי רשת לכתובת ה-IP של ה-C2 של התוקף (43[.]228[.]157[.]68) ולדומיין ה-Callback DNSHook הידוע .
5. הקשחת מאגרים וניהול חבילות:
   • הפעל כללי הגנה על ענפים (branch protection rules) בכל ענפי הפיתוח.
   • דרוש commits חתומים.
   • הימנע מסינכרון אוטומטי של רישומי חבילות (כמו Packagist) ישירות מענפי מאגר ללא שלב בדיקה .
6. בדיקת גרסאות פיתוח ב-Packagist: בעת ביקורת תלויות (dependencies), בדוק במיוחד גרסאות פיתוח (dev-master, dev-main) לאיתור קבצי .github/workflows/ לא צפויים, מכיוון שקוד PHP עצמו עשוי להיות נקי בעוד שהמתקפה חיה כולה בתצורת ה-CI/CD .