חזרה לבלוג

PHP2Shell: מה צריך לעשות
מנהל הגנת פרטיות

התראת אבטחה PHP2Shell: שתי חולשות קריטיות להרצת קוד מרחוק, CVE-2026-109618 ו-CVE-2026-109619

מה פרסם צוות PHP

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

  • CVE-2026-109618 — טיפול בחוסר זיכרון (OOM) עלול להפריע ל-PHP כשנתוני הבקשה מאותחלים רק בחלקם, וניקוי הבקשה עלול להתייחס לנתונים הלא תקינים כאל תקינים
  • CVE-2026-109619 — מצב פנימי השייך לבקשה עלול לשרוד אחרי שהזיכרון שלו שוחרר, ובקשה מאוחרת יותר באותו תהליך עובד עלולה להשתמש בו
  • דירוג: לפי ההודעה המקדימה של צוות PHP, שתי החולשות דורגו CVSS v4.0 9.2
  • מי חשוף: כל התקנת PHP שמשרתת בקשות אינטרנט, כולל PHP-FPM, Apache עם mod_php, php-cgi, FrankenPHP ו-LiteSpeed. צוות PHP מעריך את הסיכון כגבוה ביותר ב-mod_php, שבו הודגמה תקיפה שבה בקשה אחת ללא אימות מפעילה את הפגיעות עוד לפני שקוד האפליקציה רץ
  • הגרסאות המתוקנות: 8.5.12, 8.4.27, 8.3.36 ו-8.2.35

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

למה זה אירוע פרטיות ולא רק אירוע IT

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

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

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

מה הדין אומר: תקנות אבטחת מידע

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

  • תקנה 13(ג) — עדכון מערכות המאגר: נמנית בקבוצה ב, 40,000 ש"ח למאגר ברמת אבטחה בינונית ו-160,000 ש"ח ברמה גבוהה
  • תקנה 11(א) — תיעוד אירוע אבטחת מידע: נמנית בקבוצה ב
  • תקנה 11(ד)(1) — דיווח לרשות על אירוע אבטחה חמור: נמנית בקבוצה ג, 80,000 ש"ח ברמה בינונית ו-320,000 ש"ח ברמה גבוהה
  • תקנה 15(א) — בקרה ופיקוח על גורם חיצוני (מיקור חוץ): נמנית בקבוצה ג

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

מה מנהל הגנת פרטיות צריך לעשות עכשיו

הצעדים הבאים הם המלצות מעשיות:

  1. מפו ספקים ושרשרת אספקה. פנו לספקי ה-IT, מנהלי התשתיות, בתי התוכנה וחברות האחסון שמנהלים את נכסי האתר של הארגון, וודאו שהשרתים נבדקו (איסוף עדויות מספקים)
  2. דרשו עדכון גרסה מיידי. שדרגו לגרסאות המתוקנות או התקינו תיקון (backport) רשמי מספק ההפצה. אחרי העדכון הפעילו מחדש את שרתי ה-Web. גרסאות 8.1 ומטה אינן מקבלות עוד עדכונים מפרויקט PHP, ולכן פנו לספק לקבלת תיקון או שדרגו
  3. הגבילו תקשורת יוצאת (egress filtering) ככל שהתהליכים בשרת מאפשרים זאת. זה אמצעי לצמצום נזק ולמניעת חיבור חזרה של תוקף לשרת, ואינו פותר את החולשה עצמה
  4. בדקו לוגים. וודאו מול צוות האבטחה שלא נוצלה החולשה לפני העדכון, כדי לשלול תנועה רוחבית או אירוע דליפה שמחייב טיפול ודיווח

אם אי אפשר לעדכן מיד

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

  • CVE-2026-109618: להגדיר memory_limit=-1 באופן שאפליקציות לא יכולות לעקוף, להגדיר post_max_size נמוך (8M לאפליקציה בלי העלאת קבצים, 32M כשנדרשת העלאה), ולאכוף מגבלות גודל בקשה בשרת ה-Web או בפרוקסי
  • CVE-2026-109619: להגדיר session.upload_progress.enabled=0 ולהפעיל מחדש את כל התהליכים העובדים. זה חוסם את הנתיבים שאושרו, ולא וריאנטים אחרים

פירוט מלא בהודעת צוות PHP ובמסמכי האבטחה (advisories) שהיא מפנה אליהם.

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

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

שאלות נפוצות

מהו PHP2Shell?
PHP2Shell הוא הכינוי לשתי חולשות קריטיות בליבת PHP, CVE-2026-109618 ו-CVE-2026-109619, שלפי צוות PHP עלולות לאפשר הרצת קוד מרחוק ללא אימות. שתיהן דורגו CVSS v4.0 9.2.

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

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

האם חייבים לדווח לרשות להגנת הפרטיות על PHP2Shell?
לפי מדריך הרשות להגנת הפרטיות, אי-דיווח לרשות על אירוע אבטחה חמור (תקנה 11(ד)(1) לתקנות אבטחת מידע) הוא הפרה שניתן להטיל עליה עיצום כספי. אם מתברר שהחולשה נוצלה במאגר שלכם, יש לבחון עם ייעוץ משפטי אם האירוע נחשב חמור.

להרחבה המדריך המלא לתיקון 13 לחוק הגנת הפרטיות וניהול גורמים חיצוניים ושרשרת האספקה.

מקורות

  1. מדריך לתיקון מס' 13 לחוק הגנת הפרטיות — gov.il, הרשות להגנת הפרטיות, מאי 2025

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

מאמרים קשורים

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

רוצים לעשות סדר בספקים ובמאגרי המידע?

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

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