Michael Johnsonב-21 באוקטובר 2026 הודיעה PHP על שתי פרצות קריטיות שעלולות לאפשר הרצת קוד מרחוק ללא אימות. באותו יום פרסם הפרויקט תיקונים לענפי הגרסאות 8.5, 8.4, 8.3 ו-8.2, והמליץ למשתמשים לעדכן ללא דיחוי. התקנות שמטפלות בבקשות Web עלולות להיות פגיעות, ובהן PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ו-LiteSpeed, לפי הודעת PHP.
הגרסאות המתוקנות הן PHP 8.5.12, 8.4.27, 8.3.36 ו-8.2.35. העדכונים מתקנים את CVE-2026-109618, הקשורה לפגיעה במצב עקב מחסור בזיכרון, ואת CVE-2026-109619 — שגיאה שבה מצב של בקשה אחת עלול להישמר בתהליך עבודה ולשמש בעת עיבוד הבקשה הבאה. גרסאות מוקדמות יותר מהגרסאות המפורטות פגיעות. הפרויקט אינו מספק עוד עדכונים משלו עבור PHP 8.1 וענפים ישנים יותר, ולכן על מנהלי מערכות כאלה לבדוק אם ספק ההפצה או ספק התמיכה לטווח ארוך מציעים תיקונים.
שגיאות במחזור החיים של בקשת Web
במקרה של CVE-2026-109618, עיבוד בקשה עלול להיעצר בשל מחסור בזיכרון, לפני שהנתונים הפנימיים אותחלו במלואם. במהלך הסיום, PHP עלולה לגשת למצב לא תקין. בהודעת האבטחה מתארים המפתחים, בין היתר, תרחישים הכוללים בקשות multipart ומיצוי של מגבלת הזיכרון. עבור Apache mod_php אושר תרחיש שבו הבעיה מתרחשת עוד לפני שקוד היישום מתחיל לרוץ; PHP מציינת גם שהסיכון בתצורה זו גבוה יותר.
CVE-2026-109619 משפיעה על מצב שתהליך עבודה שומר בין בקשות. אם פעולה מסתיימת בשגיאה לפני ניקוי הנתונים, הזיכרון של הבקשה הקודמת משתחרר, אך מצביע אליו נשאר. בקשה הבאה שמטופלת באותו תהליך עלולה לגשת למצב שהתיישן לפני האתחול הרגיל. בהודעת האבטחה של הפרויקט מתארת PHP מסלולים שאושרו, דרך פעולות אבחון מוקדמות וטיפול בהתקדמות של העלאת קבצים; מידת הישימות של כל מסלול תלויה בתצורה, ביישום ובהרחבות שבהן נעשה שימוש.
שתי הפרצות קיבלו ציון 9.2 לפי CVSS 4.0. לפי PHP, ההשפעה שאושרה כוללת הרצת קוד בהרשאות של תהליך העבודה של שרת ה-Web. בהודעת האבטחה על שגיאת המחסור בזיכרון אושר תרחיש HTTP מלא נגד mod_php; לגבי PHP-FPM, המקור מתאר ניתוח קוד ותנאים לפגיעות, ולכן חשוב להבחין בין הנתונים בעת הערכת פריסה מסוימת.
מה על מנהלי המערכת לבדוק
ראשית, בדקו אילו גרסאות PHP מטפלות בפועל בתעבורת Web: בשרת אחד עשויות לפעול התקנות נפרדות של CLI, FPM ו-Apache, ואילו מכלים וצמתים באשכול מתעדכנים בנפרד. התקינו לכל ענף נתמך את הגרסה המתוקנת המתאימה או חבילה של הספק שכוללת תיקון מאומת. לאחר מכן הפעילו מחדש את כל תהליכי PHP ובדקו את הגרסה שלהם לאחר ההפעלה מחדש — החלפת קבצים בלי להפעיל מחדש את התהליכים משאירה תהליכים ישנים פעילים.
עבור PHP 8.1 וגרסאות ישנות יותר, בדקו את מצב התמיכה ואת זמינותו של תיקון לאחור מספק ההפצה או מספק התמיכה לטווח ארוך. אם חבילה כזו אינה זמינה, תכננו מעבר לענף נתמך. PHP מציינת שספקי הפצות Linux קיבלו את התיקונים מראש; מספר הגרסה של החבילה שלהם עשוי להיות שונה ממספר הגרסה הרשמי של PHP, ולכן יש לבדוק אם התיקון אכן נכלל בה.
הגדרות זמניות וסינון בקשות עשויים לצמצם מסלולי תקיפה מסוימים, אך הפרויקט מציין שעדכון הוא הדרך היחידה לתקן את שתי הבעיות במלואן. העדיפות המעשית לצוותים היא למפות את כל תהליכי העבודה של Web, להתקין את החבילה המתוקנת, להפעיל מחדש את התהליכים ולוודא את התוצאה בכל צומת. כך מטפלים בפרצות שאושרו, במקום להסתמך רק על תצורת שרת ה-Web.