פרצת אבטחה ב-PHP (PHP2Shell): למה עדכון וורדפרס לא מספיק

ב-21 באוקטובר 2026 פרסם צוות PHP עדכוני חירום שסוגרים פרצת אבטחה ב-PHP שקיבלה את הכינוי PHP2Shell. מדובר בשתי חולשות, CVE-2026-109618 ו-CVE-2026-109619, שמאגדות יחד ארבעה באגים של בטיחות זיכרון. שתיהן קיבלו ציון CVSS v4.0 של 9.2, ושתיהן מאפשרות לתוקף שלא התחבר לשום מקום להריץ קוד על השרת באמצעות בקשות HTTP בלבד (Sysdig).

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

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

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

מה זה PHP2Shell ולמה חולשת ה-RCE ב-PHP מדורגת קריטית

PHP2Shell הוא הכינוי לשתי חולשות של הרצת קוד מרחוק (RCE) בליבת PHP. לפי Elastic Security Labs, שתיהן מדורגות 9.2 בסולם CVSS v4.0, כלומר בדרגת חומרה קריטית. מדובר בפגמים באופן שבו PHP מטפל בזיכרון של בקשה בשלבי האתחול, הטיפול בשגיאות והניקוי.

שתי חולשות, ארבעה באגים

לפי הניתוח של Datadog Security Labs, לכל אחת משתי החולשות יש מנגנון שונה:

• CVE-2026-109618 – באג של מחסור בזיכרון (out-of-memory). אחרי שהקצאת זיכרון נכשלת, PHP משאיר מאחור נתונים לא תקינים ששלב הניקוי ממשיך לעבד.
• CVE-2026-109619 – מאפשר ל-worker של PHP לעשות שימוש חוזר במצב (state) ישן שנשאר מבקשה קודמת.

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

למה הציון כל כך גבוה

שלושה מאפיינים הופכים את החולשות האלה למסוכנות במיוחד:

1. אין צורך בהתחברות – התוקף לא צריך משתמש, סיסמה או הרשאה כלשהי.
2. מספיקה בקשת HTTP – אין צורך באינטראקציה של משתמש או בגישה מקדימה לשרת.
3. היקף עצום – מכיוון שהפגם בזמן הריצה ולא באפליקציה, כל אתר PHP שמגיש בקשות web נמצא בטווח: וורדפרס, Drupal, Joomla, Magento, Laravel ועוד.

לפי Recorded Future, החוקרים של Wiz הדגימו הרצת קוד מרחוק ללא אימות נגד וורדפרס, Drupal ו-Joomla. Sansec, שמתמחה באבטחת חנויות אונליין, מונה גם את Magento, Shopware ו-WooCommerce כמערכות מושפעות.

אילו סביבות הרצה בסיכון

לפי ההודעה של PHP כפי שמסוכמת ב-Kingy.ai, כל אחת מהסביבות הבאות שמגישה בקשות web נחשבת בסיכון:

• PHP-FPM
• Apache mod_php (הוערך כבעל הסיכון הגבוה ביותר)
• php-cgi
• FrankenPHP
• LiteSpeed

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

איך זה התגלה והתגלגל

החולשות התגלו על ידי Wiz Research, בשיתוף Calif ו-OpenAI, ודווחו לצוות PHP באוגוסט 2026. השם PHP2Shell הגיע מ-Wiz (Recorded Future).

התוכנית המקורית הייתה חשיפה מתואמת ב-22 באוקטובר. אבל ב-20 באוקטובר דלפו פרטים בפוסט ב-Hacker News, ובעקבות זאת PHP הודיע מראש על השחרור והקדים אותו ל-21 באוקטובר בשעה 14:00 UTC (Sysdig). ציר הזמן בקצרה:

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

מה עדיין לא ברור

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

• היקף הניצול בפועל – דווחו ניסיונות ניצול לפני ואחרי שחרור התיקון (Amazon Threat Intelligence, watchTowr, Cloudflare), אבל Patchstack דיווחה באותה עת על סריקות ללא פריצות מאומתות (Sodelia).
• איכות ה-PoC הציבוריים – חלק מקודי ההדגמה שפורסמו ברשת מפוקפקים, ו-Elastic ציינה שבזמן הכתיבה לא היה PoC ציבורי אמין.
• יעילות ההקלות הזמניות – המקורות חלוקים בשאלה אם הגדרות php.ini עוזרות (פירוט בהמשך).
• סטטוס חברות האחסון – מצב העדכונים משתנה מהר, ואין במקורות מידע על חברות אחסון ישראליות ספציפיות.

העובדה שאין עדיין PoC ציבורי אמין אינה סיבה להירגע, לאור ההערכה של Sansec לגבי מהירות המתקפות.

למה עדכון וורדפרס לא סוגר את פרצת האבטחה ב-PHP

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

הבקשה הזדונית לא מגיעה בכלל לאפליקציה

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

המשמעות לאתרי וורדפרס:

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

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

PHP2Shell ו-WP2Shell: לא אותו דבר

מקור בלבול נוסף הוא הדמיון בשמות. לפי Meow Apps, WP2Shell הוא סט נפרד של חולשות בוורדפרס עצמו, ואותו כן מתקן עדכון וורדפרס רגיל. החולשות של PHP2Shell, לעומת זאת, דורשות עדכון של PHP בשרת. מי שקרא כותרת על אחד מהשמות ועדכן רק את וורדפרס, ייתכן שסגר רק חצי מהבעיה.

מקור הטבלה: Meow Apps.

אז מי אחראי לעדכון?

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

אילו גרסאות תוקנו בעקבות PHP2Shell ואילו לא

לפי Recorded Future, הגרסאות המתוקנות הרשמיות הן:

מה קורה עם PHP 8.1 ומטה

PHP 5 עד 8.1 פגיעים, אבל הם כבר בסוף חיים (end of life) ולא מקבלים עדכונים רשמיים (DEV). לפי Sansec, הבאגים משפיעים על PHP 5.4 ואילך. צוות PHP פרסם backport מינימלי בקוד מקור עבור 7.4 עד 8.1, אבל צריך לקמפל אותו לבד. לגרסה 7.3 ומטה אין שום תיקון (DEV).

בפועל, לאתר שרץ על PHP 8.1 או ישן יותר יש שלוש אפשרויות:

1. backport מספק או LTS – הפצת לינוקס או ספק תמיכה מורחבת שמספק גרסה מתוקנת.
2. קומפילציה עצמית של ה-backport שפרסם צוות PHP – רלוונטי רק לצוותים עם ניסיון בניהול שרתים.
3. מעבר לענף נתמך – ההמלצה היא לתכנן מעבר ל-8.3 או 8.4 (DEV).

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

מי שעל 8.2: לתקן עכשיו ולתכנן קדימה

אתר שרץ על PHP 8.2 יכול לקבל את התיקון בגרסה 8.2.35. אבל מכיוון שתמיכת האבטחה בענף מסתיימת ב-31 בדצמבר 2026 (Sodelia), כדאי לנצל את ההזדמנות כדי לתכנן כבר עכשיו מעבר לענף חדש יותר, במקום לחזור לאותה נקודה בעוד כמה חודשים בלחץ של חולשה הבאה.

מספר גרסה נמוך לא תמיד אומר שהאתר פגיע

כאן נכנס פרט שמבלבל הרבה מנהלי מערכת. חלק מהפצות הלינוקס מבצעות backport של תיקוני אבטחה בלי לשנות את מספר הגרסה הראשי. לדוגמה, ב-Ubuntu 24.04 החבילה המתוקנת היא 8.3.6-0ubuntu0.24.04.13 (Meow Apps). מספר הגרסה 8.3.6 נראה ישן מאוד בהשוואה ל-8.3.36, אבל החבילה כוללת את התיקון.

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

איך לבדוק גרסת PHP באתר: Site Health, cPanel ושרת

השאלה איך לבדוק גרסת PHP באתר נשמעת פשוטה, אבל יש בה מלכודת: לפי Kingy.ai, גרסת ה-PHP שרצה בשורת הפקודה לבדה אינה מראה את הגרסה שמגישה את האתר. בשרת אחד יכולות להיות מותקנות כמה גרסאות במקביל.

דרך 1: Site Health בוורדפרס

זו הדרך הקלה ביותר לבעלי אתרים ללא גישה לשרת. לפי Tutor LMS, הנתיב הוא:

Tools > Site Health > Info > Server > PHP version

בממשק בעברית: כלים > בריאות האתר > מידע > שרת. הערך שמופיע שם הוא הגרסה שבה וורדפרס רץ בפועל, כלומר הגרסה שמגישה את האתר.

דרך 2: cPanel ו-MultiPHP Manager

באחסון משותף עם cPanel, הכלי MultiPHP Manager מאפשר לבדוק את גרסת PHP שמוגדרת לדומיין (Kingy.ai). אם יש כמה אתרים באותו חשבון, כדאי לבדוק כל דומיין בנפרד, כי ייתכן שאחד מהם עדיין מוגדר לגרסה ישנה.

המלצה כללית: אם הממשק מציג רק את הענף (למשל 8.3) ולא מספר גרסה מלא, יש להשלים את הבדיקה דרך Site Health או לבקש אישור מחברת האחסון שהתיקון אכן מותקן.

דרך 3: בדיקה ישירה בשרת

בשרת VPS אפשר להריץ:

php -v

אבל כפי שמציינים ב-Kingy.ai, הפקודה הזו לבדה לא מראה את מה שמגיש את האתר. כדי לבדוק את גרסת ה-web, אפשר ליצור זמנית קובץ PHP בתיקיית האתר:

<?php echo PHP_VERSION; ?>

גולשים אל הקובץ בדפדפן, רושמים את התוצאה, ומוחקים את הקובץ מיד. כפרקטיקה כללית, לא מומלץ להשאיר בשרת קבצים כמו phpinfo שחושפים מידע על התצורה.

בשרתי Ubuntu או Debian אפשר לראות את מספר החבילה המלא ולהשוות אותו להודעת האבטחה של ההפצה, כפי ש-Meow Apps ממליצה:

dpkg -l | grep php8.3

אחרי העדכון: חובה להפעיל מחדש את PHP

זו טעות נפוצה: התקנת החבילות המעודכנות לא מספיקה. לפי Meow Apps, PHP ממשיך להריץ את הקוד הישן עד שמפעילים אותו מחדש. אחרי ההתקנה צריך לבצע restart או reload ל-PHP-FPM או ל-Apache. בסביבת Docker יש ליצור מחדש את הקונטיינרים מה-image המתוקן.

דוגמאות נפוצות (שמות השירותים משתנים בין הפצות וגרסאות):

# PHP-FPM
sudo systemctl restart php8.3-fpm

# Apache עם mod_php
sudo systemctl restart apache2

# Docker Compose: משיכת image מעודכן ויצירה מחדש של הקונטיינרים
docker compose pull
docker compose up -d --force-recreate

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

צ'קליסט מעשי לבעלי אתרים וסוכנויות בישראל

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

מי שולט ב-PHP באתר

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

צ'קליסט לבעל אתר בודד

1. בדקו את הגרסה ב-Site Health ורשמו את המספר המלא.
2. השוו לטבלת הגרסאות – 8.2.35, 8.3.36, 8.4.27, 8.5.12 ומעלה נחשבות מתוקנות.
3. אם הגרסה נמוכה יותר, פנו לחברת האחסון עם השאלות שבהמשך – ייתכן שמדובר ב-backport של הפצה.
4. אם יש בחירת גרסה ב-cPanel, עברו לענף נתמך מתוקן אחרי גיבוי ובדיקה.
5. אם האתר על PHP 8.1 ומטה, תכננו מעבר בהקדם. אין תיקון רשמי.
6. עדכנו גם את וורדפרס – לא בגלל PHP2Shell, אלא כדי לסגור חולשות נפרדות כמו WP2Shell.
7. תעדו – שמרו צילום מסך של הגרסה ואת תשובת חברת האחסון.

מה לשאול את חברת האחסון

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

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

כמה חברות אחסון בינלאומיות דיווחו על הגנות ביניים. Cloudways הפעילה הגנות זמניות עד ל-PHP מתוקן, DreamHost דיווחה על הגנות בכל הפלטפורמות, ו-Flywheel על הגנה ברמת ה-CDN לצד עדכונים מתגלגלים (Meow Apps). זה צעד חיובי, אבל לא סוף הסיפור. סטטוס חברות האחסון הישראליות לא מכוסה במקורות, ולכן כדאי לבקש אישור בכתב מכל ספק.

צ'קליסט לסוכנויות שמנהלות עשרות אתרים

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

1. מלאי (inventory) – בנו טבלה של כל אתרי הלקוחות: דומיין, ספק אחסון, סוג אחסון, גרסת PHP מדויקת, מי שולט ב-PHP.
2. סיווג לפי שליטה – הפרידו בין אתרים שבהם לסוכנות יש גישת שרת (VPS, Docker) לבין אתרים שבהם רק חברת האחסון יכולה לעדכן.
3. טיפול מיידי בשרתים בשליטתכם – עדכון חבילות, הפעלה מחדש של PHP-FPM או Apache, אימות דרך הדפדפן.
4. פנייה מרוכזת לכל ספק – שלחו לכל חברת אחסון את רשימת השאלות ובקשו אישור בכתב לכל חשבון.
5. סימון אתרים על ענפים ישנים – אתרים על PHP 8.1 ומטה מקבלים עדיפות עליונה ותוכנית מעבר.
6. עדכון לקוחות – הסבירו בקצרה שהחולשות אינן בוורדפרס, ושהעדכון תלוי בספק האחסון. זה חוסך בלבול ומנמק עבודה נוספת.
7. ניטור – הגדירו מעקב אחרי סימני הפריצה שמפורטים בהמשך.
8. החלטה על אתרים שלא ניתן לעדכן – ה-NCSC הבריטי המליץ לשקול להוריד מהרשת כל מערכת שלא ניתן לעדכן מיד (Sodelia).

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

הקלות זמניות, זיהוי ניסיונות ניצול ומה לנטר

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

השוואת אפשרויות ההגנה

מקורות הטבלה: Datadog, Meow Apps, Sansec.

הגדרות php.ini: מה Sansec מציעה ולמה Datadog חולקת

Sansec מציעה כצעד זמני את שתי ההגדרות הבאות, תוך הדגשה שאין בהן ערובה:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

לעומתה, Datadog קובעת שרק עדכון מתקן את הבאגים, ושהקלות שהופצו בקהילה כמו session.upload_progress.enabled=0 לא מגינות. בנוסף, לפי Sansec, ההגדרה session.use_strict_mode לא משפיעה כשהסשנים נשמרים ב-Redis או במסד נתונים.

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

הגנות קצה וצמצום חשיפה

לפי הסיכום של Kingy.ai, צעד ביניים בטוח יותר הוא הגבלת גישה ברמת ה-proxy או קצה הרשת, או הורדת השירות מהאוויר. כמה כיוונים מעשיים:

• הפעלת חוקי WAF של Cloudflare או ספק CDN אחר, שלפי Meow Apps שוחררו גם לחבילות החינמיות.
• הגבלת גישה לאתרים פנימיים (המלצה כללית) – אתרי staging, מערכות ניהול פנימיות או אתרים ישנים שאינם בשימוש אפשר לחסום לפי IP או מאחורי VPN.
• הורדה זמנית של אתרים נטושים – אתר קמפיין ישן על PHP 7.x שאף אחד לא מתחזק הוא בדיוק סוג המערכת שה-NCSC המליץ לשקול להוריד (Sodelia).

סימני פריצה ומה לנטר

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

• שליחות טפסים גדולות במיוחד – בקשות חריגות בגודלן ביומני השרת.
• שגיאות מיצוי זיכרון בשלב אתחול הבקשה – הודעות על מיצוי זיכרון ביומני PHP שמופיעות עוד לפני שהאפליקציה נטענה.
• תהליכי shell לא צפויים – תהליכים כמו sh או bash שנפתחים תחת משתמש השרת.

Elastic מוסיפה שבסופו של דבר ניצול מתכנס לנקודה אחת: שרת ה-web או worker של PHP שמפעיל shell.

צעדים שנגזרים ישירות מהאינדיקטורים האלה:

1. סרקו את יומני השגיאות של PHP לתקופה שמה-20 באוקטובר ועד מועד ההתקנה בפועל, וחפשו שגיאות זיכרון בשלב האתחול ובקשות טופס חריגות.
2. אם יש כלי EDR או ניטור תהליכים, הגדירו התראה על shell שנפתח מתהליך של php-fpm, apache2 או httpd.

מעבר לכך, הצעדים הבאים אינם מופיעים במקורות הספציפיים ל-PHP2Shell, אלא מבוססים על פרקטיקה כללית של תגובה לאירועי אבטחה באתרי וורדפרס:

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

שאלות נפוצות

האם עדכון וורדפרס מתקן את PHP2Shell?

לא. הבאגים נמצאים במנוע PHP, ולכן צריך לעדכן את PHP בשרת. עדכוני וורדפרס, תבניות, תוספים ותוספי אבטחה לא מתקנים אותם (Meow Apps). עם זאת, כדאי לעדכן את וורדפרס בנפרד כדי לסגור את WP2Shell, שהוא סט חולשות נפרד.

איך לבדוק גרסת PHP באתר?

בלוח הבקרה של וורדפרס: כלים > בריאות האתר > מידע > שרת. ב-cPanel: דרך MultiPHP Manager. גרסת ה-PHP של שורת הפקודה לבדה לא מראה את הגרסה שמגישה את האתר (Kingy.ai).

אילו גרסאות PHP נחשבות מתוקנות?

8.2.35, 8.3.36, 8.4.27 ו-8.5.12 ומעלה. גרסאות ישנות יותר מתוקנות רק אם חברת האחסון או הפצת הלינוקס ביצעו backport, ולכן מספר נמוך בחבילת הפצה עשוי עדיין לכלול את התיקון (Meow Apps).

מה עושים אם האתר רץ על PHP 8.1 או ישן יותר?

אין גרסה רשמית מתוקנת. האפשרויות הן backport מספק או מתמיכת LTS, קומפילציה עצמית של ה-backport שפרסם צוות PHP (רלוונטי ל-7.4 עד 8.1 בלבד), ובכל מקרה תכנון מעבר ל-8.3 או 8.4 (DEV).

חברת האחסון אמרה שיש הגנת חומת אש. זה מספיק?

לא. הגנה ברמת חומת האש או ה-CDN היא פתרון ביניים, אבל היא לא שווה ערך ל-PHP מעודכן (Meow Apps). יש לבקש אישור מפורש שהתיקון לשתי החולשות הותקן ומתי.

יש פתרון עוקף אם אי אפשר לעדכן היום?

Sansec מציעה שתי הגדרות php.ini, אבל מגדירה אותן כחסרות ערובה, ו-Datadog קובעת שהגדרות כאלה לא מגינות. צעד בטוח יותר הוא הגבלת גישה ברמת ה-proxy או קצה הרשת, או הורדת השירות מהאוויר עד לעדכון (Kingy.ai).

סיכום

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

הפתרון היחיד ש-Datadog מגדירה כמתקן באמת הוא עדכון PHP לגרסה מתוקנת (8.2.35, 8.3.36, 8.4.27, 8.5.12 ומעלה, או backport מאומת של ההפצה), ולאחריו הפעלה מחדש של PHP ואימות דרך הדפדפן. אתרים על PHP 8.1 ומטה נמצאים בסיכון מוגבר, כי אין להם תיקון רשמי, ואתרים על 8.2 צריכים לתכנן מעבר לפני סוף 2026.

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

מקורות

• Sysdig: PHP2Shell detection
• Recorded Future: PHP2Shell Exploitation
• Elastic Security Labs: php2shell detection coverage
• Datadog Security Labs: PHP2Shell
• Sansec: Critical PHP RCE
• Kingy.ai: PHP2Shell Emergency Guide
• Meow Apps: PHP2Shell on WordPress
• DEV: Patch Your PHP
• Sodelia: PHP2Shell WordPress guide
• Tutor LMS: Secure WordPress from PHP2Shell