החולשה הייתה שם שנים. ה-AI שינה את המשוואה. האם ניהול הסיכונים שלכם מוכן?

חולשות האבטחה הקריטיות שהתגלו ב-PHP באוקטובר 2026 ממחישות שינוי משמעותי בעולם הסייבר: בעיות שבעבר היה מורכב מאוד להפוך למתקפה מעשית עשויות להפוך לנגישות יותר בעזרת בינה מלאכותית. בעידן שבו אי אפשר לתקן את כל החולשות או למנוע את כל האיומים, אני מאמין שניהול סיכונים חכם, ניתוח השפעה עסקית (BIA) ותיעדוף נכון הופכים לחשובים מאי פעם.

חולשה שהתגלתה עכשיו, אבל הייתה שם הרבה קודם

ב-21 באוקטובר 2026 פורסמו תיקונים לשתי חולשות אבטחה קריטיות במנוע PHP, שזוהו כ-CVE-2026-109618 ו-CVE-2026-109619 וקיבלו ציון חומרה של 9.2 במדד CVSS.

החולשות עלולות לאפשר, בתנאים מסוימים, הרצת קוד מרחוק ללא צורך בהזדהות (Remote Code Execution), ובחלק מתרחישי הניצול גם חשיפת מידע רגיש מתוך זיכרון התהליך.

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

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

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

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

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

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

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

ה-AI לא בהכרח יוצר את החולשה. הוא משנה את היכולת לנצל אותה

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

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

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

אבל כלי AI מתקדמים משנים בהדרגה את התמונה.

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

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

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

אבל מבחינתי, המשמעות רחבה הרבה יותר מהמקרה הספציפי.

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

המשמעות היא שחולשות שבעבר נחשבו קשות מאוד לניצול עשויות להפוך לרלוונטיות מהר יותר.

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

מה ההבדל בין חולשת אבטחה לבין מסלול ניצול מעשי?

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

חולשת אבטחה (Vulnerability) היא פגם בתוכנה, במערכת, בתצורה או בתהליך, שעלול לאפשר פגיעה באבטחת המידע.

מסלול ניצול מעשי (Practical Exploitation Path) הוא רצף התנאים והאפשרויות שמאפשר להפוך את אותה חולשה לפגיעה ממשית, כמו גישה בלתי מורשית למידע, שיבוש פעילות או הרצת קוד על מערכת.

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

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

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

ולמה זה חשוב למנהלי אבטחת מידע?

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

AI עשוי לשנות במהירות את אחד המשתנים המרכזיים במשוואה הזאת: עד כמה קשה להפוך חולשה קיימת למתקפה מעשית.

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

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

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

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

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

חלק מהחולשות עדיין אינן ידועות. חלקן ידועות אך טרם תוקנו. אחרות תלויות בתנאים שלא תמיד ניתן להעריך מראש.

ובמקביל, תוקפים עשויים להמשיך לפתח יכולות חדשות לניצול חולשות קיימות.

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

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

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

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

לא כל חולשה קריטית מייצרת את אותו סיכון עסקי

נניח ששתי מערכות בארגון משתמשות באותה גרסה פגיעה של PHP.

המערכת הראשונה היא אתר תדמית, שאינו כולל נתוני לקוחות או שירותים עסקיים חיוניים.

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

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

אבל ההשלכות העסקיות של פגיעה בהן יכולות להיות שונות לחלוטין.

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

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

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

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

ופה בדיוק נכנס לתמונה ה-BIA.

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

Business Impact Analysis, או BIA, הוא תהליך שנועד לזהות את התהליכים העסקיים החיוניים ולבחון כיצד פגיעה בהם תשפיע על הארגון.

באופן מסורתי, BIA שימש בעיקר לתכנון המשכיות עסקית והתאוששות מאסון.

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

גם NIST, במסמך IR 8286D המעודכן, מתייחס ל-BIA ככלי שמאפשר להבין את ההשפעה האפשרית של פגיעה במשימות הארגון ובנכסים התומכים בהן, ובכך לסייע בתיעדוף סיכוני אבטחת מידע.

ניתוח BIA צריך לעזור להנהלה לענות על שאלות בסיסיות:

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

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

כי כאשר מתגלה חולשה קריטית, לא תמיד יש זמן להתחיל ללמוד מחדש את הארגון.

כשהאיום מתפתח בשעות, הארגון חייב להגיע מוכן

אירוע PHP ממחיש את הפער שעלול להיווצר בין מהירות התפתחות האיום לבין מהירות קבלת ההחלטות בארגון.

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

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

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

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

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

איך נראה ניהול סיכוני סייבר חכם בעידן ה-AI?

אני מאמין שהגישה הנכונה צריכה לשלב כמה תהליכים משלימים.

סקר סיכונים שמתעדכן בהתאם לשינויים

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

סקר פערים ובחינת הבקרות הקיימות

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

BIA שמחובר לתהליכי קבלת ההחלטות

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

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

המטרה אינה להפיק עוד מסמך, אלא ליצור בסיס לתיעדוף ולקבלת החלטות בזמן אמת.

תיעדוף חולשות על בסיס סיכון אמיתי

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

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

ניהול סיכוני ספקים וצדדים שלישיים

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

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

היערכות לתגובה ולהמשכיות עסקית

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

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

גם בישראל, הסיכון הוא עסקי ולא רק טכנולוגי

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

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

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

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

אז מה אנחנו צריכים ללמוד מאירוע PHP?

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

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

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

אנחנו לא יכולים לדעת מראש איזו חולשה תתגלה מחר. אנחנו גם לא יכולים להבטיח שכל הסיכונים ייעלמו.

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

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

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

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

כיצד אינפוגארד יכולה לסייע?

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

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

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

האם אתם יודעים מהן המערכות הקריטיות ביותר בארגון שלכם ומה יקרה אם הן ייפגעו?

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

מקורות

• The PHP Foundation, Today's PHP Security Release, and How We're Strengthening PHP Security – תיעוד זיהוי הסימנים הראשונים לחולשה ב-2024, הקושי במציאת מסלול ניצול מעשי, הגילויים הנוספים בשנת 2026 ותהליך תיקון החולשות, 21.10.2026.
• PHP Security Team, הודעת אבטחה רשמית לגבי CVE-2026-109618 ו-CVE-2026-109619 – חולשות קריטיות העלולות לאפשר הרצת קוד מרחוק ללא הזדהות, והמלצה לעדכון מיידי לגרסאות המתוקנות, 21.10.2026.
• Wiz Research, PHP2Shell: AI Uncovers Critical RCE Vulnerabilities Affecting 70% of the Internet – מחקר המתאר כיצד כלי AI סייעו בגילוי חולשות, בפיתוח הדגמות ניצול מעשיות ובהתאמתן למספר סביבות, 21.10.2026.
• OpenAI, Patch the Planet: Global Response Coordination as Agents Uncover Critical Vulnerabilities – שימוש בכלי AI מתקדמים במחקר חולשות PHP, גילוי ותיקון מתואמים וההשפעה האפשרית על קצב פיתוח יכולות ניצול, 21.10.2026.
• AWS Security, Amazon Threat Intelligence Identifies PHP2Shell Exploitation Prior to Public Disclosure in MadPot – זיהוי ניסיונות ניצול החל מ-17.10.2026, לפני הפרסום הרשמי, ודיון בהתקצרות חלון הזמן לתגובה לחולשות בעידן ה-AI, פורסם ב-21.10.2026.
• NIST, IR 8286D – Using Business Impact Analysis to Inform Risk Prioritization and Response – שילוב ניתוח השפעה עסקית (BIA) בזיהוי נכסים קריטיים, בהערכת השלכות עסקיות ובתיעדוף סיכוני סייבר, פברואר 2025.
• NIST, Cybersecurity Framework (CSF) 2.0 – מסגרת לניהול סיכוני סייבר הכוללת ממשל ארגוני, הערכת סיכונים ותיעדוף בקרות בהתאם לצורכי הארגון, פברואר 2024.
• הרשות להגנת הפרטיות, המדריך המלא ליישום תקנות הגנת הפרטיות (אבטחת מידע) – דרישות אבטחת מידע ובקרות להגנה על מאגרי מידע אישי בארגונים, פרסום מקורי ספטמבר 2017, עדכון פברואר 2023.

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

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

המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי ROY KISCH, חובב פרטיות, אבטחת מידע, סייבר ומנהל שיווק בקבוצת חברות עידור (Messagenet, Infoguard, Idornext).