פרצות קריטיות ב-PHP: בדקו את האתר של העסק או היוזמה שלכם

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

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

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

מה בדיוק נמצא

יש שתי חולשות, שתיהן בדירוג 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 ההולנדי.

למה "יש לי אתר קטן" לא עוזר כאן

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

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

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

מה לעשות — שלב אחר שלב

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