English

ההישג: ב־21 באוקטובר 2026, בסביבות 09:30 (ET), פרויקט PHP פרסם תיקונים לשתי פרצות קריטיות של הרצת קוד מרחוק, שזכו לכינוי PHP2Shell. עד 12:21 פלטפורמת המסחר שלנו בפרודקשן כבר רצה על הגרסה המתוקנת. שלב הפרודקשן נמשך 25 שניות, ובדיקת תקינות שפנתה ל־API המסחר החי פעם בשנייה רשמה אפס כשלים לאורך כל התהליך. עוד לפני הפרודקשן, כל שאר המכונות שמריצות אצלנו PHP כבר עודכנו (או, במקומות שבהם ספק פיגר, קיבלו צעדי הגנה זמניים), אומתו ועברו בדיקת תקינות, החל מסביבת הפיתוח. עד סוף היום, כל 11 השרתים וכל 16 התקנות ה־Drupal (פרודקשן, סטייג'ינג ופיתוח) כבר רצו על הגרסאות המתוקנות, וכיסו את 7 מהאתרים והאפליקציות החיים שלנו מבוססי Drupal.

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

מה זה PHP2Shell

PHP2Shell הוא הכינוי לשתי פרצות בליבת PHP, CVE-2026-109618 ו־CVE-2026-109619, בדירוג CVSS v4 9.2 (קריטי). שתיהן מאפשרות הרצת קוד מרחוק. הפרטים דלפו לציבור ב־20 באוקטובר 2026, יום לפני התיקון המתואם, כך שלתוקפים היה יתרון פתיחה, וחברות אבטחה דיווחו עד מהרה על ניסיונות ניצול בשטח. הגרסאות המתוקנות היו PHP 8.5.12, 8.4.27, 8.3.36 ו־8.2.35. לניתוח הטכני המעמיק, ראו הניתוח של Wiz על PHP2Shell.

פרצת RCE קריטית שדלפה, בשפה שמריצה את האתרים שלכם, לא משאירה זמן לישיבות.

ציר הזמן (EDT, 21 באוקטובר 2026)

1. ~12:00 המייסד שלנו שלח הוראה אחת: למצוא, לקרוא ולתקן את כל הצי, מיד.
2. דקות ספורות אחר כך סוכני התפעול משלימים מיפוי של כל מכונה שמריצה PHP, הן מהחבילות של Ubuntu עצמה והן ממאגר PHP של צד שלישי.
3. מעט אחרי 12:00 ועד 12:21 הפריסה מתבצעת בסדר קבוע: קודם פיתוח, אחר כך שאר הצי, והפרודקשן אחרון. כל שלב מאומת לפני שהבא מתחיל.
4. 12:21:05–12:21:30 הפרודקשן מתעדכן ב־25 שניות. לאורך כל הזמן בדיקת תקינות פונה ל־API המסחר החי פעם בשנייה, וכל הבדיקות עוברות.

קראנו את יומן השינויים, לא את מספר הגרסה

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

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

ואז יצאנו לחפש צרות

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

• עצי תהליכים ותהליכי בן לא צפויים של שרת ה־web;
• חתימות קריסה שאופייניות לניצול של השחתת זיכרון;
• דפוסים ביומני הגישה שמזוהים עם סוג התקיפה הזה;
• שלמות הקבצים בתיקיות ה־web root;
• מנגנוני התמדה (משימות מתוזמנות, רשומות הפעלה, חשבונות חדשים);
• חיבורים יוצאים.

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

איפה שספק היה איטי יותר, הפעלנו מיטיגציות זמניות

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

מה שינינו כדי שבפעם הבאה יהיה מהיר יותר

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

1. העדכון האוטומטי מכסה עכשיו גם מאגרי חבילות של צד שלישי, ולא רק את המאגרים של ההפצה עצמה. הפער הזה, יחד עם שרת מראה של ספק שקרס תחת העומס, הוא הסיבה שכמה אתרים נאלצו לחכות.
2. Watchdog לעדכונים תקועים. עדכוני חבילות עלולים להיתקע בשקט ולחסום כל עדכון שבא אחריהם. עכשיו אנחנו מזהים את זה ומתריעים.
3. מעקב אחר פיד CVE נמצא בדרך, כך שהתרעות קריטיות על תוכנה שאנחנו מריצים יגיעו לסוכנים בלי שמישהו יצטרך לקרוא קודם את החדשות.
4. Runbook לסביבות ריצה קריטיות: הרצף המדויק הזה (מיפוי, קריאת יומן השינויים, פריסה שמתחילה בפיתוח, בדיקת תקינות רציפה בפרודקשן, סריקת חדירה, ומיטיגציות זמניות לפי הצורך) מתועד, כך שכל סוכן יוכל להריץ אותו.

איך צוות תפעול מבוסס AI עושה את זה בפועל

אין כאן קסמים, רק מבנה:

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

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

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

האתרים שלנו

אלה האתרים במשפחה שלנו. כל אחד מהם שרץ על סביבת ה־PHP שלנו עודכן באותו יום.

• drupaldeveloper.us: שדרוגים ל־Drupal 11, חילוץ אתרי Drupal 7 והקשחת אבטחה
• god of bots: הכירו את צוות סוכני ה־AI שמאחורי התגובה הזו
• buzzwords.technology: מילות הבאזז של עולם הטכנולוגיה, מוסברות, מפוענחות ונבחרות בקפידה
• buzzwords.news: ניתוח חדשות מבוסס AI, מוגן בפטנט אמריקאי מס' 11,232,363
• buzzword.today: המילה האחת שהחדשות לא מפסיקות לחזור עליה היום
• worldsituation.com: איך מרגישות חדשות העולם ברגע זה, במספר אחד
• foodtron.org: מתכונים, חדשות אוכל והשראה קולינרית
• hamishkan.net: מתכונים יהודיים, מסורות ומורשת קולינרית
• robotrader.io: פלטפורמת המסחר שלנו, המופעלת בידי AI

רוצים את אותו הדבר בשרתים שלכם?

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

דברו איתנו על תפעול מנוהל של Drupal / LAMP · לשירותים שלנו

לקריאה נוספת: god of bots: צוות הבוטים שמאחורי התגובה הזו · $244K אחר כך: למה עזבנו את AWS לטובת חומרה משלנו

מקורות: Wiz: ניתוח טכני של PHP2Shell · Huntress: תגובה מהירה · SecurityWeek: פרצות PHP קריטיות שדלפו · המחקר של Sansec