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

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

לקוחות OCW: אתם לא צריכים לעשות כלום. טיפלנו בזה ב-21/10 בכל האתרים שאנחנו מאחסנים ומתחזקים. הפירוט בהמשך.

מה קרה, בשתי שורות

PHP היא השפה שמריצה את וורדפרס ואת רוב האתרים בעולם. נמצאו בה שתי חולשות (CVE-2026-109618 ו-CVE-2026-109619) שמאפשרות לשלוח לשרת בקשה מיוחדת, שגורמת לו להריץ קוד של התוקף. התיקון יצא בגרסאות PHP 8.5.12, 8.4.27, 8.3.36 ו-8.2.35.

למה זה כל כך חמור

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

  • זה ב-PHP עצמה, לא בוורדפרס. לא משנה איזו גרסת וורדפרס יש לכם, אילו תוספים מותקנים או כמה האתר מעודכן. מה שקובע הוא גרסת ה-PHP בשרת.
  • אין צורך בסיסמה. התוקף לא צריך להתחבר לאתר. מספיקה בקשה אחת (או סדרה של בקשות) מבחוץ.
  • זה פוגע כמעט בכל שרת. לפי ההודעה הרשמית של PHP, בסיכון נמצאת "כל התקנת PHP שמגישה בקשות ווב", כולל PHP-FPM, אפאצ'י עם mod_php, php-cgi, LiteSpeed ו-FrankenPHP. הסיכון הגבוה ביותר הוא ב-mod_php, שם הודגם ניצול שקורה עוד לפני שקוד האתר מתחיל לרוץ.
  • שתי החולשות דורגו 9.2 מתוך 10 (בשיטת הדירוג CVSS 4.0). ראיתי ברשת גם ציון 10, אבל הציון הרשמי בהודעת PHP הוא 9.2.
  • יש קוד תקיפה פומבי, ויש ניסיונות ניצול. חברת האחסון Wordify דיווחה שמ-11:44 בבוקר (שעון ישראל) ב-21/10 הגיעו לאתרי וורדפרס אצלה בקשות תקיפה שמבוססות על קוד ניצול פומבי, ושמאז הצהריים סורקים אוטומטיים בודקים מספר גדול של אתרים. גם צוותי אבטחה נוספים דיווחו על ניסיונות תקיפה ראשונים. נכון לכתיבת שורות אלה לא מצאתי דיווח מאומת על אתרים שנפרצו בפועל, אבל כשקוד התקיפה זמין לכולם, סביר שהניסיונות רק יתרבו.

מה תוקף יכול לעשות אם הצליח

הרצת קוד על השרת היא כמו לקבל את המפתח לבית. התוקף רץ בהרשאות של שרת האתר, ומשם הוא יכול:

  • לקרוא את קובץ ההגדרות של וורדפרס (wp-config.php) ולקבל את הסיסמה למסד הנתונים, ואיתה את כל המידע באתר: משתמשים, הזמנות, פניות מטפסים.
  • להשתיל דלת אחורית (backdoor) שתאפשר לו לחזור גם אחרי שתעדכנו.
  • להזריק ספאם, הפניות לאתרים זדוניים או קוד שגונב פרטי תשלום בחנות.
  • להשתמש בשרת שלכם כדי לתקוף אחרים או לשלוח ספאם, מה שעלול להוביל להשבתה על ידי חברת האחסון ולסימון האתר בגוגל.

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

צעד ראשון: לבדוק איזו גרסת PHP מריצה את האתר

יש שלוש דרכים פשוטות:

  1. מתוך וורדפרס: בלוח הניהול נכנסים ל"כלים" ואז "בריאות האתר" (Site Health), לשונית "מידע", ופותחים את החלק "שרת". שם מופיעה גרסת ה-PHP.
  2. מלוח הבקרה של האחסון: ב-Plesk, cPanel, Cloudways ודומיהם יש מסך PHP לכל אתר, שבו רואים את הגרסה הפעילה.
  3. לשאול את חברת האחסון: אם אין לכם גישה, שלחו להם שאלה קצרה: "איזו גרסת PHP מריצה את האתר שלי, והאם היא כוללת את התיקון ל-CVE-2026-109618 ול-CVE-2026-109619?"

איך לקרוא את התוצאה:

  • 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, 8.0 ו-7.4: אין גרסה רשמית חדשה. יש רק תיקון בקוד מקור, וחלק מחברות האחסון מכניסות אותו לחבילות שלהן.
  • PHP 7.3 ומטה, כולל 5.6: אין תיקון רשמי בכלל.

הערה חשובה: בשרתים שמשתמשים בחבילות של הפצת לינוקס (אובונטו, דביאן, Red Hat ודומיהן), מספר הגרסה לא תמיד משתנה, כי ההפצה מכניסה את התיקון לגרסה הקיימת. שם הבדיקה היא ברשימת השינויים של החבילה: האם מופיעים בה שני מספרי ה-CVE. נכון לבוקר ה-21/10, לפי דיווחים, חלק מההפצות עדיין סימנו את התיקון כ"ממתין".

אם אפשר לעדכן: לעדכן עכשיו

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

מה המטרה: להגיע לגרסה המתוקנת של הענף שלכם (מהרשימה למעלה), או לעבור לענף נתמך. אם האתר על 7.4, 8.0 או 8.1, זה הזמן לתכנן מעבר ל-8.2 ומעלה. שימו לב ש-8.2 מפסיקה לקבל עדכוני אבטחה בסוף דצמבר 2026, כך שהיעד הנכון לטווח ארוך הוא 8.3 ומעלה.

איך זה נראה בלוחות הבקרה הנפוצים (המסכים משתנים בין גרסאות, אז זה כיוון כללי):

  • Plesk: מנהל השרת מעדכן את חבילות ה-PHP דרך "Tools & Settings" ואז "Updates". בעל האתר בוחר את גרסת ה-PHP של האתר במסך "PHP" של הדומיין.
  • cPanel / WHM: מנהל השרת מעדכן את חבילות ea-php דרך עדכוני המערכת. בעל האתר בוחר גרסה ב-"MultiPHP Manager".
  • Cloudways: בהגדרות השרת, במסך החבילות (Settings & Packages), בוחרים את גרסת ה-PHP.
  • אחסון וורדפרס מנוהל (Kinsta, WP Engine, SiteGround, Wordify ודומיהם): בדרך כלל חברת האחסון מעדכנת בעצמה. היכנסו לדף הסטטוס או לבלוג שלהם, ואם לא כתוב שם שטיפלו, שאלו אותם ישירות.

שני דברים שאסור לדלג עליהם:

  1. הפעלה מחדש של PHP. התקנה של גרסה חדשה לא מספיקה אם התהליכים הישנים ממשיכים לרוץ. צריך להפעיל מחדש את PHP-FPM (או את אפאצ'י, אם האתר על mod_php) לכל גרסה שמותקנת בשרת.
  2. אימות. אחרי העדכון חוזרים ל"בריאות האתר" בוורדפרס ובודקים שהגרסה שמופיעה היא הגרסה המתוקנת. אם יש כמה גרסאות PHP בשרת, בודקים כל אתר.

לפני עדכון בין ענפים (למשל מ-7.4 ל-8.2) כדאי לגבות את האתר ולבדוק אותו אחרי המעבר. תוסף ישן או תבנית ישנה עלולים לא לעבוד עם גרסה חדשה. אם יש לכם גיבוי אוטומטי, זה הרגע לוודא שהוא עובד.

אם אי אפשר לעדכן עכשיו

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

1. לכבות את מעקב התקדמות ההעלאה (session.upload_progress)

אחד מנתיבי התקיפה שאומתו עובר דרך פיצ'ר של PHP שמדווח על התקדמות העלאת קבצים. הפיצ'ר פעיל כברירת מחדל, ורוב האתרים לא משתמשים בו. מכבים אותו בשורה אחת:

session.upload_progress.enabled = 0

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

  • הכי טוב: בקובץ php.ini הראשי של כל גרסת PHP בשרת, או בקובץ הגדרות נוסף בתיקיית ההגדרות שלה (למשל קובץ חדש בתיקייה conf.d או php.d).
  • ב-PHP-FPM: אפשר גם בהגדרות ה-pool של האתר, בצורה הזאת:
php_admin_value[session.upload_progress.enabled] = 0
  • באפאצ'י עם mod_php: בהגדרות השרת או ה-VirtualHost:
php_admin_value session.upload_progress.enabled 0
  • מה לא מספיק: צוות PHP כותב במפורש לא לסמוך על הגדרה בקובץ .user.ini (בשרתי PHP-FPM) ולא על ini_set() בתוך הקוד. גם שורת php_value בקובץ .htaccess לא מופיעה ברשימה שלהם. אם זו האפשרות היחידה שלכם, היא עדיפה על כלום, אבל אל תסמכו עליה ובקשו מחברת האחסון לשים את ההגדרה ברמת השרת.

אחרי השינוי חובה להפעיל מחדש את כל תהליכי ה-PHP (PHP-FPM או אפאצ'י). בלי זה ההגדרה לא נכנסת לתוקף.

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

2. צעדים נוספים מההודעה הרשמית

למי שמנהל את השרת, צוות PHP מציע עוד כמה צעדים חלקיים:

  • לצמצם את גודל הבקשות: להגדיר post_max_size נמוך (8M לאתר בלי העלאת קבצים, 32M אם יש העלאות), ולשמור על upload_max_filesize קטן ממנו. כדאי להגביל גם ברמת שרת הווב את גודל הבקשה ואת מספר השדות והחלקים בבקשה.
  • memory_limit=-1: צוות PHP מציין את זה כצעד חלקי לחולשה הראשונה. זה מסיר מגבלה שימושית על צריכת זיכרון, אז אם בוחרים בזה, כדאי להחזיק גבול זיכרון ברמת המערכת (container או cgroup).
  • ב-PHP 8.5: להגדיר fatal_error_backtraces=0 ולהפעיל מחדש.

3. חומת אש לאפליקציות (WAF)

אם יש בשרת WAF כמו ModSecurity או Imunify360, או שהאתר עובר דרך Cloudflare, כדאי לוודא שיש חוק שחוסם בקשות POST שמכילות את השדה PHP_SESSION_UPLOAD_PROGRESS. קוד התקיפה הפומבי שולח את השדה הזה. Wordify דיווחה שחוקי ה-WAF שלה חסמו את כל ניסיונות התקיפה שזיהתה.

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

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

אם האתר על אחסון משותף, רוב הצעדים האלה בידיים של חברת האחסון. שלחו להם היום שלוש שאלות: האם ה-PHP שלכם כולל את התיקון לשני ה-CVE, האם session.upload_progress.enabled כבוי ברמת השרת, והאם יש חוק WAF לתקיפה הזאת.

5. אתר ישן שאף אחד לא מתחזק

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

6. לתכנן את המעבר

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

איך בודקים אם כבר נפרצתם

ניסיונות התקיפה התחילו ב-21/10, ולכן כדאי לבדוק כל שינוי מאז 20/10. מה לחפש:

  • קבצי PHP חדשים באתר שנוצרו או השתנו מאז 20/10, במיוחד כאלה עם שמות מוזרים או קוד מוסתר (base64, eval).
  • קבצי PHP בתיקיית ההעלאות (wp-content/uploads). שם אמורות להיות תמונות וקבצים, לא קוד. קובץ PHP שם הוא סימן אזהרה חזק.
  • משתמשי מנהל שאתם לא מכירים ברשימת המשתמשים בוורדפרס.
  • משימות מתוזמנות חדשות (cron), גם בשרת וגם בתוך וורדפרס.
  • סימנים ברמת השרת: תהליכים חשודים שרצים תחת משתמש שרת הווב, קבצים חדשים בתיקיות /tmp או /dev/shm, ומפתחות SSH חדשים.
  • בלוגים: חברות אבטחה מציינות סדרות של מאות בקשות POST גדולות מאותה כתובת IP בזמן קצר, ושגיאות שמכילות "in Unknown on line 0".

אם מצאתם משהו: קודם מעדכנים את PHP וסוגרים את הפרצה, ואז מנקים. מחליפים את כל הסיסמאות (מנהלי וורדפרס, FTP, מסד הנתונים, לוח הבקרה), מחליפים את מפתחות האבטחה (salts) בקובץ wp-config.php כדי לנתק את כל מי שמחובר, ומוחקים משתמשים ומשימות זרים. כתבנו מדריך מפורט למה עושים בשעות הראשונות אחרי פריצה. אם האתר עסקי ואתם לא בטוחים, זה הזמן לקרוא למי שעושה את זה כל יום.

לקוחות OCW: טיפלנו בזה

אם אתם לקוחות של OCW, אתם לא צריכים לעשות כלום. בכל האתרים שאנחנו מאחסנים ומתחזקים עשינו ב-21/10 את הדברים הבאים:

  • עדכנו את PHP 8.3 לגרסה 8.3.36 והפעלנו מחדש את השירותים על הגרסה החדשה.
  • כיבינו את session.upload_progress בכל גרסאות ה-PHP בשרתים.
  • הפעלנו חוקי WAF נגד התקיפה.
  • בדקנו סימני פריצה (קבצי PHP חדשים מאז 20/10, קבצי PHP בתיקיות ההעלאות, תהליכים חשודים ומשימות cron), ולא מצאנו.

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

לא בטוחים מה המצב אצלכם?

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

לקריאה נוספת: חלק טכני למנהלי שרתים

שתי החולשות, לפי צוות PHP:

  • CVE-2026-109618, הרצת קוד דרך השחתת זיכרון בזמן חוסר זיכרון (OOM): כש-PHP נתקלת בחוסר זיכרון באמצע אתחול של נתוני הבקשה, היא עלולה לצאת מהאתחול באמצע, ושלב הניקוי בסוף הבקשה מתייחס לנתונים החלקיים כאילו הם תקינים. לפי ההודעה, כמה בעיות בפענוח בקשות multipart מאפשרות לדחוף בקשה לחוסר זיכרון בלי לחרוג מהמגבלות הגלויות של PHP. ב-mod_php הניצול אומת. LiteSpeed (LSAPI) ו-FrankenPHP כנראה פגיעים, ו-FPM נחשב פגיע אבל לא הודגם בו ניצול לחולשה הזאת.
  • CVE-2026-109619, הרצת קוד דרך מצב גלובלי שנשאר מבקשה קודמת: מצב פנימי של בקשה יכול לשרוד אחרי שהזיכרון שלו שוחרר, ובקשה מאוחרת יותר באותו תהליך עלולה להשתמש בו לפני האתחול (use-after-free). המקרים שאומתו: מנגנון session upload progress (אומת מול mod_php ומול FPM, ולא דורש ש-session_start נקרא באתר), ו-fatal_error_backtraces ב-PHP 8.5.

ענפים ישנים: PHP 8.1 ומטה לא מקבלות עוד גרסאות מהפרויקט. צוות האבטחה של PHP פרסם תיקוני קוד מקור מינימליים ל-7.4, 8.0 ו-8.1 (בענפים ייעודיים במאגר php-src), למי שבונה מקוד מקור או אין לו ספק LTS. הפצות וספקי LTS אמורים להכניס את התיקונים לחבילות שלהם.

מאגר remi: צוות PHP ממליץ למי שמסתמך על rpms.remirepo.net לעבור לחבילות של ההפצה או לבנות מקוד מקור, כי המאגר לא היה צפוי להתעדכן ביום הפרסום.

חבילות של לוחות בקרה: אם לוח הבקרה הוציא build חדש של PHP, זה עדיין לא אומר שהתיקון בפנים. בדקו את רשימת השינויים של הספק לפני שאתם מסמנים V. נכון לזמן הכתיבה לא מצאתי הודעה רשמית פומבית של Plesk או cPanel על הענפים 7.4 עד 8.1.

צעד נוסף שהוזכר: pm.max_requests=1 ב-FPM מצמצם את האפשרות שמצב מבקשה אחת יגיע לבקשה הבאה, במחיר ביצועים.

שאלות נפוצות

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

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

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

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

מקורות: הודעת האבטחה של PHP · CVE-2026-109618 ב-GitHub · CVE-2026-109619 ב-GitHub · הדיווח של Wordify · גרסאות PHP נתמכות