PHP2Shell הוא הכינוי לשתי פרצות קריטיות בליבת PHP, שמספרי הזיהוי שלהן הם CVE-2026-109618 ו-CVE-2026-109619. ניצול מוצלח שלהן עלול לאפשר לתוקף להריץ קוד בשרת פגיע בלי להזדהות קודם. תיקונים פורסמו ב-21 באוקטובר 2026, וחברות אבטחה דיווחו על ניסיונות ניצול — אך ניסיון תקיפה אינו הוכחה לפריצה מוצלחת.
11
14
19
מה עושות פרצות PHP2Shell?
החולשות נמצאות בסביבת הריצה של PHP עצמה, ולא באתר מסוים או במערכת ניהול תוכן מסוימת. לפי Red Hat, באחת מהן טיפול שגוי במצב הזיכרון עלול להתרחש כאשר הקצאת זיכרון נכשלת במהלך עיבוד בקשה; השנייה עלולה להשאיר מצב פנימי מיושן אחרי ששגיאה חמורה קוטעת את תהליך הניקוי.
7 השילוב בין הבעיות עשוי לאפשר הרצת קוד מרחוק — כלומר, תוקף עשוי להפעיל קוד בשרת פגיע גם בלי להתחבר אליו תחילה.
11
13
לכל אחת מהפרצות ניתן ציון 9.2 לפי CVSS v4.0, דירוג שנחשב קריטי.
4 התוצאות האפשריות כוללות השתלטות על שרת, חשיפת מידע או שיבוש שירותים. עם זאת, עצם קיומן של הפרצות לא אומר שכל אתר PHP הותקף או נפרץ.
13
למה האירוע עורר דאגה?
לפי דיווחים, הפרצות היו קיימות ב-PHP במשך שנים לפני שהתגלו.
42 משך הזמן הזה אינו מוכיח שתוקפים הכירו אותן או ניצלו אותן לאורך כל התקופה.
האירוע גם עורר עניין בגלל השימוש בבינה מלאכותית במחקר אבטחה. לפי הדיווחים, Calif ו-Wiz השתמשו בכלי AI במסגרת החקירות שלהן, וגם OpenAI הייתה מעורבת במאמץ המחקר והדיווח.
34
44 כלי AI יכולים לסייע לחוקרים לבחון תוכנה, אבל סיפור הגילוי לבדו לא מוכיח באיזו מהירות תוקפים יוכלו להשתמש בכלים דומים, או מי מהצדדים נהנה מיתרון.
בחלק מהכותרות הוזכר גם השימוש הרחב ב-PHP — לעיתים בהערכה של כ-70% מהאתרים.
20 הנתון מתייחס להיקף השימוש המדווח בשפה, ולא למספר השרתים שאומתו כפגיעים או נפרצו. החשיפה בפועל תלויה בגרסת PHP, בהגדרות, באופן הפריסה ובשאלה אם הותקן תיקון.
תיקונים, ניסיונות תקיפה ומה ידוע עליהם
פרויקט PHP פרסם ב-21 באוקטובר גרסאות מתוקנות: 8.2.35, 8.3.36, 8.4.27 ו-8.5.12.
19 רשימת הגרסאות שפורסמה מכסה את PHP 8.2 עד 8.5. ארגונים המשתמשים בגרסאות ישנות יותר צריכים לבדוק את הודעות האבטחה של ספק מערכת ההפעלה או שירות האחסון, ולוודא אם קיים תיקון מאומת או תיקון שהותאם לאחור — במקום להניח שהוא זמין או שאינו קיים.
יש דיווחים על ניסיונות ניצול. SecurityWeek דיווחה כי אמזון זיהתה ניסיון ב-17 באוקטובר, ארבעה ימים לפני פרסום התיקונים.
14 גם Cloudflare דיווחה על עלייה חדה בתעבורה שניסתה לנצל את הפרצות לאחר שהמידע עליהן פורסם, עם מספרים שהגיעו למיליונים בדיווחים מאוחרים יותר.
27
38 אלה נתונים על ניסיונות שנצפו, ולא על פריצות מוצלחות.
הדיווחים אינם אחידים בהערכת היקף התקיפות: חלק מהמקורות תיארו ניסיונות תקיפה פעילים, ואחרים העריכו שניצול המוני נרחב נראה פחות סביר מכפי שחששו בתחילה.
3
4 החומר הזמין אינו מוכיח שהתרחשה פגיעה מוצלחת בהיקף רחב. חשוב להתייחס ברצינות לדיווחים אמינים על תקיפות, ובמקביל להבחין בין סריקות או ניסיונות ניצול לבין ראיות לכך ששרת מסוים נפרץ.
2
3
צעדי חירום של מפעילי שירותים ורשויות
חלק מהארגונים השביתו שירותים שהיו נגישים לציבור בזמן שנערכו לטיפול בפרצות. לפי דיווחים, אתרים ושירותים הושבתו זמנית או הועברו לתחזוקה ביפן, בצרפת, בפינלנד ובהולנד; גם רשויות בארצות הברית ובאירופה קראו לארגונים לפעול.
18
20
35 השבתת אתר עשויה לצמצם חשיפה במהלך הטיפול, אך אינה מעידה כשלעצמה שהאתר נפרץ.
מה כדאי למפעילי PHP לעשות?
- לבדוק את סביבת הריצה, לא רק את האתר. PHP2Shell משפיע על סביבת הריצה של PHP. עדכון מערכת ניהול תוכן או תוסף לבדו אינו מוכיח שהתקנת PHP עצמה תוקנה.
13
- להתקין תיקון מאומת. יש לעדכן לגרסת PHP מתאימה שבה תוקנו החולשות, או לפעול לפי הנחיות הספק לגבי תיקון שהותאם לאחור. חשוב לוודא איזו גרסה פועלת בפועל בסביבת הייצור.
19
- לחפש סימנים לפריצה. התקנת תיקון מטפלת בפגיעות, אך אינה מוכיחה שאיש לא ניגש לשרת קודם לכן. בדקו יומני מערכת רלוונטיים וחקרו פעילות חשודה לפני החזרה לשגרה.
- להשתמש בהפחתות סיכון זמניות בזהירות. יש לפעול לפי הנחיות עדכניות של צוות PHP או של הספק. שינוי הגדרה בודד או חומת אש לאפליקציות אינטרנט (WAF) אינם תחליף לתיקון מאומת בסביבת הריצה.
15
27
- להוסיף שכבות הגנה לחשבונות. סיסמאות ייחודיות ואימות רב-שלבי מסייעים להגן על חשבונות, אך אינם מתקנים חולשה שמאפשרת הרצת קוד בשרת ללא אימות.
לצוותי IT חשוב להבחין בין חולשה, ניסיון ניצול ופריצה מאומתת. ההבחנה מאפשרת לפעול במהירות להתקנת תיקונים, בלי להפוך טענות לא ודאיות למסקנות על מי שנפגע.