PHP2Shell: מה לבקש היום מספק האחסון של אתר העסק

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

הודעה להעתקה לספק האחסון

שלום, נא לבדוק את הדומיין ______, תתי־הדומיינים והאתרים הנוספים בחשבון ביחס ל־CVE-2026-109618 ול־CVE-2026-109619. אנא מסרו את גרסת PHP המלאה ואת מספר החבילה שמשרתת בפועל כל אתר, סוג סביבת ההרצה והשרתים המעורבים. צרפו אסמכתה לכך שהתיקון מכסה את שתי החולשות, מועד ביצוע או יעד לתיקון ושם אחראי. פרטו אילו פעולות הפעלה מחדש נדרשות לפי הוראות החבילה והספק, ואשרו שבוצעו ושסביבת האתר אומתה לאחר השינוי. ציינו גם מי אחראי לגיבוי, לבדיקות התאימות ולבדיקת סימני חדירה.

הסיכון העסקי והמערכות שצריך לבדוק

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

CVE-2026-109618 קשורה לטיפול לא תקין בכשל הקצאת זיכרון; CVE-2026-109619 קשורה למצב פנימי שממשיך להפנות לזיכרון של בקשה שכבר שוחרר. הסיכון כולל הרצת קוד וחשיפת מידע, בהתאם למסלול הניצול ולתצורה. עלוני PHP מפרטים את התנאים לכל חולשה: טיפול בכשל הקצאת זיכרון ו־מצב פנימי שנותר בין בקשות. אין להסיק שכל אתר ניתן לניצול באותה דרך.

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

שלבי התיקון ואימות הסביבה הפעילה

בקשו מהספק לאשר שהתיקון חל על סביבת PHP שמשרתת בפועל את האתר. את פעולות ההפעלה מחדש והאימות יש לבצע בהתאם להוראות החבילה והספק.

1. מפו את הסביבה הפעילה

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

2. בחרו מסלול תיקון

עלוני PHP עבור CVE-2026-109618 ועבור CVE-2026-109619 מציינים את גרסאות התיקון הראשונות בטבלה הבאה. המיפוי מתייחס לענפים 8.2–8.5 ולשתי החולשות המקוריות; אין להסיק ממנו שענפים ישנים יותר אינם פגיעים.

בקשו מהספק לבחור חבילה מתוקנת המתאימה לסביבה ולצרף אסמכתה המכסה את שתי החולשות. אם נדרש מעבר לענף אחר, תכננו עם המפתח את בדיקות התאימות לפני השינוי.

3. גבו ובדקו תאימות

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

4. בצעו את הוראות ההפעלה ואמתו את התוצאה

בקשו מהספק לבצע את פעולות ההפעלה מחדש הנדרשות לפי הוראות החבילה וסביבת ההרצה, ולוודא לאחר השינוי שהאתר משתמש בחבילה המתוקנת. שמרו את אישור הביצוע ואת ראיית האימות עם תשובת הספק.

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

עלון Red Hat מתאר גם חולשה קשורה, CVE-2026-115560, הדורשת שילוב חריג של תצורה וקוד יישום. לפי העלון, השבתת מנגנון התקדמות העלאת קבצים באמצעות session מגינה מפניה. בקשו מהספק לבדוק את הנחיות המוצר להגדרה המתאימה ולהשלכותיה על האתר. אין לראות בפעולה זו אישור לתיקון שתי החולשות המקוריות.

חלוקת אחריות ותנאי סיום

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

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

שאלות נפוצות