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

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

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

מה בדיוק נמצא

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

מדוע זו שאלה של חוסן דיגיטלי של הקהילה ולא של אתר בודד

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

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

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

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

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