שבוע לחוץ במיוחד עבר על מנהלי אתרים ושרתים ברחבי העולם. בפרויקט PHP, שפת התכנות שעליה רצים חלק ניכר מאתרי האינטרנט, ממערכות ניהול תוכן ועד חנויות מקוונות, פורסמו ב-21 באוקטובר עדכוני חירום לשתי חולשות קריטיות. החולשות, שזכו לכינוי PHP2Shell וסומנו CVE-2026-109618 ו-CVE-2026-109619, דורגו 9.2 בסולם CVSS 4.0. לפי החוקרים, הן עלולות לאפשר לתוקף להריץ קוד על שרת פגיע מרחוק, בלי שם משתמש וסיסמה.
מה שהפך את הסיפור לשיחת היום בתעשייה הוא לא רק חומרת החולשות, אלא הדרך שבה נמצאו. לפי הדיווחים, חוקרים בחברת האבטחה Wiz, שבבעלות גוגל, ובחברת הבינה המלאכותית Calif איתרו את הבעיות בעזרת מודלים מתקדמים של OpenAI ושל גוגל. Wiz מסרה שהיא זיהתה את החולשה הראשונה באוגוסט ודיווחה עליה למפתחי PHP כעבור כמה ימים. מכאן התחיל תהליך של גילוי אחראי שהסתיים בפרסום העדכונים.
מי בסיכון
לפי הסיכומים שפורסמו, הפגיעות נוגעת לטווח רחב של גרסאות, מ-PHP 5.4 ועד 8.5. הדרכים הנפוצות להריץ PHP על שרת, ובהן PHP-FPM, אפאצ'י עם mod_php, php-cgi, FrankenPHP ו-LiteSpeed, מופיעות ברשימת התצורות שבסיכון. הצירוף של אפאצ'י עם mod_php מוגדר כמסוכן ביותר. כותרות רבות דיברו על עד 70 אחוז מאתרי האינטרנט. כדאי לזכור שזה הנתון על נפוצות השפה, ולא ספירה של שרתים שנפרצו בפועל.
העדכונים זמינים בגרסאות 8.5.12, 8.4.27, 8.3.36 ו-8.2.35. מי שמריץ PHP 8.1 או גרסה ישנה יותר לא יקבל תיקון רשמי מהפרויקט, ויצטרך לשדרג או לבדוק אם ספק ההפצה שלו מציע עדכון משלו. בהודעה הרשמית נכתב שאין עקיפה מלאה ושהעדכון הוא הדרך הבטוחה היחידה.
השעון כבר מתקתק
כמו כמעט בכל חולשה מתוקשרת, הפער בין הפרסום לניסיונות הניצול היה קצר מאוד. לפי דיווחים בתקשורת המקצועית, קוד שמדגים את הניצול הופיע ב-GitHub בתוך שעות. אמזון דיווחה על ניסיונות תקיפה בפועל, ואתר The Hacker News דיווח שתועד ניסיון ניצול ארבעה ימים לפני הפרסום הרשמי. הנתון האחרון מעורר שאלות לא נוחות: האם המידע דלף, או שגורם נוסף מצא את אותה בעיה במקביל?
יומיים אחרי עדכוני החירום הודיעו מפתחי PHP על בעיה נוספת שעדיין לא תוקנה, CVE-2026-115560. לפי ההודעה, הסיכון ממנה נמוך יותר, כי היא משפיעה רק על יישומים שמוגדרים בצורה לא שגרתית. בכל זאת, מי שמנהל מערכות צריך לעקוב גם אחריה.
מה לעשות עכשיו
לבעלי אתרים קטנים שמשתמשים באחסון משותף, הצעד הראשון הוא לבדוק מול ספק האחסון שהעדכון הותקן. ארגונים שמנהלים שרתים בעצמם צריכים למפות את כל המקומות שבהם רצה PHP, כולל קונטיינרים ותמונות בסיס ישנות שנשכחו, לשדרג לגרסה מתוקנת ולבדוק ביומני השרת אם יש סימנים לניסיונות חדירה. כדאי גם לוודא שכלי ניטור ומערכות הגנה ליישומי ווב קיבלו את החתימות העדכניות. אלה לא מחליפים את העדכון, אבל יכולים לזהות ניסיונות תקיפה.
