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

מה החולשה?

כשל בהקצאת זיכרון הוא מצב שתוכנה צריכה לצאת ממנו מהר, בלי להמשיך לעבוד על בקשה שאין לה במה להחזיק אותה. PHP עושה את זה בעזרת longjmp, מנגנון בשפת C שקופץ בחזרה לנקודה שנשמרה מראש בהרצה ומדלג על כל מה שביניהן.

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

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

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

כלומר החולשה דורשת עבודה. לפי הקטלוג של CISA, מישהו כבר עשה אותה.

מי מושפע?

לפי רשימת הגרסאות ברשומה: כל מה שלפני 8.2.35, הקו של 8.3 לפני 8.3.36, הקו של 8.4 לפני 8.4.27, והקו של 8.5 לפני 8.5.12.

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

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

מאז הפרסום הראשון גדלה רשימת המוצרים ברשומה, והיא כוללת כיום גם רכיבי תשתית שמריצים PHP בתוכם: PAN-OS של פאלו אלטו בענף 10.2, מגרסה 10.2.0 ועד 10.2.11, בהתקנות Panorama, וגם RUGGEDCOM APE1808 של סימנס. מי שמחזיק רכיב כזה אינו רואה גרסת PHP בשום פאנל ואינו מעדכן אותה בעצמו, והנקודה הזאת חוזרת בהמשך.

האם מנוצלת בפועל?

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

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

מה שהקטלוג אינו אומר הוא מי התוקפים, מה הם עשו ואיפה. הרשומה מצביעה על הודעת האבטחה של צוות php-src ועל שתי פניות לרשימת התפוצה oss-security, מה-21 וה-23 באוקטובר, ואלה פרסומים של מי שעסק בחולשה ובתיקון שלה. תיאור של הניצול בשטח עצמו אינו מופיע בהם.

מה עושים?

בררו קודם מה רץ אצלכם. בשורת הפקודה על השרת, הפקודה php -v מדפיסה את הגרסה. בפאנל הניהול של חברת אחסון יש בדרך כלל מסך שבו בוחרים את גרסת PHP לכל אתר, והמספר מופיע שם.

העדכונים שסוגרים את החולשה הם 8.2.35, 8.3.36, 8.4.27 ו-8.5.12. עברו לזה שמתאים לקו שאתם עליו, וזו פעולה שבפאנל אחסון היא בדרך כלל בחירה מתפריט.

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

מי שמריץ את PHP בתוך רכיב תשתית אינו מעדכן אותו בעצמו. שם התיקון מגיע כעדכון מהיצרן, והרשומה אינה נוקבת בגרסה מתוקנת לרכיבים האלה. ההודעה של סימנס על RUGGEDCOM APE1808 נמצאת בפורטל ה-CERT שלה, ומי שמחזיק Panorama צריך את ההודעה של פאלו אלטו לענף שהוא נמצא עליו.

הפרטים הרשמיים על החולשה עצמה נמצאים בהודעת האבטחה של php-src. ואם האתר מתארח אצל ספק ואין בפאנל גרסה מעודכנת, זו שאלה לספק, ושווה לשאול אותה בשם המדויק: האם הגרסה שמותקנת כוללת את התיקון ל-CVE-2026-109618.