CVE-2026-109618 ו-CVE-2026-109619: ניתוח שתי פגיעויות קריטיות ב-PHP וסדר התגובה

ב-21 באוקטובר 2026 צוות PHP שחרר עדכונים חריגים, וצוות התגובה האירופי לתקריות סייבר CERT-EU פרסם אזהרה דחופה. שתי הפגיעויות דורגו ב- 9.2 נקודות ומאפשרות להריץ קוד שרירותי על השרת ללא אימות.

מכיוון ש-PHP נותרה השפה הנפוצה ביותר בצד השרת של האינטרנט — עליה פועלים WordPress, Joomla, OpenCart, Bitrix, Laravel ונפח ניכר של אינטגרציות עצמיות עם CRM ומערכות הנהלת חשבונות — מעגל המערכות הנפגעות כולל את רוב הארגונים בעלי נכס אינטרנטי משלהם, ובהם גם מוסדות מחקר וניתוח.

מה בדיוק נמצא

יש שתי חולשות, שתיהן בדירוג 9.2, ושתיהן מובילות לאותה תוצאה — הרצת קוד זר על השרת בלי שום הרשאה.

CVE-2026-109618 — קריסה בעת מחסור בזיכרון

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

CVE-2026-109619 — שאריות של הבקשה הקודמת

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

בסיכון נמצאת כל התקנה של PHP שמשרתת בקשות web: PHP-FPM, Apache עם המודול mod_php, php-cgi, FrankenPHP, LiteSpeed. המסוכן מכולם, לדברי צוות PHP, הוא דווקא השילוב של Apache עם mod_php — הוא עדיין ברירת המחדל באחסונים זולים רבים.

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

אילו גרסאות בסיכון

כל מה שנמוך מהגרסאות האלה — פגיע:

ענף PHP	גרסה בטוחה
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 וגרסאות ישנות יותר	אין תמיכה

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

הערכת הסיכון עבור מוסדות

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

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

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

מה לעשות — שלב אחר שלב

1. בררו את הגרסה שלכם. בלוח הבקרה של האחסון זה הסעיף "גרסת PHP" או "PHP Selector"; בשרת עצמי — הפקודה php -v. חשוב לבדוק את הגרסה שבה האתר עצמו עובד, ולא את זו ששורת הפקודה מציגה: לעיתים קרובות הן שונות.
2. עדכנו בתוך הענף שלכם. מעבר מ-8.2.29 ל-8.2.35 הוא תיקון בתוך אותו ענף: התאימות נשמרת והאתר לא נשבר מזה. אין לבלבל זאת עם מעבר מ-8.2 ל-8.4 — זה כבר דורש בדיקה.
3. אם יש לכם 8.1 או ישנה יותר — לענפים האלה אין תמיכה. בשל חומרת המצב צוות האבטחה של PHP שחרר תיקונים מינימליים גם ל-7.4, 8.0 ו-8.1, וחלק מספקי האחסון מחזיקים גרסאות מהודרות משלהם. אבל ההחלטה הנכונה היא מעבר לענף נתמך, וכדאי לתכנן אותו עכשיו ולא בפעם הבאה.
4. הפעילו מחדש את מנועי העיבוד. בלי הפעלה מחדש של php-fpm או Apache תהליכי העבודה ממשיכים לרוץ על הקוד הישן, והעדכון בפועל לא מתבצע.
5. בדקו את התוצאה. הדרך הפשוטה ביותר היא עמוד זמני עם phpinfo(), שצריך למחוק מיד לאחר הבדיקה, או הסעיף "גרסת PHP" בלוח הבקרה לאחר ההפעלה מחדש.

למשתמשי אחסון לרוב לא יהיה צורך לעשות דבר בידיים: הספקים הגדולים קיבלו את התיקונים מראש ומעדכנים את המכונות שלהם בעצמם. כדאי לכתוב לתמיכה שורה אחת — "האם PHP עודכן לגרסאות מ-21 באוקטובר 2026" — ולקבל תשובה בכתב.

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

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

• לחסום את מיצוי הזיכרון כנקודת כניסה: memory_limit=-1, המוגדר כך שהיישום לא יוכל לדרוס אותו, ובדיקה שאף pool או ספרייה לא מחזירים את המגבלה;
• להקטין את post_max_size — 8M לאתרים בלי העלאת קבצים, 32M אם העלאות נחוצות, ואת upload_max_filesize להחזיק נמוך יותר;
• לכבות את session.upload_progress.enabled ולהפעיל מחדש את כל תהליכי העבודה;
• ב-PHP 8.5 לכבות בנוסף את fatal_error_backtraces;
• להגביל את גודל הבקשות ומורכבותן ברמת שרת ה-web או הפרוקסי.

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

אם גם זה בלתי אפשרי, CERT-EU ממליץ על פתרון פשוט ולא פופולרי: להוציא את השירות הפגיע מהאינטרנט הציבורי עד שהתיקון יותקן וייבדק.

מאין הנתונים האלה

• CERT-EU, Security Advisory 2026-018 "Critical Vulnerabilities in PHP"
• ההודעה על שחרור העדכונים ב-php.net
• התיאור הטכני של CVE-2026-109618 וכן CVE-2026-109619

---

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

מחבר החומר — SmartGT. מקור ראשוני: "חולשות קריטיות ב-PHP: אין לדחות את העדכון".