שתי חולשות אבטחה בדירוג 9.2 מאפשרות השתלטות מרחוק על שרתים ללא סיסמה. מתקפות כבר זוהו, שירותים ממשלתיים נותקו מהרשת ותיקוני חירום שוחררו
במשך שנים, PHP הייתה אחת מאבני היסוד השקטות של האינטרנט. עכשיו, שתי פרצות אבטחה שנחשפו בשפת התכנות הפופולרית גרמו לממשלות להשבית שירותים מקוונים, לחברות אחסון להיכנס לכוננות ולמנהלי אתרים בכל העולם לחפש בדחיפות את גרסת ה-PHP שמותקנת אצלם. הסיבה פשוטה ומדאיגה: בתנאים מסוימים, תוקף יכול להשתלט על שרת פגיע באמצעות בקשת HTTP זדונית, בלי לדעת סיסמה ובלי להזדהות.
בהולנד הושבתו כאמצעי זהירות שירותי ממשל מרכזיים, בהם DigiD, המשמש להזדהות מול רשויות המדינה, ו-MijnOverheid, הפורטל האישי של אזרחי הולנד. שירותים ואתרים נוספים הושבתו במדינות אירופה, וגם קרן Wikimedia נאלצה לנתק זמנית מערכות התומכות בוויקיפדיה. חשוב להבחין בין השבתה יזומה לבין מתקפת סייבר מוצלחת: חלק מהארגונים בחרו להתנתק דווקא כדי למנוע פריצה, ולא מפני שכבר נפרצו.
שתי חולשות בלב מנגנון הזיכרון
הפרצות, שמזוהות כ-CVE-2026-109618 ו-CVE-2026-109619 וזכו לכינוי PHP2Shell, קיבלו כל אחת דירוג חומרה של 9.2 מתוך 10 בתקן CVSS 4.0. הן נמצאות במנוע של PHP עצמו, ולא בתוסף מסוים או באתר שנכתב בצורה רשלנית. המשמעות היא שגם מערכת ניהול תוכן מעודכנת לחלוטין עלולה להיות חשופה אם סביבת ה-PHP שמתחתיה לא תוקנה.
שתי החולשות קשורות לאופן שבו PHP מנהלת זיכרון ומטפלת בשגיאות. הראשונה מאפשרת, בתנאים מסוימים, לגרום לתהליך להגיע למגבלת הזיכרון שלו בזמן עיבוד בקשה. כאשר PHP מנסה להתאושש, היא עלולה להשתמש במבני נתונים שלא אותחלו כראוי. השנייה מתרחשת כאשר שגיאה חמורה משאירה הפניות למידע שכבר שוחרר מהזיכרון, ובקשה מאוחרת יותר משתמשת באותן הפניות.
אלה נשמעות כמו תקלות פנימיות שרק מפתחי PHP צריכים להכיר, אבל התוצאה האפשרית חמורה בהרבה מקריסה של אתר. ניצול מוצלח עלול לאפשר לתוקף להריץ קוד על השרת, לגשת למידע רגיש ולפעול בהרשאות של תהליך ה-PHP. החוקרים כבר הצליחו להדגים הרצת קוד מרחוק בסביבות Apache עם mod_php, ובמקרים מסוימים גם בסביבות PHP-FPM.
הסיכון גבוה במיוחד בשרתים המשתמשים ב-mod_php, שבהם הודגמה תקיפה באמצעות בקשה ללא הזדהות, עוד לפני שקוד האפליקציה מתחיל לפעול. במילים אחרות, גם בדיקות האבטחה שמפתח האתר הוסיף לקוד שלו לא בהכרח יגיעו להזדמנות לעצור את הבקשה.
היקף החשיפה מסביר את הדאגה. PHP משמשת כ-69% מהאתרים ששפת צד השרת שלהם ידועה, והיא עומדת מאחורי פלטפורמות נפוצות כמו WordPress, Drupal, Joomla ו-Magento. לא כל אתר כזה נפרץ, ולא כל התקנת PHP חשופה באותה מידה, אבל מספר המערכות שדורשות בדיקה מגיע למיליונים.
הפגם היה מוכר מ-2024, הבינה המלאכותית חשפה את הסכנה
אחד הפרטים המעניינים בסיפור הוא שלפחות חלק מהבעיה לא התגלה רק השבוע. כבר ב-2024 זיהה מפתח PHP סימנים לליקוי בניהול הזיכרון, בעקבות ביקורת אבטחה חיצונית. האפשרות לנצל אותו נבחנה, אך באותו שלב לא נמצאה דרך מעשית להרצת קוד זדוני מרחוק.
פיתוח תיקון התעכב במשך חודשים. הפתרונות שנבחנו היו עלולים לשבור תאימות לאחור, ליצור בעיות חדשות או לחייב שינויים בתוספים רבים. צוות האבטחה הקטן התקשה להגיע להחלטה, והטיפול נדחה שוב ושוב. אנשי הפרויקט הודו כעת שהעיכוב נבע מכשל בתהליכי קבלת ההחלטות וממחסור במשאבים.
השינוי הגיע באוגוסט 2026. חוקרי אבטחה מחברת Calif, שנעזרו במודל GPT-5.6 Sol של OpenAI במסגרת יוזמת Patch the Planet, הדגימו דרך מעשית לניצול החולשה. גם חוקרי Wiz ו-OpenAI הגיעו באופן עצמאי לממצאים דומים. מה שנחשב במשך שנתיים לבעיה מורכבת שקשה לנצל הפך לאיום מוחשי על שרתי אינטרנט.
התיקונים תוכננו במקור ל-22 באוקטובר, אבל פרטים על הפרצות החלו להסתובב ברשת יממה קודם לכן. סרטון שהציג הדגמת תקיפה פורסם בטעות, ובהמשך הופצו גרסאות שלו. מפתחי PHP הקדימו את השחרור ל-21 באוקטובר, אך עוד לפני כן הופצו קבצים שהכילו את התיקון ואפשרו לתוקפים פוטנציאליים לנתח את השינויים.
במקביל, Cloudflare כבר זיהתה תעבורת תקיפה המנסה לנצל את החולשות. החברה פרסה כללי הגנה חדשים בחומת האש שלה, כולל עבור לקוחות במסלול החינמי, והוסיפה מנגנון שבוחן לא רק את הבקשה המגיעה לשרת אלא גם את התגובה שהוא מחזיר. כך אפשר לזהות דפוסים חשודים שקשה לאתר מתוך הבקשה בלבד. זיהוי ניסיונות תקיפה אינו מעיד בהכרח על השתלטות מוצלחת על השרתים שהותקפו.
יש כאן גם שינוי משמעותי במאזן הכוחות של אבטחת המידע. כלי AI מאפשרים לחוקרים לאתר ולנתח פגמים עמוקים בקוד במהירות שלא הייתה מעשית בעבר, אבל אותן יכולות עשויות לקצר גם את הזמן שנדרש לתוקפים לפתח ניצול עובד. במקרה הזה, נראה שצד ההגנה הצליח להגיע ראשון. השאלה היא כמה פעמים זה יקרה גם בעתיד.
התיקונים כבר בחוץ, אבל עדכון WordPress לא מספיק
מפתחי PHP פרסמו ב-21 באוקטובר ארבע גרסאות מתוקנות: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 ו-PHP 8.2.35. העדכונים מטפלים בשתי החולשות, וההמלצה למנהלי שרתים היא להתקין אותם באופן מיידי. גרסאות PHP 8.1 ומטה כבר אינן מקבלות עדכונים שוטפים מהפרויקט, אף שחלק מספקי הלינוקס והתמיכה ארוכת הטווח מציעים תיקונים מותאמים.
עבור בעלי אתרי WordPress, הנקודה החשובה היא שהעדכון צריך להתבצע ברמת השרת. עדכון WordPress, התקנת גרסת תוסף חדשה או שינוי סיסמת מנהל לא יתקנו פרצה במנוע PHP. מי שמשתמש באחסון שיתופי צריך לוודא שספק האחסון התקין את העדכון המתאים, ולא להסתפק בכך שמערכת ניהול התוכן מציגה שהכול מעודכן.
מי שמנהל שרת בעצמו צריך לבדוק את גרסת ה-PHP הפעילה בפועל, להתקין את חבילת האבטחה הרלוונטית ולוודא שתהליכי השרת הופעלו מחדש עם הגרסה המתוקנת. במערכות שמריצות כמה גרסאות PHP במקביל, או משתמשות בקונטיינרים ובסביבות נפרדות, יש לבדוק כל התקנה בנפרד.
למנהלים שאינם יכולים לעדכן מיד קיימים צעדים זמניים להפחתת החשיפה, בהם הגבלת העלאות קבצים, שינוי הגדרות מסוימות של ניהול הזיכרון וביטול מנגנוני עיבוד מסוימים. אבל אלה אינם מספקים הגנה מלאה, וחלקם מחייבים בדיקה זהירה כדי שלא לפגוע בפעילות האתר. במקרים שבהם אי אפשר להגן על שרת חשוף, ההמלצה היא לשקול ניתוק זמני שלו מהאינטרנט עד להתקנת התיקון.
עבור הגולש הרגיל אין צורך לעדכן דבר במחשב או בדפדפן. האחריות נמצאת אצל מפעילי השירותים. עבור בעלי האתרים, לעומת זאת, זה אחד מאותם מקרים שבהם דחיית תחזוקת שרת שגרתית עלולה לעלות הרבה יותר מכמה דקות של השבתה יזומה.
האירוע הזה ממחיש עד כמה האינטרנט תלוי ברכיבי תוכנה ותיקים, שמתוחזקים לעיתים בידי צוותים קטנים ביחס למספר המערכות שנשענות עליהם. כשחולשה נמצאת בשכבת התוכנה שעליה פועלים מיליוני אתרים, גם קוד אתר מושלם לא יתקן את מה שנמצא מתחתיו.
