PHP2Shell - למה עדכון האתר לא מחליף את תיקון PHP בשרת
שתי חולשות קריטיות ב־PHP מאפשרות בתנאים מסוימים הרצת קוד מרחוק ללא התחברות. באחד ממסלולי הניצול, הכשל מתרחש עוד לפני שקוד האתר מתחיל לפעול. לבעלי אתרים, המשמעות היא לבדוק איזו סביבת PHP מריצה את האתר בפועל והאם התיקונים הוחלו עליה.
ב־21 באוקטובר 2026 פורסמו עדכוני אבטחה לשתי חולשות המכונות יחד PHP2Shell: CVE-2026-109618 ו־CVE-2026-109619. שתיהן קיבלו דירוג חומרה של 9.2 מתוך 10 לפי CVSS v4.0. ניצול מוצלח עשוי לאפשר לתוקף בלתי מזוהה להריץ קוד בשרת, בהרשאות של תהליך ה־PHP.
האירוע נוגע ישירות גם למי שמנהל אתר וורדפרס ומקפיד לעדכן תוספים ותבניות. החולשות נמצאות ב־PHP עצמה, סביבת הריצה שמבצעת את קוד האתר. לכן, השלמת העדכונים במערכת ניהול התוכן עדיין משאירה שאלה נפרדת: האם גם סביבת השרת תוקנה.
הכשל יכול להתרחש לפני שקוד האתר מתחיל לרוץ
הפרט המשמעותי ביותר בדיווח הטכני נוגע לאופן שבו PHP מטפלת בבקשה נכנסת. לפני שהאפליקציה מתחילה לעבוד, סביבת הריצה כבר מבצעת פעולות הכנה ועיבוד של נתוני הבקשה.
בחולשה CVE-2026-109618, מחסור בזיכרון עלול להפסיק פעולה בזמן שחלק מנתוני הבקשה הפנימיים עדיין אינם מאותחלים כראוי. בהמשך, מנגנון סיום הבקשה עלול להשתמש בנתונים הפגומים כאילו היו תקינים.
בתצורת Apache עם mod_php תועד מסלול שבו עיבוד אוטומטי של בקשת multipart, המשמשת בין היתר להעברת טפסים וקבצים, מוביל למצב הזה לפני הרצת קוד האפליקציה.
מבחינת בעלי אתרים, זו הסיבה שעדכון תוסף או הוספת בדיקת קלט בקוד אינם פתרון לפגם עצמו. הבקשה יכולה להגיע לשלב הפגיע עוד לפני שההגנות שבתוך האתר מקבלות הזדמנות לבדוק אותה. גם כאשר מופעל סינון תעבורה, נדרש תיקון של סביבת הריצה.
שתי חולשות, עם תנאי ניצול שונים
החולשה השנייה, CVE-2026-109619, קשורה למידע פנימי שנשאר נגיש בין בקשות. תהליך PHP שמטפל בבקשות, המכונה worker, עלול לשמור הפניה לזיכרון שכבר שוחרר. כאשר אותו תהליך מטפל בבקשה נוספת, פעולה מוקדמת יכולה להשתמש בהפניה הישנה לפני שהאתחול הרגיל מאפס אותה. זהו כשל מסוג use-after-free.
בדיווח הטכני אומתה הרצת קוד דרך מנגנון מעקב התקדמות העלאות גם ב־mod_php וגם ב־PHP-FPM, בכפוף לתנאים המתוארים בו. לעומת זאת, במסלול המחסור בזיכרון של החולשה הראשונה, ניתוח הקוד מצביע על חשיפה אפשרית ב־FPM, אך לא הודגם בו ניצול מלא.
ההבחנה הזאת חשובה להערכת הסיכון. אין בסיס לקבוע שכל אתר PHP ניתן לפריצה באותה דרך או באותה קלות. עם זאת, הודעת PHP הרשמית כוללת באזהרה את כלל ההתקנות שמשרתות בקשות אינטרנט, ובהן PHP-FPM, mod_php, php-cgi, FrankenPHP ו־LiteSpeed.
אילו גרסאות PHP כוללות את התיקונים
הגרסאות הבאות פורסמו ב־21 באוקטובר עם תיקונים לשתי חולשות PHP2Shell:
| ענף PHP | הגרסה הכוללת את התיקונים |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
אפשר לקבל את התיקונים גם באמצעות חבילות אבטחה של ספק מערכת ההפעלה או ספק התחזוקה. במקרים כאלה, הספק עשוי להחיל תיקון באמצעות backport, בלי להחליף את מספר גרסת הבסיס במספר המופיע בטבלה. לכן צריך לבדוק גם את זיהוי החבילה ואת הודעת האבטחה של הספק.
PHP 8.1 וגרסאות ישנות יותר אינן מקבלות עוד עדכונים רגילים מפרויקט PHP. עבור מערכות כאלה נדרשת בדיקה מול ספק התחזוקה או מעבר לענף נתמך. פורסמו גם תיקוני מקור מצומצמים לענפים ישנים מסוימים, אך עצם פרסומם אינו מעיד שהם הותקנו בשרת.
האזהרה הנוספת מ־23 באוקטובר
יומיים לאחר פרסום התיקונים, פרויקט PHP פרסם הנחיה נוספת בנוגע לתכונת מעקב התקדמות העלאות, תחת המזהה CVE-2026-115560.
לפי ההודעה, מסלול זה דורש שילוב חריג: הגדרת מנגנון שמירת נתוני session כ־php_binary או php_serialize, מעבר ל־php בזמן הריצה לפני הקריאה ל־session_start(), ותכונת מעקב העלאות פעילה.
הפרויקט ממליץ להגדיר session.upload_progress.enabled=0 עד לעדכון התיקונים הרגיל הבא. ההודעה מבהירה שאפליקציות שאינן מחליפות את מנגנון ה־session בזמן הריצה יכולות להשאיר את התכונה פעילה.
לכן, גם אחרי התקנת גרסאות החירום צריך לבדוק את ההנחיה הנוספת מול תצורת השרת והאפליקציה.
מה לבדוק מול חברת האחסון
הבדיקה המועילה ביותר היא של סביבת הריצה שמשרתת את הדומיין המסוים. מספר גרסה בשורת הפקודה או בחירת ברירת מחדל בלוח הניהול אינם מספיקים לבדם כדי לאמת זאת.
למנהל השרת יש אפשרות לזהות את גרסת PHP הפעילה באמצעות phpversion() ואת ממשק ההפעלה באמצעות php_sapi_name(). לצורך בדיקת אתר, יש לבצע את האימות בהקשר של בקשת אינטרנט לאותו אתר. זו המלצה תפעולית הנובעת מההבדל בין סביבת CLI לבין ממשקי ההפעלה של שרת האינטרנט.
בפנייה לחברת האחסון כדאי לבקש תשובה ממוקדת על ארבע נקודות:
- איזו גרסת PHP ואיזו חבילת ספק מריצות את הדומיין בפועל.
- האם החבילה כוללת תיקונים לשני מזהי ה־CVE של PHP2Shell.
- האם תהליכי ה־PHP הפעילים הוחלפו או אותחלו כנדרש לאחר העדכון.
- האם נבדקה גם ההנחיה מ־23 באוקטובר לגבי
session.upload_progress.
בסביבה מנוהלת, בקשה לאישור כזה מועילה יותר משינוי עצמאי של הגדרות ללא היכרות עם תצורת השרת.
חשוב לכלול במיפוי גם ממשקי ניהול ומוצרי צד שלישי שמטמיעים PHP. מרכז הסייבר הלאומי של הולנד מדגיש שהחשיפה יכולה להימצא גם במכשירים ובמערכות שבהם PHP אינה רכיב שבעל האתר מעדכן ישירות.
הגנות זמניות דורשות התאמה לשרת
בהודעות הטכניות מופיעים צעדים לצמצום מסלולי ניצול, ובהם הגבלת בקשות, כיבוי תכונות מסוימות ושינוי הגדרות זיכרון. צעדים אלה אינם מכסים את כל התנאים הפגיעים.
בפרט, אין להעתיק אוטומטית את ההגדרה memory_limit=-1. היא מסירה את מגבלת הזיכרון של PHP ויכולה לצמצם את המסלול המבוסס על חריגה ממנה, אך אינה מונעת כל כשל הקצאת זיכרון. יישומה דורש גם התייחסות להגבלת משאבים ברמת התשתית.
גם כיבוי מעקב העלאות מצמצם מסלולים מסוימים של החולשה השנייה. הוא אינו מכסה את כל סוגי המידע הפנימי שעלולים להישאר בין בקשות. הפתרון הנדרש לשתי החולשות הוא התקנת התיקונים המתאימים.
לאחר העדכון צריך לבחון גם את תקופת החשיפה
נכון ל־23 באוקטובר, סוכנות הסייבר של סינגפור דיווחה על ניסיונות ניצול נרחבים ועל פיתוח קוד הוכחת היתכנות. דיווח על ניסיונות אינו מוכיח שכל ניסיון הצליח או שאתר מסוים נפרץ. הוא כן מצדיק תעדוף של מערכות החשופות לאינטרנט ובחינת סימנים לפעילות חריגה.
למערכת שהייתה חשופה מומלץ לתעד מתי הוחל התיקון ולבחון את התקופה שקדמה לו בהתאם לרמת הסיכון. התקנת עדכון אינה מספקת מידע על מה שאירע לפני ההתקנה.
ההפרדה בין מצב העדכונים לבין חקירת פעילות קודמת מופיעה גם בכתבה על שרשרת הפריצה שהתגלתה ב־Ivanti. במקרה של PHP2Shell, הצעד הראשון הוא לקבל אישור שסביבת PHP הפעילה תוקנה, ולצרף אליו בדיקת חשיפה כאשר נסיבות המערכת מצדיקות זאת.
