PHP2Shell: פרצת אבטחה ב-PHP ומה לבדוק באתר העסק

PHP2Shell: מה זו פרצת האבטחה ב-PHP שנחשפה באוקטובר?

PHP2Shell הוא השם של שתי חולשות קריטיות ב-PHP, השפה שעליה רץ WordPress. לפי הודעת צוות PHP מ-21 באוקטובר 2026, מדובר בפרצת אבטחה ב-PHP שמאפשרת לתוקף להריץ קוד על השרת בלי שם משתמש וסיסמה. התיקון יצא באותו יום, בגרסאות 8.5.12, 8.4.27, 8.3.36 ו-8.2.35. שרת שלא עודכן נשאר חשוף.

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

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

האם האתר של העסק שלכם בסיכון?

אם האתר בנוי על WordPress, או על כל מערכת אחרת שכתובה ב-PHP, הוא בסיכון עד שמישהו עדכן את PHP בשרת. WordPress ממליץ על PHP 8.3 ומעלה, אבל לפי האתר הרשמי שלו הוא עובד גם עם PHP 7.4. כלומר, אתר יכול לעבוד מצוין על גרסה שלא תקבל תיקון. השאלה היא לא אם האתר עובד, אלא איזו גרסה רצה מתחתיו.

לפי W3Techs, נכון ל-23 באוקטובר 2026, PHP משמש 69.3% מהאתרים ששפת השרת שלהם ידועה. מתוך האתרים שמריצים PHP, 65.3% על גרסה 8, 26.9% על גרסה 7 ו-7.7% על גרסה 5. צוות PHP כבר לא מוציא עדכונים לגרסה 8.1 ולכל מה שלפניה, ולכן גם בתוך גרסה 8 רק 8.2 ומעלה מקבלות גרסה מתוקנת רשמית.

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

מי אחראי לעדכן את PHP: חברת האחסון, המפתח או אתם?

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

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

בענן יש גם הפתעות. לפי עלון האבטחה של AWS מ-21 באוקטובר 2026, AWS לא יכולה לעדכן במקום שרתי Lightsail שכבר רצים. מי שמריץ עליהם PHP צריך להקים שרת חדש מתבנית מעודכנת ולהעביר אליו את האתר. זו עבודה, לא לחיצה על כפתור, ומישהו צריך לתכנן אותה.

מה עושים אם גרסת PHP באתר היא 8.1 או ישנה יותר?

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

צוות PHP אמנם פרסם תיקון מינימלי לקוד המקור של 7.4, 8.0 ו-8.1, אבל לפי ההודעה שלו הוא נועד למי שבונה PHP בעצמו או שאין לו ספק LTS.

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

האם כבר מנצלים את הפרצה בפועל?

יש ניסיונות, ולא ברור כמה מהם עובדים. CISA כתבה ב-21 באוקטובר שלא זיהתה ניצול נכון למועד הפרסום. ב-23 באוקטובר כתב Johannes Ullrich ממרכז SANS ISC ש-Cloudflare ו-Amazon רואות מספר גדול של ניסיונות תקיפה, אבל לא ברור אם הם עובדים. לדבריו, ככל הידוע לו, עד אותו יום לא פורסם לציבור קוד תקיפה אמין.

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

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

האם חומת אש לאתר (WAF) מחליפה את העדכון?

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

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

האם רק האתר בסכנה, או גם מערכות אחרות במשרד?

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

ההמלצה של SANS נכונה בלי קשר ל-PHP: ממשקי ניהול של נתבים, אחסון רשת (NAS) ומצלמות לא אמורים להיות חשופים לאינטרנט, והם צריכים לשבת ברשת פנימית מבודדת. אנחנו אומרים את אותו דבר על RDP: מה שלא חייב להיות פתוח לאינטרנט, סגור. אם אתם לא יודעים מה אצלכם נראה מבחוץ, המדריך על מיפוי שטח התקיפה החיצוני של העסק מסביר איך בודקים.

מה לבקש מחברת האחסון ומאיש ה-IT?

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

1. גרסה. איזו גרסת PHP רצה על השרת של האתר, עם מספר הגרסה המלא? אנחנו מצפים ל-8.5.12, 8.4.27, 8.3.36 או 8.2.35, או לגרסה חדשה יותר באותו ענף.
2. גרסה ישנה. אם השרת על 8.1 או ישן יותר: מה התוכנית לשדרוג, ועד מתי? האם יש תיקון מספק מערכת ההפעלה?

1. גיבוי. לפני כל שדרוג, גיבוי מלא של האתר ושל מסד הנתונים, שנשמר מחוץ לשרת.
2. ההגדרה שנשארת כבויה. עד העדכון הרגיל הבא של PHP, להשאיר כבויה את מעקב ההתקדמות של העלאות בסשן (session upload progress), כמו שצוות PHP המליץ ב-23 באוקטובר.

1. סימני חדירה. לבדוק ביומני השרת אם תהליכים של PHP הפעילו shell או הורידו כלים. זה בדיוק מה ש-CISA ממליצה לנטר.
2. מיפוי. רשימה של כל מערכת בעסק שמריצה PHP: אתר נוסף, דף נחיתה, מערכת פנימית, פורטל לקוחות.

1. ציוד המשרד. לוודא שממשקי הניהול של הנתב, ה-NAS והמצלמות לא נגישים מהאינטרנט.

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

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

ובינתיים, שאלה אחת: מתי בפעם האחרונה מישהו אמר לכם בכתב איזו גרסת PHP רצה מתחת לאתר שלכם?

שאלות נפוצות

האם PHP 7.4 פגיע ל-PHP2Shell?

כן, ואין לו תיקון רשמי. לפי עלון האבטחה של AWS, לגרסאות 5.4 עד 8.1 לא שוחרר תיקון מצוות PHP, כי הן כבר מחוץ לתמיכה. התיקון המינימלי שצוות PHP פרסם לקוד המקור של 7.4 מיועד למי שבונה PHP בעצמו. לאתר עסקי על 7.4 הדרך היא שדרוג לגרסה נתמכת, ועד אז CISA ממליצה להוריד את המערכת מהרשת.

האם עדכון של WordPress מתקן את PHP2Shell?

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

איך יודעים אם האתר כבר נפרץ דרך PHP2Shell?

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

האם PHP2Shell משפיע גם על אתרים שלא בנויים ב-WordPress?

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