שני חורים ב-PHP בדירוג 9.2: מה זה אומר לעסק וכמה עולה הדחייה

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

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

מה בדיוק נמצא

יש שתי חולשות, שתיהן בדירוג 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 ההולנדי.

כמה זה עולה לחברה

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

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

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

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

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: אין לדחות את העדכון".