WEBA

ה-WAF של Cloudflare יגן מ-php2shell אך לא מהרצת קוד

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

682 מילים22 עובדות אומתו

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

השמירה על אתרי אינטרנט שמריצים מערכות כמו WordPress הפכה דחופה ברגע שהדלף התרחש. שעות ספורות לפני פרסום התיקונים הרשמיים, החל מהשעה 03:02 לפי שעון UTC ב-21 באוקטובר 2026, Cloudflare הפעילה חוקי הגנה אוטומטיים עבור כלל לקוחותיה. ההגנה הזו נפרסה במסלולים בתשלום ובחשבונות החינמיים, כפי שמפרטת החברה בהודעה הרשמית. עם זאת, מדובר במחסום רשת בלבד.

מגן על המידע, לא על השרת

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

חוקי תגובה יכולים לחסום את תגובת המקור לפני שהיא מגיעה לשולח הבקשה, אך אינם יכולים לבטל פעולות שכבר בוצעו במקור.Cloudflare בבלוג הטכנולוגי

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

שתי תקלות זיכרון עמוקות

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

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

שום שינוי בקבצי התבנית או השבתת תוספים לא ינטרלו את הכשלים האלה. שורש הבעיה נמצא בקוד המקור של שפת הפיתוח עצמה.

השוואת מאפייני החולשות של פרצת php2shell
חולשהתנאי הפעלהכשל זיכרון ב-PHPתוצאה אפשרית
CVE-2026-109618קטיעת בקשה עקב מחסור בזיכרון (OOM)שימוש בנתונים פנימיים שלא אותחלו במהלך ניקוי הזיכרוןקריסת תהליך והרצת קוד שרירותי
CVE-2026-109619שגיאה פטלית שעוצרת את עיבוד הבקשהשימוש במצביעים ישנים לזיכרון שכבר שוחרר בבקשות הבאותדליפת מידע רגיש וגישה לזיכרון לא תקף

התגובה מסגירה את הפריצה

כדי להתמודד עם התקיפות החדשות, החברה השיקה יכולת שנקראת Full Transaction Detection, עליה פרסמה פרטים בניתוח ארכיטקטורה. בדיקה של בקשת ה-HTTP הנכנסת לבדה אינה מספקת תמיד ודאות. מחרוזות שנראות חשודות מופיעות לעיתים קרובות בפעילות לגיטימית, וחסימה גורפת שלהן עלולה לייצר התרעות שווא שישבשו את פעילות האתר.

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

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

אימות ההגנה בארבע לחיצות

אם האתר שלכם מוגדר מאחורי הפרוקסי של Cloudflare, ההגנה מופעלת כברירת מחדל. כדי לוודא זאת בעצמכם, היכנסו ללוח הבקרה ובחרו בנתיב Security ולאחר מכן Security Rules. עבור כלל החשבונות הופעל כלל ברירת המחדל afffe22785674c80a31875c848d2242a ב-Cloudflare Managed Response Firewall Default, בעוד לקוחות חינמיים מקבלים הגנות בקשה תחת Cloudflare Managed Free Ruleset במסגרת מזהה הסט 77454fe2d30c4220b5701f6fdfb893ba. לקוחות במסלולים בתשלום יכולים לוודא שהחוקים במזהה efb7b8c949ac4650a09736fc376e9aee מוגדרים במצב Block כפי שמסבירים בדוקומנטציית המערכת.

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

אפשר לנשום לרגע, אבל מפתח ה-SSH מחכה לכם.

מה לעשות עכשיובדקו שכללי ה-WAF פעילים בממשק Cloudflare, והתקינו עוד היום את עדכון האבטחה הרשמי של PHP בשרת הלינוקס שלכם.

מקורות

הידיעה נכתבה מהמקורות שלמעלה בתאריך הפרסום, וכל טענה בה נבדקה מולם. מצאתם טעות? כתבו.

מה שואלים על זה

האם אתר בחבילה החינמית של Cloudflare מוגן אוטומטית?

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

האם הגנת ה-WAF מבטלת את הצורך לעדכן את גרסת ה-PHP בשרת?

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

האם עדכון של וורדפרס או תוסף ספציפי פותר את חולשת php2shell?

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