כשוורדפרס עצמה מחליטה לדרוס את בחירת מנהל האתר ולדחוף עדכון בכוח למיליוני אתרים בבת אחת, זה כבר לא "עוד פרצה". זה קוד אדום. הפעם קוראים לזה wp2shell, והוא מאפשר לתוקף אנונימי לחלוטין, בלי סיסמה ובלי אף תוסף מותקן, להריץ קוד על השרת שלכם. הנה כל מה שצריך לדעת, ולמה לקוחות הוורדפרס המנוהל שלנו יכלו להמשיך לישון בשקט.
⚡ בקצרה (TL;DR)
- מה זה: פרצת RCE (הרצת קוד מרחוק) קריטית בליבת וורדפרס, ללא צורך בהזדהות.
- מזהים: CVE-2026-63030 (בלבול נתיב ב-REST API) יחד עם CVE-2026-60137 (SQL Injection). השרשור ביניהן הוא מה שמסוכן.
- גרסאות פגיעות: 6.9.0 עד 6.9.4 וכן 7.0.0 עד 7.0.1. ענף 6.8 חשוף רק ל-SQLi.
- התיקון: שדרוג ל-7.0.2, ל-6.9.5 או ל-6.8.6. וורדפרס הפעילה עדכון אוטומטי כפוי.
- מה עושים עכשיו: לוודא גרסה, לחסום את נתיב ה-batch ב-WAF, ולהישאר מעודכנים.
הקדמה: כשוורדפרס עצמה נלחצת
יש כלל לא כתוב בעולם וורדפרס: הפרויקט לא דוחף עדכונים בכוח לאתרים שבחרו במפורש לכבות עדכונים אוטומטיים. זו בחירה של מנהל האתר, והפרויקט מכבד אותה, אלא אם קורה משהו חמור באמת. ב-17 ביולי 2026 קרה בדיוק ה"משהו החמור באמת".
וורדפרס שחררה בבהילות את גרסאות 7.0.2 ו-6.9.5, והפעילה מנגנון עדכון כפוי על פני כל האתרים הפגיעים. עצם ההחלטה הזו אומרת על חומרת הבאג יותר מכל דירוג CVSS: מדובר בפרצה שמאפשרת השתלטות מלאה על השרת, התוצאה הגרועה ביותר שאפליקציית ווב יכולה להציע לתוקף, ושניתן להפעיל אותה בבקשת HTTP בודדת מאדם אנונימי לחלוטין.
אז מה זה בעצם wp2shell?
הפרצה התגלתה על ידי Adam Kues מחברת Assetnote (הזרוע לניהול משטח תקיפה של Searchlight Cyber), ודווחה לוורדפרס דרך תוכנית ה-HackerOne. לפי הגילוי, למתקפה "אין תנאים מקדימים וניתן לנצל אותה על ידי משתמש אנונימי" מול התקנה סטנדרטית.
השם wp2shell מתאר בדיוק את מה שקורה: מבקשה תמימה לאתר וורדפרס, עד לגישת shell על השרת. וכאן החלק המפחיד באמת: הפגיעות נמצאת בליבה (Core) של וורדפרס עצמה, לא בתוסף או בתבנית. המשמעות היא שגם התקנה חדשה לגמרי, נקייה, בלי שום תוסף ובלי שום התאמה אישית, פגיעה, כל עוד היא רצה על גרסה לא מעודכנת. עם כ-500 מיליון אתרי וורדפרס בעולם (כ-40% מכלל הרשת), פוטנציאל הנזק עצום.
איך זה עובד? שתי חולשות שמתחברות לאחת
זה הפרט הקריטי שרוב הכותרות מפספסות: wp2shell איננה פרצה אחת אלא שתיים, והקשר ביניהן הוא מה שהופך אותה לקטלנית. כל אחת לבדה מטרידה; יחד הן אסון.
1. חוליית ה-SQL Injection: CVE-2026-60137
הזרקת SQL בפרמטר author__not_in של המחלקה WP_Query, המחלקה הליבתית שבונה כמעט כל שאילתת מסד נתונים שוורדפרס מבצעת. היא מדורגת CVSS 9.1 (קריטי, מסוג CWE-89) ומגיעה אחורה עד גרסה 6.8. לבדה, זו בעיית שלמות נתונים: תוקף יכול "לשכנע" את מסד הנתונים להחזיר מידע שאסור לו, למשל hashes של סיסמאות מנהל. חמור, אבל תחום.
2. חוליית בלבול הנתיב ב-REST API: CVE-2026-63030
בעיית "בלבול נתיב" (interpretation conflict, מסוג CWE-436) בנקודת הקצה /wp-json/batch/v1, נקודת קצה שקיימת בוורדפרס מאז גרסה 5.6 (שנת 2020). דירוג הבסיס שלה 7.5. זהו הרכיב שהופך הזרקה תחומה להשתלטות מלאה: כשמנתבים את ה-SQL Injection דרך נקודת ה-batch בגרסאות 6.9 ומעלה, ההזרקה מסלימה להרצת קוד מרחוק (RCE).
שרשרת התקיפה, בקצרה:
- התוקף מזהה אתר שרץ על גרסה פגיעה של וורדפרס.
- הוא שולח בקשת HTTP מעוצבת במיוחד אל נקודת הקצה הציבורית /wp-json/batch/v1.
- בלבול הנתיב יחד עם הזרקת ה-SQL מאפשרים להריץ קוד שרירותי על השרת.
- מרגע שיש הרצת קוד, התוקף שותל דלת אחורית (backdoor), גונב מידע, מזריק הפניות זדוניות, יוצר משתמש אדמין חדש, או מגייס את השרת ל-botnet.
🔎 נקודה מקצועית: אי-התאמה בדירוגים יש חוסר עקביות מעניין: האזהרות של וורדפרס ב-GitHub מסמנות את באג ה-batch כ"קריטי" ואת ההזרקה כ"בינוני", בעוד דירוגי ה-NVD הופכים את הסדר. זה משקף הבדל אמיתי במה שכל צד מודד, פוטנציאל השרשור מול ההשפעה העצמאית, אבל למנהל אתר זה אקדמי בלבד: שתיהן מתוקנות באותה גרסה, והתוצאה המשולבת היא השתלטות על השרת מבקשה לא מאומתת.
ממתי זה קיים, ואילו גרסאות פגיעות?
יש כאן חדשות טובות שממתנות מעט את הפאניקה: נתיב הקוד הפגיע ל-RCE קיים רק מגרסה 6.9 ומעלה, שיצאה ב-2 בדצמבר 2025. כלומר כל אתר פגיע רץ על גרסה בת פחות משמונה חודשים. עם זאת, קהילת וורדפרס נוטה להתעדכן אגרסיבית, מה שדווקא מגדיל את מספר האתרים החשופים.
| ענף גרסה | סטטוס | גרסת התיקון |
|---|---|---|
| 6.9.0 עד 6.9.4 | פגיע ל-RCE המלא | 6.9.5 |
| 7.0.0 עד 7.0.1 | פגיע ל-RCE המלא | 7.0.2 |
| 7.1 beta | פגיע | 7.1 beta2 |
| 6.8.x | חשוף רק ל-SQL Injection (לא לשרשרת ה-RCE) | 6.8.6 |
| ישן מ-6.8 | לא מושפע משתי הבעיות | — |
האם מנצלים את זה כבר בשטח?
נכון ל-18 ביולי, לא נצפה ניצול פעיל בשטח, ו-Searchlight Cyber נמנעה במכוון מפרסום הפרטים הטכניים המלאים כדי לתת למגינים זמן לתקן. הם אף פרסמו כלי סריקה ציבורי בכתובת wp2shell[.]com לבדיקת חשיפה (שהיה עמוס ולא זמין לסירוגין).
⏳ החלון נסגר מעצמו השקט הזה זמני. וורדפרס היא קוד פתוח: גרסאות 7.0.1 ו-7.0.2 יושבות בארכיון הציבורי, וההשוואה בין שתיהן היא הדרך הסטנדרטית שבה תיקון "שקט" מהונדס לאחור ל-exploit עובד. Searchlight עצמה כבר הדגימה את התבנית: כשדרופל תיקנה הזרקת SQL אנונימית דומה במאי, החברה הפכה את התיקון הפומבי לניתוח בן יום עם שני PoC פעילים. המשוואה היחידה שנותרה היא זמן: האם התיקון יגיע לאתר שלכם לפני שמישהו אחר יקרא את ה-diff.
מה עושים כדי להתגונן?
העדיפות חד-משמעית: לתקן. אבל תיקון לבדו לא מספיק בלי אימות ושכבות הגנה נוספות:
- שדרגו מיד ל-7.0.2, או ל-6.9.5 בענף 6.9 (ול-6.8.6 בענף 6.8). דרך לוח הבקרה: עדכונים ← עדכן עכשיו.
- ודאו את הגרסה בפועל. אל תניחו שהעדכון הכפוי נחת. וורדפרס לא אישרה שהמנגנון מגיע לאתרים עם עדכוני רקע מכובים לחלוטין. עדכון כפוי טוב רק כמו האתרים שהוא באמת נוגע בהם.
- חסמו את נתיב ה-batch ב-WAF אם אינכם יכולים לעדכן מיד. חסמו גם את /wp-json/batch/v1 וגם את המקבילה בפרמטר rest_route=/batch/v1. כלל שמכסה רק את הנתיב הראשון משאיר את השני פתוח!
- לחלופין, כבו גישת REST לא מאומתת, או הוסיפו must-use plugin שדוחה בקשות אנונימיות ל-batch ב-rest_pre_dispatch.
- אם יש חשד להדבקה, שמרו לוגים (ווב, WAF, אחסון, הזדהות) לפני ניקוי, וסקרו שינויים מאז התקנת הגרסה הפגיעה: קבצים חדשים, משתמשי אדמין לא מוכרים, משימות cron חשודות.
שימו לב: כל הפתרונות הזמניים (workarounds) עלולים לשבש תעבורת REST לגיטימית ואינטגרציות, ואף אחד מהם אינו תחליף לתיקון עצמו. הם גשר בלבד עד השדרוג.
איך שירות הוורדפרס המנוהל של SPD עוזר לכם במקרים כאלה 🛡️
אירוע כמו wp2shell ממחיש בדיוק למה קיים שירות הוורדפרס המנוהל של SPD. במקום שכל מנהל אתר ירדוף לבד אחרי כל פרצה חדשה, המערך שלנו נותן כמה שכבות הגנה:
- עדכונים אוטומטיים: אתרי הוורדפרס המנוהל אצלנו מוגדרים לקבל עדכוני ליבה אוטומטיים, כך שתיקוני אבטחה קריטיים כמו זה מגיעים לאתר במהירות ובלי תלות בזכירה ידנית של המנהל.
- שתי שכבות WAF (הגנה לעומק): תעבורה עוברת דרך Cloudflare WAF בקצה הרשת, ובנוסף דרך שכבת WAF נוספת משלנו על השרתים. שתי חומות אש אפליקטיביות נפרדות שמסננות תעבורה זדונית וניסיונות ניצול עוד לפני שהם מגיעים לאתר. זהו עקרון ה-defense in depth: אם שכבה אחת מפספסת ניסיון תקיפה, השכבה השנייה עדיין עומדת בדרך, ולא נשענים על נקודת כשל אחת.
- ה-SOC שלנו: מרכז ניטור אבטחה שעוקב אחר איומים ומגיב לאירועים כחלק ממערך האחסון.
זו הפילוסופיה שלנו: אחסון הוא לא רק מהירות ונפח, הוא קודם כל מבצר. wp2shell הוא עוד תזכורת לכמה חשוב מי מנהל לכם את התשתית ואת מדיניות העדכונים.
רוצים אחסון וורדפרס מנוהל עם הגנה מובנית? דברו איתנו »
שורה תחתונה
wp2shell הוא מקרה מבחן קלאסי: פרצה קריטית בליבה, ללא צורך בהזדהות, שמאיימת על מיליוני אתרים, עם פער זמן קצר וקטלני בין פרסום התיקון לבין הופעת ה-exploit הפומבי. אם אתם מנהלים אתר וורדפרס בעצמכם, בדקו את הגרסה עכשיו, אמתו שהיא 7.0.2, 6.9.5 או 6.8.6, וודאו שנתיב ה-batch חסום. ואם אתם מעדיפים שמישהו אחר ידאג לעדכונים ולשכבות ההגנה במקומכם, לשם בדיוק קיים הוורדפרס המנוהל של SPD.
מקורות: Rapid7 — ETR: CVE-2026-63030 wp2shell · SOCRadar — wp2shell CISO FAQ · Cyber Kendra — WP2Shell: Critical WordPress Flaw · Aikido Security — Unauthenticated RCE in WordPress (wp2shell) · Cyber Security News — New wp2shell RCE Vulnerability · The Hacker News (18.7.2026) · WordPress.org Security Advisory.
המידע נכון למועד הפרסום (יולי 2026) ומבוסס על הגילוי הרשמי. מצב הניצול בשטח משתנה במהירות, עקבו אחר עדכונים והתייעצו עם צוות האבטחה שלכם.
