גל החולשות שה-AI חושף: PHP, GitLab ו-Node.js ביום אחד, והמדריך המעשי לארגונים

ביום רביעי, 21 באוקטובר 2026, מנהלי אבטחת מידע בישראל ובעולם קיבלו בתוך כמה שעות ארבע התרעות שכל אחת מהן לבד הייתה מצדיקה ישיבת חירום. שתי פרצות קריטיות בשפת PHP, שעליה רצים רוב אתרי האינטרנט בעולם. עשר חולשות ב-Node.js. חולשה בדירוג חומרה מקסימלי ב-GitLab. וקוד זדוני שהוחדר לגרסה רשמית של LiteLLM, ספרייה שמחברת אפליקציות למודלי AI.

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

• מה קרה: ב-21 באוקטובר פורסמו תיקונים לחולשות קריטיות ב-PHP, GitLab ו-Node.js, ונחשף קוד זדוני בגרסה 1.107.0 של LiteLLM.
• למה עכשיו: לפי Google, מספר החולשות שמתפרסמות בחודש הוכפל השנה, וחולשות שמוצאים כלי AI מובילות פי שניים יותר להשתלטות מרחוק.
• מה עושים: מלאי מעודכן של כל התוכנות והרכיבים, מקור התרעות אחד שמישהו אחראי לקרוא, כלל תעדוף פשוט, זמני תיקון מוגדרים מראש ותוכנית למקרה שבו אי אפשר לעדכן.
• הכי דחוף: כל שרת או ממשק ניהול שנגיש מהאינטרנט ורץ על PHP צריך עדכון או הגבלת גישה מיידית.

מה קרה ב-21 באוקטובר

הנה ארבע ההתרעות של אותו יום, עם מה שכל ארגון צריך לדעת עליהן:

PHP: הפרצה שנוגעת כמעט לכל ארגון

לפי הודעות האבטחה הרשמיות של PHP, שתי החולשות נמצאות במנוע של השפה עצמה, ולא בקוד של אתר מסוים. כלומר, גם אתר שנכתב בצורה מאובטחת לגמרי חשוף, כל עוד הוא רץ על גרסת PHP פגיעה. חוקרי Wiz הדגימו השתלטות מרחוק על WordPress, Drupal ו-Joomla בגרסאות העדכניות שלהם, וכתבו שכמעט כל גרסה של PHP מאז 5.4 מושפעת מלפחות אחת החולשות.

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

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

LiteLLM: התקפה על שרשרת האספקה של ה-AI עצמו

המקרה של LiteLLM שונה, והוא מזכיר שהסיכון לא מגיע רק מחולשות. לפי חוקרי Upwind, הקוד הזדוני לא הופיע בקוד המקור של הפרויקט אלא הוחדר בשלב בניית החבילה. הוא רץ אוטומטית עם עליית Python, הוריד קוד נוסף מהשרת של התוקף כל שעה, ושלח מפתחות וסיסמאות לדומיין שמתחזה לאתר הרשמי. מכיוון ש-LiteLLM רצה בדרך כלל בדיוק במקום שבו נמצאים מפתחות ה-API של מודלי ה-AI ומפתחות הענן, הנזק הפוטנציאלי גדול. הסרת הגרסה לא מספיקה: צריך להחליף כל מפתח שהיה זמין לה.

למה זה קורה עכשיו: AI מוצא חולשות בקצב חדש

חולשות PHP התגלו בעזרת כלי AI. לפי Wiz, החוקרים שלה השתמשו בסוכן ה-AI שלהם ובמודלים Gemini 4 Argon ו-GPT-5.6 Sol, לא רק כדי למצוא את החולשות אלא גם כדי להתאים את דרך הניצול לגרסאות ולהגדרות שונות. בניסוח שלהם, "With AI this is no longer a barrier". חברת Calif מצאה את אחת החולשות במסגרת יוזמת "Patch the Planet" של OpenAI, שמחפשת חולשות בתוכנות קוד פתוח.

המספרים מראים שזו מגמה רחבה:

• קבוצת מודיעין האיומים של Google מדווחת שמספר החולשות שמתפרסמות בחודש הוכפל השנה, מ-5,045 בינואר ל-10,740 באוגוסט 2026.
• לפי אותו דוח, מחצית מהחולשות שככל הנראה נמצאו על ידי AI מאפשרות הרצת קוד מרחוק, לעומת 26% מהחולשות האחרות. כלומר, ה-AI לא רק מוצא יותר חולשות, הוא מוצא את הסוג שתוקפים הכי רוצים.
• בעדכון האבטחה החודשי של אוקטובר תיקנה מיקרוסופט 1,413 חולשות, יותר מכל מה שתיקנה בכל 2025.
• לפי דוח ההגנה הדיגיטלית של מיקרוסופט לשנת 2026, הזמן החציוני מגילוי חולשה ועד שתוקפים הופכים אותה לנשק ירד הרבה מתחת ל-24 שעות, והשנה צפויה להסתיים עם כ-72 אלף חולשות מתועדות.
• קרן PHP מספרת שמאז יולי פרסמה 15 חולשות וטיפלה ביותר מ-100 דיווחים לא תקפים או כפולים, ומעריכה שכמות הדיווחים רק תגדל.

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

מה זה משנה עבור ארגונים

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

• הכמות: צוות IT שקורא כל התרעה ידנית פשוט לא יעמוד בקצב. צריך כלל תעדוף.
• המהירות: חלון הזמן בין פרסום חולשה לניצול שלה מתקצר לשעות או לימים. "נעדכן בחלון התחזוקה הבא" כבר לא מספיק לחולשות הקריטיות.
• העומק: החולשות נמצאות ברכיבי תשתית שכולם משתמשים בהם, כמו שפות תכנות, ספריות קוד פתוח וממשקי ניהול של ציוד רשת. ארגון יכול להיות חשוף בלי לדעת שהרכיב בכלל קיים אצלו.

המדריך המעשי: שבעה צעדים להתמודדות עם גל החולשות

צעד 1: דעו מה יש לכם

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

• כל מה שנגיש מהאינטרנט: אתרים, פורטלים, שרתי VPN, ממשקי ניהול של חומות אש ונתבים, שרתי דואר ומערכות פיתוח כמו GitLab.
• רכיבי התוכנה: באילו שפות, גרסאות וספריות כל מערכת משתמשת. לכל אפליקציה שאתם מפתחים כדאי להחזיק רשימת רכיבים (SBOM) שמתעדכנת אוטומטית.
• מה שהספקים מריצים בשבילכם: אתר שמתוחזק על ידי חברה חיצונית, מערכת SaaS או שרת אצל ספק אחסון. האחריות לוודא שעודכנו היא עדיין שלכם.
• כלי ה-AI: ספריות כמו LiteLLM, שרתי מודלים וסוכנים שעובדים עם מפתחות API. זה תחום חדש שלרוב לא נמצא ברשימות של צוות ה-IT. זו בדיוק הבעיה של Shadow AI: כלים שעובדים בארגון בלי שמישהו מנהל אותם.

צעד 2: איך יודעים שהתגלתה פרצה שנוגעת לכם

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

הכלל החשוב: מקור אחד מרכזי ובעל תפקיד אחד שאחראי לקרוא אותו כל יום, כולל בסופי שבוע כשמדובר בחולשה קריטית. התרעה שמגיעה לתיבה של כולם, בפועל לא מגיעה לאף אחד.

צעד 3: מחליטים מה לתקן קודם

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

1. האם המערכת הפגיעה נגישה מהאינטרנט?
2. האם אפשר לנצל את החולשה בלי הזדהות?
3. האם היא מאפשרת הרצת קוד או השתלטות על המערכת?
4. האם כבר יש קוד ניצול פומבי, או שהחולשה מופיעה בקטלוג KEV?

חולשה שעונה "כן" על שלוש או ארבע שאלות היא אירוע חירום. כך בדיוק נראית חולשת PHP הנוכחית: נגישה מהאינטרנט, בלי הזדהות, הרצת קוד, ועם קוד ניצול שכבר מתפרסם. גם Google ממליצה לתת עדיפות ראשונה לציוד קצה, כמו חומות אש ו-VPN, ולממשקי ניהול שנגישים בלי הזדהות.

צעד 4: קובעים זמני תיקון מראש

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

חשוב לא פחות: להחליט מי מאשר עדכון חירום מחוץ לחלון התחזוקה, ומי רשאי להחליט להוריד שירות מהאוויר. כשהשאלה הזאת עולה לראשונה בשתיים בלילה, מאבדים שעות.

צעד 5: מה עושים כשאי אפשר לעדכן

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

• להוריד את השירות מהאוויר עד שיהיה אפשר לעדכן. זה כואב, אבל לפעמים זו האפשרות האחראית.
• להגביל את הגישה: לחסום גישה מהאינטרנט, או לאפשר אותה רק מכתובות IP מוכרות, דרך VPN או מאחורי מערכת הזדהות.
• להפעיל הגנות ביניים: חוקי WAF, הגדרות שמבטלות את הרכיב הפגיע ומעקפים שהיצרן פרסם. רק חשוב לזכור שבחולשת PHP, למשל, היצרן הבהיר שהמעקפים חלקיים בלבד.
• להגביר את הניטור על המערכת עד לעדכון, כדי לזהות ניסיון ניצול מוקדם ככל האפשר.

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

צעד 6: מגינים על שרשרת האספקה

המקרה של LiteLLM מראה שגם תוכנה שמגיעה ממקור רשמי יכולה להיות זדונית. כמה הרגלים מצמצמים מאוד את הסיכון:

• לנעול גרסאות: להתקין גרסאות מוגדרות מראש ולא "הכי חדשה" אוטומטית, ולהשתמש בקובצי נעילה (lockfiles).
• לא למהר לגרסה שיצאה עכשיו: השהיה של כמה ימים לפני אימוץ גרסה חדשה של ספרייה, כשאין צורך אבטחתי דחוף, נותנת לקהילה זמן לגלות בעיות.
• להחזיק מפתחות בכספת: מפתחות API וסיסמאות לא שמורים בקבצים או במשתני סביבה פתוחים, אלא בכלי לניהול סודות, עם הרשאות מינימליות.
• לנטר תעבורה יוצאת: שרת שמתחיל לפתע לפנות לדומיין לא מוכר הוא סימן אזהרה מוקדם.

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

צעד 7: מתכוננים לאירוע אמת

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

• תוכנית תגובה כתובה: מי מחליט, מי מבצע, מי מדבר עם ההנהלה, הלקוחות והרגולטור. עמוד או שניים מספיקים, בתנאי שכולם מכירים אותם.
• אנשי קשר זמינים: מספרי טלפון של מנהל אבטחת המידע, ספקי התוכנה, ספק האחסון, חברת תגובה לאירועים ויועץ משפטי. כשהמערכות למטה, המספרים צריכים להיות גם מחוץ להן.
• גיבויים מנותקים: גיבוי שתוקף לא יכול להגיע אליו, ובדיקה תקופתית שבאמת אפשר לשחזר ממנו.
• תרגיל שולחני פעם ברבעון: לקחת התרעה אמיתית, כמו PHP של השבוע, ולשאול "מה היה קורה אצלנו". רוב הפערים מתגלים כבר בחצי השעה הראשונה של התרגיל.
• חובת דיווח: לבדוק מראש מתי אירוע מחייב דיווח לרשות להגנת הפרטיות, לרגולטור שלכם או ללקוחות, ובתוך כמה זמן.

איך יודעים שכבר נפרצתם

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

• יומני שרת: לפי Wiz, ניסיונות לנצל את חולשת PHP יכולים להיראות כבקשות multipart חריגות שאחריהן שגיאות זיכרון, רצף של שגיאות 500, עוגיות PHPSESSID גדולות או משובשות, ותהליכי PHP שקורסים ועולים מחדש בלי הסבר.
• קבצים ותהליכים חדשים: קבצים שלא אמורים להיות בתיקיות האתר, משתמשים חדשים ומשימות מתוזמנות שלא הוגדרו על ידכם.
• תעבורה יוצאת: חיבורים מהשרת לכתובות לא מוכרות, במיוחד מתהליכים כמו PHP או Python.
• מפתחות וסיסמאות: אם יש ספק, מחליפים. במקרה של LiteLLM זו לא המלצה אלא חובה: כל מפתח שהיה זמין לסביבה הפגיעה נחשב חשוף.

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

צ'קליסט ל-48 השעות הקרובות

• לאתר כל שרת שרץ על PHP, כולל אתרי WordPress, Drupal ו-Moodle, ולעדכן לגרסאות המתוקנות. גרסאות 8.1 ומטה צריכות שדרוג.
• לשאול כל ספק של ציוד רשת ואבטחה אם ממשק הניהול של המוצרים שלו פגיע, ולוודא שאף ממשק ניהול לא נגיש מהאינטרנט.
• לעדכן שרתי GitLab בניהול עצמי.
• לעדכן Node.js בשרתים ובאפליקציות לגרסאות המתוקנות, ולבנות מחדש קונטיינרים.
• לבדוק אם LiteLLM 1.107.0 הותקנה אי פעם, כולל בסביבות פיתוח ובצנרת ה-CI, ואם כן, לבודד ולהחליף את כל המפתחות.
• לוודא שספקים חיצוניים שמתחזקים אתרים ומערכות בשבילכם ביצעו את העדכונים, ולבקש אישור בכתב.

להשתמש ב-AI גם בצד המגן

אותם כלים שמוצאים חולשות זמינים גם לכם. ארגונים יכולים להשתמש ב-AI כדי לסרוק את הקוד שלהם לפני שהוא עולה לאוויר, לסכם ולתעדף את מבול ההתרעות, להתאים אוטומטית התרעות למלאי הנכסים, ולכתוב טיוטות של תיקונים לבדיקה אנושית. גם Google ממליצה לשלב סקירת קוד מבוססת AI לפני שחרור גרסה. לפי קרן PHP, גם הצוות שלהם משתמש בכלי AI כדי לבדוק דיווחים ולקבץ דיווחים עם אותו שורש, אבל כל החלטה וכל תיקון נעשים על ידי אנשים. זה האיזון הנכון: AI מאיץ, בני אדם מחליטים.

מי שמכניס כלים כאלה צריך לנהל גם אותם: אילו כלים מאושרים, לאיזה מידע הם ניגשים ומי אחראי עליהם. ערכת מדיניות ה-AI שלנו עוזרת לבנות את זה בצורה מסודרת.

מה זה אומר לארגון שלכם

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

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

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