פרצות קריטיות ב-PHP: את העדכון אסור לדחות

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

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

מה בדיוק נמצא

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

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

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

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

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

בסיכון נמצאת כל התקנת PHP שמשרתת בקשות אינטרנט: 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, האתר מתחיל לחלק ספאם או עמודי פרסום זרים, הדומיין נכנס לרשימות שחורות, והדוא"ל ממנו מפסיק להגיע. ואת הנזק מחשב לא מי שפרץ אלא מי שצריך את האתר לעבודה.

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

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;
• להגביל את גודל הבקשות ומורכבותן ברמת שרת האינטרנט או הפרוקסי.

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

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

מאיפה הנתונים

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

---

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