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

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

מה התגלה ב-PHP?

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

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

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

איפה AI נכנס לסיפור?

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

ב-2026 חוקרים הצליחו להראות איך אפשר לנצל את הבעיה. OpenAI דיווחה ש-Calif נעזרה במודל GPT-5.6 Sol וש-Wiz מצאה ודיווחה על שתי הפרצות גם במחקר נפרד. צוות PHP הכין את התיקונים ואת הגרסאות המעודכנות.

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

הסרטון עלה לפני הזמן

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

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

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

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

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

ואז הגיעו ההודעות על סגירת אתרים

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

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

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

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

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

ומה קרה בימים שאחרי?

בימים שאחרי פרסום הפרצות נוספו גם עדויות לשימוש בהן. ב-26 באוקטובר הכניסה סוכנות הסייבר האמריקאית CISA את שתי הפרצות לרשימת הפרצות המוכרות כמנוצלות.

Palo Alto Networks מדווחת גם על ניצול נגד ממשקי ניהול של מוצרי PAN-OS שנשארו פתוחים לאינטרנט. לכן כדאי לבקש מאחראי המחשוב לבדוק גם מוצרי תשתית שמשתמשים ב-PHP. עדכון האתר לבדו לא בהכרח מסיים את הבדיקה.

לצד זה יש סימנים שהטיפול מתקדם. בדוח מ-27 באוקטובר דיווחה Wiz על ירידה של כ-67% במספר המכונות החשופות והפגיעות שראתה במדידה שלה. הנתון מתייחס למדידה שלה, והירידה יכולה לנבוע מעדכונים, מסגירת מערכות או מהגבלת הגישה אליהן. הוא אינו מאפשר לדעת מה קרה בכל אתר. את התשובה לגבי האתר שלכם עדיין צריך לקבל מהספק.

מה צריך לבדוק עכשיו באתר שלכם?

נכון לבדיקה ב-28 באוקטובר, PHP הפנתה לתיקונים שפורסמו ב-21 באוקטובר בגרסאות 8.5.12, 8.4.27, 8.3.36 ו-8.2.35. הפרצות מזוהות במספרים CVE-2026-109618 ו-CVE-2026-109619. אפשר להעביר את הפרטים האלה לספק כדי שיאשר שהתיקון המתאים הותקן. חלק מהספקים כוללים אותו בחבילת עדכון משלהם.

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

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

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

קודם מבררים מי אחראי ועל מה

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

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

המדריכים תמיד חינמיים, אבל אם בא לכם להתמקצע - יש גם קורס מקיף לבינה מלאכותית - GenAI Master

לפרטים נוספים לחצו כאן >>

מבקשים לבדוק את האתר שפועל ברשת

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

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

בודקים גם מה קרה לפני העדכון

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

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

ומה אם האתר מחובר גם לכלי AI?

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

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

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

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

אפשר להתחיל בפנייה קצרה לספק:

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

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