פרצות קריטיות ב-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 ההולנדי.

למה אתר שנפרץ של פרויקט הוא שאלה של אמון ולא רק של טכנולוגיה

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

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