נכתב בתאריך 22 באוקטובר 2026
בקצרה
חולשת PHP2Shell מאפשרת לתוקפים להריץ קוד מרחוק ולהשתלט על שרתים ללא צורך בשם משתמש או סיסמה. התיקון דורש עדכון של מנוע ה-PHP בשרת עצמו ולא רק עדכון של מערכת ניהול התוכן.
אם האתר או המערכת הארגונית שלכם רצים על PHP, אתם חייבים לעדכן מיד את תשתית השרת לגרסאות 8.5.12, 8.4.27, 8.3.36 או 8.2.35 כדי למנוע השתלטות מרחוק. ב-21 באוקטובר 2026 שוחרר עדכון חירום קריטי בעקבות חשיפת צמד חולשות שזכו לכינוי PHP2Shell, עם דירוג חומרה קיצוני של 9.2 מתוך 10.
הבעיה המרכזית שגורמת למנהלי מערכות כאב ראש אמיתי היא שהפגיעות נמצאת בליבת השפה עצמה, עוד לפני שקוד האתר או תוספי האבטחה שלכם בכלל נכנסים לפעולה. בשעות האחרונות מתנהל בשטח מרוץ חימוש מהיר, ובאמזון (AWS) וב-Cloudflare כבר תיעדו ניסיונות ניצול פעילים של הפרצה בהיקף רחב.
בניגוד לדיווחים חדשותיים שמסתפקים בתיאור הבהלה העולמית, ריכזנו עבורכם תוכנית פעולה טכנית ומעשית לסגירת הפרצה בשרתים שלכם כבר עכשיו.
מהי חולשת PHP2Shell ולמה היא מסכנת את השרת שלכם?
הכינוי PHP2Shell מתייחס לשתי חולשות קריטיות בניהול הזיכרון של מנוע ה-PHP. הראשונה היא CVE-2026-109618, שגורמת להשחתת זיכרון במצב של חוסר זיכרון (OOM), והשנייה היא CVE-2026-109619, שמאפשרת שימוש בזיכרון שכבר שוחרר מבקשה קודמת (Use-After-Free).
השילוב הזה מסוכן במיוחד כי הוא מאפשר הרצת קוד מרחוק (RCE) ללא שום צורך בהזדהות. התוקף שולח בקשת רשת מיוחדת, והפגיעה מתרחשת ברמת המפענח של השפה עוד לפני שהאפליקציה שלכם מתחילה לרוץ.
לפי סוכנות הסייבר האמריקאית (CISA), החולשה נוגעת לכל התקנת PHP שמשרתת בקשות אינטרנט. כל סביבות הריצה חשופות, כולל PHP-FPM, LiteSpeed, FrankenPHP ובעיקר שרתי Apache עם mod_php שנמצאים בסיכון המיידי הגבוה ביותר.
איך בינה מלאכותית חשפה באג שהסתתר מאז גרסה 5.4?
לפי חברת האבטחה Calif, הקוד הפגיע קיים בליבת PHP עוד מגרסה 5.4 הישנה. קרן PHP זיכתה על הגילוי, בין השאר, את Calif, את OpenAI ואת Wiz, ו-Calif ו-Wiz ציינו שנעזרו במודלים של בינה מלאכותית במחקר שלהן.
לפי Calif, היא הצליחה להריץ קוד מרחוק בלי התחברות על גרסאות מסוימות של וורדפרס, דרופל, ג'ומלה ומג'נטו. קרן PHP מסרה שבזמן הפרסום לא זוהו כלי ניצול שעובדים בפועל, אבל ניסיונות תקיפה כבר דווחו.
תוכנית פעולה: איך סוגרים את חולשת PHP בשרת?
במסגרת מתן ניהול שרתים ללקוחותינו, ראינו לא פעם שמנהלי מערכות מתקינים עדכון אבל שוכחים שלבים קריטיים שמשאירים את השרת חשוף. כדי לוודא שאתם מוגנים באמת, פעלו לפי סדר הפעולות הבא.
1. מיפוי מערכות ובדיקת חבילות מערכת ההפעלה
לפני הכל, אתרו את כל המקומות בארגון שבהם רץ PHP. זכרו שלפעמים השפה מסתתרת בתוך מערכות מוטמעות, קונטיינרים או תוכנות צד שלישי שאתם לא חושבים עליהן ביומיום.
בדקו איזו גרסה מותקנת בכל שרת ענן או שרת מקומי. תנו עדיפות ראשונה למערכות שחשופות ישירות לרשת האינטרנט. אם האתר שלכם יושב באחסון משותף, פנו מיד לחברת האחסון כדי לוודא שהם ביצעו את העדכון ברמת השרת.
2. התקנת הגרסאות המתוקנות (או טיפול בגרסאות ישנות)
עדכנו מיד את סביבת הריצה של PHP לאחת מהגרסאות המתוקנות ששוחררו ב-21.10.2026:
- עבור ענף 8.5: עדכנו לגרסה 8.5.12
- עבור ענף 8.4: עדכנו לגרסה 8.4.27
- עבור ענף 8.3: עדכנו לגרסה 8.3.36
- עבור ענף 8.2: עדכנו לגרסה 8.2.35
מה עושים עם שרתים ישנים? לגרסאות 7.4, 8.0 ו-8.1 פורסמו תיקוני קוד מקור בלבד (Backports), ולכן עליכם לבדוק מול ספק מערכת ההפעלה של השרת (כמו Ubuntu או RedHat) אם שוחררו חבילות עדכון תואמות. לגרסאות 5.4 עד 7.3 אין תיקון כלל, והנחיית CISA וגופי הסייבר באירופה (CERT-EU) היא לנתק מערכות בנות גרסה 8.1 ומטה מהאינטרנט אם לא ניתן לעדכן אותן מיד.
3. ניטור לוגים וזיהוי ניסיונות תקיפה
התוקפים לא חיכו להודעה הרשמית. באמזון תועדו ניסיונות תקיפה כבר ב-17 באוקטובר, וגם חברת המחקר watchTowr דיווחה על סריקות פעילות ברשת. לכן, במסגרת אבטחת ענן תקינה, חשוב לבדוק שלא נפגעתם עוד לפני העדכון.
סרקו את קובצי היומן (Logs) של השרת וחפשו בקשות multipart/form-data חריגות, שימוש בשדה PHP_SESSION_UPLOAD_PROGRESS, או שגיאות חריגת זיכרון (Out-of-memory) בשלב אתחול הבקשה. בנוסף, עקבו אחרי תהליכי PHP חשודים שמנסים להריץ פקודות מערכת (Shell) או להוריד קבצים מבחוץ.
צ'קליסט מעשי למנהלי מערכות ובעלי אתרים
session.upload_progress.enabled רק עד שהעדכון יושלם.פתרונות ביניים: מה עושים אם אי אפשר לעדכן באותו הרגע?
לפעמים שדרוג מיידי של שרת ייצור עלול לשבור מערכות קיימות ופוגע ברמת המשכיות עסקית של הארגון. אם אתם חייבים זמן קצר לבדיקות, יש שני צעדים זמניים שיכולים לצמצם מעט את החשיפה, אך חשוב להבין שהם אינם מספקים הגנה מלאה.
הצעד הראשון הוא כיבוי ההגדרה session.upload_progress.enabled בקובץ ההגדרות (והפעלה מחדש של תהליכי ה-PHP). שימו לב: זה יפסיק את פעולת פסי ההתקדמות בהעלאת קבצים באתר, וחוקרי אבטחה (כולל Datadog) כבר הבהירו שזה חוסם רק את דרכי התקיפה הידועות לאחת החולשות ולא את כולן.
הצעד השני הוא שימוש במערכת חומת אש לאתרים (WAF). חברת Cloudflare כבר הוסיפה כללי חסימה ייעודיים לתנועה שעוברת דרכה, אבל גם זה מוגדר כפלסטר זמני בלבד עד להתקנת העדכון המלא.
מתי להסתדר לבד ומתי לפנות למומחי IT?
אם יש לכם אתר תדמית פשוט שיושב על אחסון משותף מנוהל, בדרך כלל מספיק לפתוח פנייה לחברת האחסון ולוודא שהם שדרגו את גרסת ה-PHP בשרת. בממשקי ניהול פשוטים תוכלו גם להעביר את הגרסה בעצמכם בלחיצת כפתור.
לעומת זאת, אם אתם מנהלים שרתי לינוקס עצמאיים, מערכות מבוססות קונטיינרים או גרסאות PHP ישנות (8.1 ומטה) שדורשות התאמות קוד ובדיקות תאימות, אל תעשו ניסויים על שרת חי. טעות בשדרוג תשתית עלולה להשבית את האתר או להשאיר אתכם בטוחים שהשרת מוגן בזמן שהוא עדיין חשוף לתקיפה.
בדיוק בשביל מצבים כאלה אנחנו כאן. הצוות של erg מלווה עסקים וארגונים עם שירותי it לעסקים בזמינות מיידית. אנחנו יכולים לבדוק עבורכם את השרתים, להתקין את עדכוני האבטחה בבטחה ולוודא שכל המערכות ממשיכות לעבוד בצורה חלקה גם אחרי העדכון.
המלצת המומחה: אייל גבעון
"כשמתפרסמת חולשה ברמת חומרה של 9.2 שמנוצלת בפועל ברשת, זמן התגובה שלכם הוא הכל. מהניסיון שלי, הסכנה הגדולה ביותר בארגונים היא 'מערכות שקופות', כלומר שרתים ישנים או מערכות משניות שהותקנו לפני שנים ואף אחד לא זוכר שהם מריצים PHP מאחורי הקלעים. אל תסתפקו בעדכון האתר הראשי שלכם; בצעו סריקה יסודית של כל כתובות ה-IP החיצוניות של העסק, ואם יש מערכת שלא ניתן לעדכן כרגע, נתקו אותה מגישה חיצונית עד למציאת פתרון."
שאלות נפוצות
מהי חולשת PHP2Shell ואיך היא מאפשרת הרצת קוד מרחוק על שרתים?
חולשת PHP2Shell מורכבת משתי פגיעויות קריטיות (CVE-2026-109618 ו-CVE-2026-109619) במנגנון ניהול הזיכרון של PHP. היא מנצלת מצבים של חוסר זיכרון ושימוש בזיכרון ששוחרר מבקשות קודמות כדי לאפשר לתוקף להריץ קוד זדוני מרחוק (RCE) ברמת מפענח השפה, ללא צורך בהתחברות או בסיסמה.
אילו גרסאות של PHP מושפעות מחולשת האבטחה ולאילו גרסאות חובה לעדכן עכשיו?
כל גרסאות PHP החל מגרסה 5.4 שלא עודכנו לגרסאות המתוקנות חשופות לפרצה. חובה לעדכן מיד לגרסאות המתוקנות ששוחררו ב-21 באוקטובר 2026: גרסה 8.5.12, 8.4.27, 8.3.36 או 8.2.35. עבור גרסאות 7.4 עד 8.1 פורסמו תיקוני קוד מקור בלבד ויש לבדוק עדכוני חבילות מול ספק מערכת ההפעלה.
איך בודקים אם השרת או אתר הוורדפרס שלי חשופים לחולשת PHP החדשה?
יש לבדוק את גרסת ה-PHP שרצה בפועל על השרת (דרך לוח הבקרה של האחסון, כלי הבריאות של וורדפרס או פקודת טרמינל בשרת). אם הגרסה נמוכה מ-8.2.35 (בענף 8.2) או מהגרסאות המתוקנות המקבילות בענפים המתקדמים יותר, האתר שלכם חשוף לחלוטין גם אם הוורדפרס עצמו מעודכן.
מה צריך לעשות מיד אם אין אפשרות להתקין את עדכון האבטחה של PHP באופן מיידי?
אם המערכת מריצה גרסה ישנה (כמו 8.1 ומטה) או שלא ניתן לעדכן אותה מיד, ההנחיה הרשמית של CISA וגופי הסייבר באירופה היא להוציא את המערכת מהאוויר (Offline) או לבודד אותה מגישה לאינטרנט עד להשלמת העדכון. כצעד מצמצם סיכון זמני בלבד, ניתן להפעיל הגנת WAF ולכבות את הגדרת התקדמות העלאת הקבצים.
האם שינוי הגדרות בקובץ php.ini או שימוש ב-WAF מספיקים כדי להתגונן מפני חולשת PHP2Shell?
לא. כיבוי ההגדרה session.upload_progress.enabled בקובץ ההגדרות חוסם רק חלק מדרכי התקיפה הידועות לאחת החולשות ואינו מהווה הגנה מלאה. גם חומת אש לאתרים (WAF) כמו Cloudflare מספקת שכבת הגנה חלקית בלבד לתנועה שעוברת דרכה. הפתרון המלא היחיד הוא התקנת עדכון האבטחה.
איך בינה מלאכותית עזרה לחשוף את חולשת PHP?
קרן PHP זיכתה על הגילוי, בין השאר, את Calif, את OpenAI ואת Wiz, ו-Calif ו-Wiz ציינו שנעזרו במודלים של בינה מלאכותית במחקר. לפי Calif, הקוד הפגיע קיים עוד מגרסה 5.4.
בשורה אחת
חולשת PHP2Shell אינה עוד התראת אבטחה שגרתית שאפשר לדחות לשבוע הבא. עם ניסיונות תקיפה פעילים שכבר מתרחשים ברשת ויכולת להשתלט על שרתים מרחוק ללא הזדהות, כל שעה שבה השרת שלכם אינו מעודכן חושפת את העסק לסיכון ממשי.
אם אתם לא בטוחים אילו מערכות בארגון מריצים PHP, או שאתם זקוקים לסיוע מקצועי בביצוע העדכון בלי לפגוע בפעילות השוטפת, הצוות שלנו ב-ERG זמין עבורכם. קבעו שיחה איתנו עוד היום – אנחנו נבדוק את השרתים שלכם, נתקין את העדכונים הדרושים ונוודא שהכל ממשיך לעבוד בצורה יציבה ובטוחה.