כדי להגיע לחולשה הזאת צריך קודם להוציא את PHP ממצב שבו נשאר לו זיכרון להקצות. זה נשמע כמו מכשול, ולפי הרשומה יש כמה דרכים להביא את השרת לשם באופן עקבי. מה שקורה אחרי זה, בתוך הליך הניקוי של הבקשה, יכול להסתיים בהרצת קוד. הציון 9.2 מתוך 10.
מה החולשה?
כשל בהקצאת זיכרון הוא מצב שתוכנה צריכה לצאת ממנו מהר, בלי להמשיך לעבוד על בקשה שאין לה במה להחזיק אותה. PHP עושה את זה בעזרת longjmp, מנגנון בשפת C שקופץ בחזרה לנקודה שנשמרה מראש בהרצה ומדלג על כל מה שביניהן.
הדילוג הזה הוא מקור הבעיה, כי קוד שקפצו מעליו אינו מסיים את מה שהתחיל. לפי הרשומה, חלק מההקשרים ב-PHP אינם לוקחים את התרחיש הזה בחשבון, ומשאירים את זיכרון הבקשה במצב לא מאותחל לפני שהם מבצעים הקצאה. אחר כך מגיע הליך הניקוי של אותה בקשה, קורא מאותו זיכרון או מסתעף לפי מה שכתוב שם, ומתייחס למה שנשאר בו כאילו היה מידע תקין שהוא עצמו כתב.
הרשומה מסמנת את הכשל CWE-416, שימוש בזיכרון אחרי שחרורו, וכותבת שכמה אסטרטגיות שונות של מיצוי זיכרון מגיעות למצב הזה בעקביות ושהתוצאה היא הרצת קוד מרחוק.
ושווה לעצור על הציון, כי הוא מספר משהו שאפשר לפספס. 9.2 ולא 9.8, והווקטור מסביר למה: מורכבות התקיפה מסומנת שם כגבוהה, ובנוסף מסומן שקיימות דרישות מוקדמות לתקיפה. במילים פשוטות, הרשומה אומרת שהתוקף תלוי בתנאים שאינם כולם בידיו, והבאת השרת למצב של חוסר זיכרון היא בדיוק תנאי כזה.
זה אינו הופך את החולשה לתיאורטית. זה אומר שהיא דורשת עבודה.
מי מושפע?
לפי רשימת הגרסאות ברשומה: כל מה שלפני 8.2.35, הקו של 8.3 לפני 8.3.36, הקו של 8.4 לפני 8.4.27, והקו של 8.5 לפני 8.5.12.
PHP אינו תוכנה שמשתמש מתקין על המחשב שלו. זאת השפה שמריצה חלק גדול מהאתרים שאתם נכנסים אליהם מדי יום, ובכלל זה כל אתר שבנוי על וורדפרס. מי שמושפע כאן אינו הגולש אלא מי שמחזיק את השרת שמריץ את הקוד.
ולרוב בעלי האתרים בישראל זה אומר דבר אחד מעשי: הגרסה שרצה אצלכם נקבעת אצל חברת האחסון, והיא זו שמתקינה את העדכון. מי שמריץ שרת משלו, או מכונה וירטואלית שהוא האחראי עליה, צריך לעשות את זה בעצמו.
האם מנוצלת בפועל?
CISA, סוכנות הסייבר האמריקאית, לא הכניסה את החולשה לקטלוג ה-KEV שלה, זה שמרכז חולשות עם ניצול מתועד בשטח. לא ידוע על ניצול.
ברשימת המקורות של הרשומה אפשר לראות איך הגילוי התגלגל לציבור: הודעת האבטחה של צוות php-src עצמו, רשומה בבלוג של חברת האבטחה Wiz, ופנייה לרשימת התפוצה oss-security. שלושתם פרסומים מסודרים של מי שעסק בנושא, ולא עקבות של תקיפה שנמצאה בשטח.
הרשומה עלתה ל-NVD ב-21 באוקטובר 2026.
מה עושים?
בררו קודם מה רץ אצלכם. בשורת הפקודה על השרת, הפקודה php -v מדפיסה את הגרסה. בפאנל הניהול של חברת אחסון יש בדרך כלל מסך שבו בוחרים את גרסת PHP לכל אתר, והמספר מופיע שם.
העדכונים שסוגרים את החולשה הם 8.2.35, 8.3.36, 8.4.27 ו-8.5.12. עברו לזה שמתאים לקו שאתם עליו, וזו פעולה שבפאנל אחסון היא בדרך כלל בחירה מתפריט.
אם אתם מתחת לקו 8.2, שימו לב שהרשומה מסמנת את כל מה שלפני 8.2.35 כמושפע ואינה מצביעה על גרסה מתוקנת בקו שאתם נמצאים בו. המעבר הנדרש שם הוא לאחת מארבע הגרסאות שלמעלה, וזה שינוי שכדאי לבדוק מול האתר לפני שמבצעים.
הפרטים הרשמיים נמצאים בהודעת האבטחה של php-src. ואם האתר מתארח אצל ספק ואין בפאנל גרסה מעודכנת, זו שאלה לספק, ושווה לשאול אותה בשם המדויק: האם הגרסה שמותקנת כוללת את התיקון ל-CVE-2026-109618.