עדכון PHP דחוף: שתי חולשות שמאפשרות להריץ קוד בשרת בלי הזדהות
אם האתר שלכם רץ על PHP, כמו כל אתר וורדפרס, זה הזמן לבדוק באיזו גרסה הוא נמצא. ב-21 באוקטובר 2026 פרסם פרויקט PHP ארבע גרסאות אבטחה: 8.5.12, 8.4.27, 8.3.36 ו-8.2.35. הן סוגרות שתי חולשות קריטיות שעלולות לאפשר לתוקף להריץ קוד בשרת, בלי להתחבר ובלי שום הרשאה.
צוות האבטחה של PHP לא משאיר הרבה מקום לפרשנות: עדכון הוא הפתרון המלא היחיד, ואין אמצעי הקלה שמחליפים אותו.
על מה מדובר: CVE-2026-109618 ו-CVE-2026-109619, שתיהן בדירוג 9.2 בסולם CVSS v4.0. המקור: הודעת האבטחה הרשמית של php.net מ-21 באוקטובר 2026.
שתי חולשות, אותה תוצאה
המנגנון שונה, אבל שתי החולשות מובילות לאותו מקום: הרצת קוד מרחוק ללא אימות. ההבדל ביניהן הוא באיזה רגע PHP מאבדת שליטה על הזיכרון.
CVE-2026-109618 – כשהזיכרון נגמר באמצע הבקשה. החולשה מתעוררת במצב של OOM, כלומר חוסר זיכרון. הטיפול בחוסר הזיכרון עלול לקטוע את PHP בזמן שנתוני הבקשה הפנימיים מאותחלים רק חלקית. בשלב הניקוי, PHP עלולה להתייחס לנתונים הפגומים כאילו הם תקינים, וכך נוצרת השחתת זיכרון שמאפשרת הרצת קוד.
CVE-2026-109619 – שארית מבקשה קודמת. כאן הבעיה היא מצב פנימי ששייך לבקשה מסוימת ושורד גם אחרי שהזיכרון שמאחוריו שוחרר. בקשה מאוחרת יותר שמטופלת באותו worker עלולה להשתמש במצב הישן, לפני שהאתחול הרגיל מספיק לאפס אותו.
את הפרטים הטכניים המלאים פרסמה PHP בהודעות ב-GitHub: CVE-2026-109618 ו-CVE-2026-109619.
למה mod_php בראש רשימת הסיכון?
כל התקנת PHP שמשרתת בקשות אינטרנט חשופה, בלי קשר לאופן ההרצה. זה כולל PHP-FPM, Apache עם mod_php, php-cgi, FrankenPHP ו-LiteSpeed.
PHP מעריכה שהסיכון הגבוה ביותר הוא ב-mod_php, ויש לכך סיבה מוחשית: נגדו כבר הודגם ניצול. בהדגמה, בקשה ללא אימות מפעילה את התקיפה עוד לפני שמתבצעת שורה אחת מקוד האפליקציה.
המשמעות המעשית: הגנות שרצות בתוך האתר עצמו לא מגיעות לשלב הזה. את הבעיה סוגרים ברמת השרת.
יום אחד של התראה מראש
PHP הודיעה על המהדורה יום לפני שיצאה. ב-20 באוקטובר 2026 פורסמה הודעה מקדימה על מהדורת אבטחה ליום רביעי, 21 באוקטובר, בשעה 14:00 UTC (17:00 שעון ישראל), עבור שתי חולשות קריטיות בדירוג 9.2. הפרויקט שמר לעצמו את הזכות להקדים את הפרסום אם פרטי החולשות ייחשפו או אם יתגלו ראיות לניצול פעיל.
למחרת, כמתוכנן, יצאו הודעת האבטחה וארבע הגרסאות המתוקנות.
ומה לגבי תקיפות בפועל? ההודעה לא מדווחת על התקפות בשטח, אבל היא כן מציינת את הניצול שהודגם נגד mod_php. המצב הזה יכול להשתנות מהר, ולכן כדאי לבדוק במקורות מעודכנים מה מצב הניצול היום.
העדכון: מה בודקים ובאיזה סדר
כאן כדאי להשקיע את הזמן, כי זו הדרך היחידה לסגור את החולשות באמת.
- מיפוי. אתרו כל התקנת PHP שמשרתת בקשות אינטרנט, בכל אחד מאופני ההרצה שפירטנו למעלה. התחילו מהשרתים שרצים עם mod_php.
- עדכון לגרסה המתוקנת של הענף. הגרסה הנכונה מופיעה בטבלה למטה. קוד המקור זמין בדף ההורדות של PHP, ושם נמצאים גם קוד מקור ובינאריים ל-Windows.
- חבילות של הספק. הפצות לינוקס וספקי LTS קיבלו את התיקונים מראש, אז שווה לבדוק מול הספק אם כבר יש חבילות מעודכנות. באחסון משותף או מנוהל זה התפקיד של חברת האחסון: פנו אליה וודאו שהשרת כבר עבר לגרסה המתוקנת.
| ענף PHP | גרסה מתוקנת | יומן שינויים |
|---|---|---|
| 8.5 | 8.5.12 | ChangeLog |
| 8.4 | 8.4.27 | ChangeLog |
| 8.3 | 8.3.36 | ChangeLog |
| 8.2 | 8.2.35 | ChangeLog |
שימו לב ל-8.2: הענף מגיע לסוף תמיכה ב-31 בדצמבר 2026 ולא יקבל אחר כך תיקוני אבטחה. מי שמעדכנים עכשיו ל-8.2.35 צריכים כבר לתכנן את השדרוג הבא לגרסה נתמכת.
השרת עדיין על 8.1 או ישנה יותר?
פרויקט PHP כבר לא מעדכן את 8.1 ומטה, אבל עדיין יש שתי דרכים לקבל תיקון:
- דרך הספק. חלק מההפצות וספקי ה-LTS מספקים תיקוני backport. פנו לספק, או שדרגו לגרסה נתמכת.
- בנייה מקוד מקור. למי שבונים בעצמם או שאין להם גישה לספק LTS, צוות האבטחה של PHP פרסם תיקוני backport מינימליים ל-PHP 7.4, 8.0 ו-8.1 (הקישורים בסוף).
מקרה נוסף שדורש תשומת לב הוא המאגר rpms.remirepo.net. המאגר מתוחזק בידי מתנדבים, וביום ההודעה לא היו בו עדכונים. מי שנשענים עליו מתבקשים לעבור לחבילות של ההפצה או לבנות מקוד מקור.
אין אפשרות לעדכן היום? אמצעים זמניים בלבד
האמצעים כאן מצמצמים חשיפה למסלולי תקיפה מסוימים, אבל לפי ההודעה הם לא הופכים התקנה לבטוחה. אלה הגדרות שרת, ולכן באחסון מנוהל את רובן צריך לבקש מחברת האחסון.
נגד CVE-2026-109618 (השחתת זיכרון)
- memory_limit=-1 – רצוי באופן שהאפליקציות לא יכולות לשנות, למשל עם php_admin_value בהגדרות ה-FPM pool או ב-Apache. ודאו שאף הגדרת pool, ספרייה או אפליקציה לא מחזירה מגבלה סופית. ההגדרה מסירה את כשל מגבלת הזיכרון של PHP, אבל כשל הקצאה בסיסי עדיין יכול להגיע למסלול הפגיע.
- post_max_size נמוך – 8M ליישומים בלי העלאת קבצים, 32M אם העלאות נחוצות, ו-upload_max_filesize קטן מ-post_max_size. מומלץ לאכוף מגבלות גם בשרת האינטרנט או ב-proxy: גודל הבקשה המפוענחת, מספר שדות הקלט, מספר חלקי ה-multipart, מספר הכותרות ועומק הקינון, כולל בקשות בלי Content-Length שמיש.
- מגבלת קונטיינר או cgroup כגבול זמינות, רצוי עם מדיניות שהורגת רק את ה-worker שנפגע. לא להחליף אותה ב-RLIMIT_AS או ב-RLIMIT_DATA, כי הם עלולים לגרום בדיוק לכשל ההקצאה הפגיע.
נגד CVE-2026-109619 (מצב שנשאר בזיכרון)
כאן ההגדרות חוסמות מסלולים ספציפיים, ולא את החולשה כולה:
- session.upload_progress.enabled=0 והפעלה מחדש של כל worker. ההגדרה צריכה להיכנס לתוקף לפני עיבוד הבקשה: ב-php.ini, בהגדרות FPM pool או בהגדרות השרת. ini_set או הקובץ .user.ini של FPM לא מספיקים. כך נחסמים מסלולי ה-session שאומתו, אבל לא וריאנטים אחרים.
- fatal_error_backtraces=0 (ב-PHP 8.5 בלבד) והפעלה מחדש של כל worker. זה חוסם רק את מסלול ה-fatal backtrace שאומת.
- ניקוי הגדרות – להסיר הגדרות לא תקינות או הגדרות שהוצאו משימוש, שמוחלות בכל בקשה ומפיקות הודעות אבחון לפני האתחול. הסתרת ההודעות עם error_reporting, display_errors או האופרטור @ לא עוזרת.
- תיקון שגיאות קטלניות וחריגות מזמן הריצה המרבי שתוקף יכול להגיע אליהן, כולל כשלים ב-callbacks, בעיבוד העלאות או ייבוא ובניקוי.
ההגדרות המרכזיות, מרוכזות:
; CVE-2026-109618
memory_limit=-1 ; e.g. php_admin_value in the FPM pool / Apache config
post_max_size=8M ; 32M if file uploads are necessary
; CVE-2026-109619
session.upload_progress.enabled=0
fatal_error_backtraces=0 ; PHP 8.5 onlyמקורות וקישורים
- php.net: הודעת האבטחה הרשמית
- php.net: ההודעה המקדימה על המהדורה
- הודעות GitHub: CVE-2026-109618 · CVE-2026-109619
- הורדות PHP: קוד מקור · קוד מקור ובינאריים ל-Windows
- הודעות המהדורות: PHP 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35
- תיקוני backport: PHP 7.4 · PHP 8.0 · PHP 8.1
