לקחי PHP2Shell: איך להתכונן לפרצות הבאות

ב-17 באוקטובר, רשת ה-honeypot של Amazon רשמה ניסיון ניצול PHP2Shell מכתובת IP אנונימית. עם זאת, נותרו עוד ארבעה ימים עד לחשיפה לציבור.

כאשר PHP פרסמו את התיקונים ב-21 באוקטובר, הפרטים הטכניים כבר דלפו, ניצולי Proof-of-Concept הופצו באופן נרחב, וניסיונות ניצול נוספים נרשמו ללא הרף. הבעיה הייתה שמדובר בשתי פגיעויות קריטיות של ביצוע קוד מרחוק (RCE) ללא אימות במנוע ה-PHP עצמו (CVE-2026-109618 ו-CVE-2026-109619, שתיהן עם ציון CVSS v4.0 של 9.2) — מה שאנחנו מכירים כיום בשם PHP2Shell.

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

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

מדוע ⁦PHP2Shell⁩ הייתה בעיה עבור צוותים עם קוד נקי?

ובכן, כי הפגיעויות נמצאות מתחת לרמת הקוד. ומה זה אומר? שני ה-CVEs המוזכרים מתרחשים במחזור החיים של הבקשה (request lifecycle) במנוע ה-PHP, מה שהופך אותם לניתנים לניצול עוד לפני שקוד היישום רץ בפועל. ב-Apache, עם mod_php, נדרשה בקשה אחת בלבד ללא אימות כדי לבצע את הניצול.

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

השאלה הייתה לגבי הפעלת יישומים. אותה שאלה שתמיד יתחילו התוקפים איתה.

איזה מלאי אומר לך היכן פועל ⁦PHP⁩?

כל סוג של מלאי אומר לך חלק ממנו.

PHP מגיע לסביבת הייצור באמצעות Dockerfile, חבילת הפצה, תמונת (image) פלטפורמה, או התקנה ידנית. אילוץ "php": ">=8.2" ב-composer.json אומר לך מה האפליקציה מקבלת, אך הגרסה שנפרסת בפועל תלויה באופן שבו היא הותקנה. סריקות קונטיינרים מזהות PHP שהותקן מחבילות הפצה ברגע שהן מפרסמות עדכון אבטחה, אך PHP שהורכב מקוד מקור (compiled from source), כולל בתמונות ה-Docker הרשמיות של PHP, נשאר מחוץ לטווח הראייה הזה. (שוב, הפוסט של צוות המחקר שלנו ממפה בדיוק איזו תצוגה ב-Snyk רואה כל חלק במציאות הזו.)

ואז ישנה מחרוזת הגרסה. VirusTotal מבצעת טביעות אצבע לכ-5.1 מיליון כתובות IP המריצות PHP, ורק כ-1.1 מיליון מהן מציגות את הגרסה שלהן, כך שארבע מתוך חמש מסתירות אותה. הסיכום שלהם הוא אחת השורות הטובות ביותר שקראנו בנושא: "אם אתה מחפש רק את מחרוזת הגרסה, אתה רואה רק את החלק הבעייתי שחושף אותה מרצונו".

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

איך נראתה התגובה מבחוץ פנימה?

היתרון המוקדם: לפני השחרור של PHP ב-14:00 UTC ב-21 באוקטובר, ל-Snyk כבר היו עדכוני אבטחה פעילים עבור שני ה-CVEs, כך שפרויקטים מנוטרים קיבלו התראה ברגע שהגרסאות המתוקנות הפכו לידועות. תוך כ-30 דקות מהשחרור, אותם עדכונים כבר כללו טווחי גרסאות מושפעות וגרסאות מתוקנות, ועדכוני הפצה הגיעו ככל שכל מפיץ פרסם אותם. זה כיסה את מה שסריקות Snyk Container ו-Unmanaged יכלו לומר לך.

שלוש שאלות עלו דרך Snyk API & Web:

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

• מישהו יכול לנצל את זה? בתוך 24 שעות מהשחרור של ⁦PHP⁩, פרופיל הסריקה המלא נבדק עבור ⁦PHP2Shell⁩, וצוותים יכלו להריץ את הבדיקה בעצמם כפרופיל מותאם אישית לקבלת מענה מהיר בכל יעד ⁦PHP⁩.

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

אז, Discovery --> בדיקה ממוקדת --> תיקון --> בדיקה חוזרת: בדיקה, תצפית והסקה, מול שעון שרץ כעת בשעות. וזה בדיוק החלק המדאיג ביותר. עבור צוותים שכבר הריצו Snyk API & Web, החלק הקשה נעשה עוד לפני ה-21 באוקטובר: הדומיינים שלהם היו ממופים והאפליקציות הוגדרו כמטרות. כשהבדיקה הייתה זמינה, התגובה דרשה רק פילטר וסריקה מהירה.

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

אם ⁦PHP2Shell⁩ ניתן לזיהוי מבחוץ, מה היה החלק הקשה?

במאי הצגנו את ההבחנה שעליה בנוי COS. פגיעויות שניתנות לזיהוי היוריסטי חושפות את עצמן לכלים דטרמיניסטיים: זריקת מטענים (payloads) על אפליקציה או API רצים, תצפית על התגובות, והסקה. פגיעויות תלויות-הקשר (כמו BOLA, זליגת נתונים בין דיירים (cross-tenant), ובעיות לוגיקה עסקית) לא נושאות חתימה כלל, כי הן קיימות בפער שבין מה שאפליקציה אמורה לעשות לבין מה שהיא עושה בפועל.

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

החשיפה גם המשיכה להשתנות. ב-23 באוקטובר, פרויקט PHP תיאר מעקף חלקי (CVE-2026-115560) שחל כאשר אפליקציה מחליפה את ה-session serialization handler באמצעות ini_set() לפני תחילת הסשן, עם מצב upload progress פעיל. התנאים המוקדמים לכך נדירים, וכל מה שהסקת ביום רביעי עדיין היה זקוק לבדיקה חוזרת ביום שישי. תשובה נקודתית מתיישנת תוך ימים.

למה ⁦PHP2Shell⁩ לא יהיה האחרון?

יש לכך שלוש סיבות. בשל אופי האופן שבו הם נמצאו:

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

• קצב מהיר יותר. Manoj Nair, ה-CTO ו-Chief Innovation Officer של Snyk, תיאר זאת בספטמבר: "סוג הפגם החמור שבינה מלאכותית חושפת כעת בתוכנות פופולריות – סוג הממצא שפעם היה מגיע פעם או פעמיים בשנה ומערער את התוכניות הרבעוניות של כולם – מופיע כעת כמה פעמים בשבוע, לפי מה שאני רואה."

• שעון מהיר הרבה יותר. CJ Moses, ה-CISO של Amazon Integrated Security, הפיק שני לקחים מ-PHP2Shell שרלוונטיים הרבה מעבר למקרה זה. מגינים "לא צריכים להניח שתאריך החשיפה לציבור הוא התאריך המוקדם ביותר של הניצול". וכן, "הזמן מתיקון לניצול עובד מתקצר מסיבות מבניות", כי ניתוח בסיוע AI הופך את התרגום של תיקון (patch diff) או הודעת אבטחה לניצול עובד לזול הרבה יותר. העצה שלו לפגיעויות קריטיות במערכות הפונות לאינטרנט: "מדדו את לוחות הזמנים לתיקון והפחתת סיכונים בשעות."

מה לוקח להיות מוכן לשלב הבא?

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

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

• בודק שנשלח תוך שעות. הפער בין מבחן מייעץ למבחן ריצה הוא החלון של התוקף. למדוד את זה.

• בדיקות חוזרות לפי דרישה. אותה בדיקה ממוקדת, הפעל שוב עד שהתיקון יחזיק מעמד.

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

בתור ⁦for Snyk⁩, כך זה ממפה למה שאנו מציעים.

Snyk API & Web כולל את שלושת הראשונים: Discovery, מנוע שהצוות מעדכן ברגע שמתפרסמות חשיפות, ופרופילים ממוקדים שניתן להריץ ולהריץ שוב. Continuous Offensive Security מוסיף את הרביעי: AI Pentesting מסיק מסקנות לגבי האפליקציה שלך כפי שפנטסטר היה עושה, Agent Red Teaming נכנס לפעולה ברגע שזיהוי מבחין ב-LLM בערימה, ו-Dynamic Testing, המנוע של Snyk API & Web, מכסה את המחלקות ההיוריסטיות מתחת לפני השטח, באופן רציף. במונחי הפלטפורמה שלנו, זהו Validate: תקיפה מתמשכת של האפליקציות שלך כדי להוכיח שהתיקונים החזיקו מעמד ולהראות מה עדיין ניתן לניצול.

ואז יש יציבה. ב-⁦AI⁩ Security ⁦Panel⁩: ללא סינון ב-14 באוקטובר, ⁦Manoj⁩ שאל את השאלה שאנו חוזרים אליה כל הזמן: "כאשר תוקף אוטונומי הולך לתקוף אותך, למה שלא תתקוף את עצמך?" השאלה הזו היא כל הנחת היסוד של ⁦COS⁩. מהצד שלנו, העבודה מצמצמת כל פער בסיפור הזה: מייעוץ לבדיקה הרצה, ומבדיקה לתיקון מאושר.

איפה יופיע הראשון הבא?

איזה מנוע, ומתי, הוא הניחוש של מישהו עכשיו. למקום שבו הוא מופיע ראשון קל יותר להתקשר: ב-⁦URL⁩ שלך. זה המקום שבו הבדיקות שלך כבר אמורות להיות.

רוצה לראות מה תוקף ימצא ב-⁦URL⁩ שלך היום? הזמינו הדגמה של ⁦Evo Continuous Offensive Security⁩ וראו כיצד היא ממפה את משטח ההתקפה שלכם מבחוץ פנימה, מוכיחה אילו ממצאים ניתנים לניצול, ובודקת מחדש עד שהתיקון מתקיים.

אימוץ ⁦AI⁩ מאובטח בקנה מידה

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

קרא עוד

⁦PHP⁩ ⁦Patches Two Critical Unauthenticated⁩ ⁦RCEs⁩ (⁦CVE-2026-109618⁩, ⁦CVE-2026-109619⁩): [⁦Updated⁩ עבור ⁦CVE-2026-115560⁩]

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

הפוך את ה-Backlog של הפגיעויות שלך ל-Pull Requests באמצעות Agentic Remediation

ה-⁦Evo Remediation Agent⁩ נמצא כעת ב-⁦Open Preview⁩, מביא לפתרון תלות אוטומטי ל-⁦Evo Agentic AppSec⁩. צוותי AppSec יכולים כעת להפעיל תיקון מתמשך

AI קורא לכל סיכון שקיבלת על עצמך: שבע תובנות מפאנל אבטחת ה-AI: ללא סינון

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