AI Safety Incidents

wp2shell: RCE בפורדפרס סטנדרטי, שנמצא בתוך עשר שעות תמורת 25 דולר

מחבר

Rowan Sterling

תאריך פרסום

Oct 30, 2026

מודלים אחרונים · 20צפו בכל המודלים →

בנצ'מרקים: Artificial Analysis · מתעדכן יומית

חזרה לכל הפוסטים

ב-17 ביולי 2026 פרסמה Searchlight Cyber את wp2shell, שרשרת ניצול לביצוע קוד מרחוק לפני אימות בליבת WordPress שאינה דורשת תוסף, ערכת עיצוב או התחברות. די בבקשה אנונימית כנגד התקנה סטנדרטית: "להתקפה אין תנאים מקדימים והיא ניתנת לניצול בידי משתמש אנונימי בהתקנת WordPress סטנדרטית ללא תוספים", כך נכתב בייעוץ האבטחה של החברה. השרשרת מחברת שתי פגיעויות — CVE-2026-63030, פגיעות בלבול נתיבים בנקודת הקצה batch של WordPress REST API, שאותה מדרג ייעוץ הפרויקט כקריטית, ו-CVE-2026-60137, הזרקת SQL בפרמטר author__not_in של WP_Query, שאותה הוא מדרג כבינונית. WordPress שחררה את WordPress 7.0.2 באותו יום, וייעוצי הפרויקט מפרטים את WordPress 6.9.5, WordPress 6.8.6 ו-WordPress 7.1 beta2 ככאלה הכוללים את אותם תיקונים. Searchlight Cyber מצטטת הערכות שלפיהן יש יותר מ-500 מיליון אתרי WordPress. החוקר שמאחורי השרשרת, Adam Kues, אומר שהיא נבעה מהרצה של GPT-5.6 Sol Ultra שנבנתה על בסיס פרומפט ש-OpenAI פרסמה לבעיה מתמטית: עד ארבעה סוכנים, לפחות שש שעות של ציד ועוד כארבע שעות של הסלמה, בערך $25 של שימוש במודל. הרשומה נרשמת כממצא מחקרי — חומרה גבוהה לפי סולם הארכיון עצמו, רמת ודאות A, ללא נזק מתועד בעולם האמיתי, מתוארכת ליום בודד — וthe Orca AI Incident Archive מציג אותה עם המסמכים הראשוניים המקושרים מתחתיה.

החשיפה תואמה. Searchlight נמנעה מלחשוף את המכניקה ב-17 ביולי והעניקה למגנים את סוף השבוע לשדרוג; Kues פרסם את הדוח הטכני המלא ב-20 ביולי. עד אז כבר שוחזר הניצול המשורשר באופן עצמאי: Searchlight אומרת ש-Calif ו-Hacktron בנו מחדש את השרשרת המלאה לפני שהופיעו הוכחות היתכנות נוספות ב-GitHub. שני ייעוצי האבטחה של WordPress עצמה מציינים את אותן גרסאות מתוקנות, ו-CISA הוסיפה את שני ה-CVEs לקטלוג Known Exploited Vulnerabilities שלה ב-21 ביולי.

שני באגים, והמערכים שמאבדים סנכרון

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

ה-API של batch מפצל את ה-pipeline לשניים: הוא מאמת כל תת-בקשה בלולאה אחת ומבצע אותן בלולאה שנייה, והוא מחזיק בשני מערכים, $matches ו$validation, שהרשומות שלהם אמורות להתיישר זו מול זו לפי אינדקס. בקובץ class-wp-rest-server.php, כפי ש-Kues מתאר זאת, תת-בקשה שהיא עצמה שגיאת WordPress מתווספת אל $validation ואז נתקלת ב-continue, ומדלגת על השורה שמוסיפה אל $matches. מאותה נקודה ואילך כל התאמה מוזזת אחורה במיקום אחד. לולאת הביצוע מצמידה את תת-הבקשה באינדקס מסוים לאימות שנרשם באותו אינדקס, אבל המטפל מותאם לנתיב אחר — כך שפרמטר נבדק מול הכללים של נקודת קצה אחת ואז מבוצע על ידי הקוד של אחרת.

זה מה שהופך פרמטר רשימה שנראה תמים להזרקה. מסלול אוסף הפוסטים ממפה את הארגומנט הציבורי author_exclude שלו אל author__not_in. כאשר הערך הוא מערך, WordPress מפעיל את absint על כל איבר וממיין אותם; כאשר הערך הוא סקלר, הוא משורשר ללא שינוי אל קטע ה-SQL שהופך ל-NOT IN ($author__not_in). מחרוזת כגון 0) OR 1=1 -- לכן מגיעה אל טקסט השאילתה. בקריאה רגילה, המסלול היה מסרב לה, משום ש-author_exclude חייב להיות מערך של מספרים שלמים; קריאת האצווה הלא-מסונכרנת היא מה שמאפשר למחרוזת לעבור.

שני מכשולים נותרו, ושניהם נפתרו על ידי קינון התחבולה. ה-API של האצווה דוחה בקשות GET, וההזרקה נמצאת בנתיב GET; ואימות שיטת הבקשה עצמו מיושם כאימות פרמטרים, שאותו חוסר סנכרון יכול לעקוף. ה-payload שפרסם Kues שולח תת-בקשה חיצונית פגומה כדי לגרום לחוסר סנכרון בבדיקת השיטה, לאחר מכן אצווה פנימית שתת-הבקשה השנייה שלה מכילה את הפרמטר הזדוני author_excludeמול מטפל שאינו מאמת אותו, ואז את בקשת ה-GET שמפעילה אותו. הזרקה מבוססת UNION מחזירה ערכי מסד נתונים שרירותיים בתוך שורות המעוצבות כפוסטים רגילים.

A self-built HTML card headed 'wp2shell: what is affected and what fixes it', laying out two columns of version ranges as a scannable table. The left column, labelled CVE-2026-63030, batch route confusion, critical, CVSS 9.8, lists affected WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1, fixed in WordPress 6.9.5 and WordPress 7.0.2. The right column, labelled CVE-2026-60137, author__not_in SQL injection, moderate, CVSS 5.9, lists affected WordPress 6.8.0 to 6.8.5, 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1, fixed in WordPress 6.8.6, WordPress 6.9.5 and WordPress 7.0.2. A footer strip notes that 7.1 beta2 also carries the fixes and that the full chain needs WordPress 6.9 or later. Small print at the bottom credits the version ranges to the two WordPress security advisories and the scores to the WPScan-assigned CVSS vectors.

הרצת המודל: פרומפט מתמטי, המכוון אל בסיס קוד

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

ההתקנה הייתה מצומצמת במכוון. הוא שכפל את הגרסה היציבה העדכנית של WordPress לספרייה בשם main/ ומחק את ספריית .git שלו, תוך שאמר למודל לא להשתמש ביומני שינויים, בהיסטוריית git או באינטרנט הפתוח כדי להשוות את הקוד לגרסה מתוקנת — הסיבה שהוא ציין לכך היא שבעבור גילוי פגיעויות חדשות, התייעצות עם ההיסטוריה או עם האינטרנט היא בזבוז טוקנים. הוצעה ספרייה ריקה third_party/ כדי שהמודל יוכל לשכפל תלויות כגון קוד המקור של PHP או MySQL אם יסיק שהשרשרת זקוקה לבאגים בספריות שמתחת ל-WordPress. המשימה הוגדרה כ-RCE לפני אימות בפריסת ייצור טיפוסית על MySQL, עם עד ארבעה סוכנים ולפחות שש שעות. Kues כתב שהוא מציין את דרישת התצורה במפורש משום שאחרת מודלים "מרמים" — באמצעות בחירת אפשרויות תצורה בלתי סבירות ביותר, או באמצעות המצאת תנאים מוקדמים שתוקף לעולם לא היה יכול להשיג.

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

חישוב העלות שלו עצמו: 50% ממכסת שימוש שבועית, שאותה העריך בכ-25 דולר באופן יחסי (פרו-רטה) על מנוי של 200 דולר, עבור ניצול שהופק בקצת יותר מעשר שעות. החלק האנושי לא היה בחינם — Kues בילה את היום שלמחרת בפיענוח מה שהמודל עשה, וכתב שעבודת הניצול שלאחר החדירה ארכה לו הרבה יותר זמן להבנה מכפי שנדרש כדי ליצור אותה. מסקנתו חריפה באופן יוצא דופן ומוגבלת לתחום צר: "איני מעלה טענות כלליות, אך אני יכול לומר בביטחון מלא שאף חוקר אבטחה לא היה מצליח למצוא ולהשלים את שרשרת הניצול הזו ב-10 שעות ללא AI."

מ-SELECT לקריאה בלבד ועד להרשאות מנהל

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

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

שנית, להפוך פוסטים מומצאים לשורות אמיתיות. תכונת ההטמעה של WordPress שומרת במטמון הטמעות שנפתרו במסד הנתונים כפוסטים מסוג oembed_cache. הטמעת פוסט מקומי באמצעות נתיב יחסי, כמו ב-[embed]/?p=S[/embed], גורמת ל-WordPress לדלג על בקשת ה-HTTP ולעולם לא לבדוק שהפוסט שאליו מפנים קיים, כך נוצרת שורה. שלוש הטמעות כאלה עם אסימוני מחרוזת שאילתה שונים מייצרות שלושה גיבובי מטמון שונים, וכך התוקף משיג כמה שורות לעבוד איתן.

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

רביעית, גאדג'ט המחזור. לפוסטים יש הורים, ווורדפרס מסרבת למחזורים: מסנן ה-wp_insert_post_parent מטפס במעלה העץ, וכשמוצא לולאה, קורא לעדכון שקובע את post_parent לאפס. הקריאה הזו לא דורסת את post_content, ולכן הגרסה המאולתרת בזיכרון שורדת את הפיוס — ערכת שינויים, עם ה-JSON שלה בשלמותו, מגובה בשורה אמיתית.

חמישית, שאול את סמכותו של המנהל. סט שינויים שהסטטוס שלו מציין שהוא מתוזמן לעתיד אך תאריכו נמצא בעבר מיושם מיד. כל רשומה ב-JSON שלו מציינת user_id, והרשומה בשרשרת של Kues מציינת user_id 1, המנהל, כך ש-WordPress מאמץ באופן זמני את הזהות הזו כדי ליישם את השינוי. השינוי הראשון הוא עדכון תמים למראה ל-nav_menus_created_posts.

שישית, הריצו שוב את הבקשה בתור הזהות הזו.פרסום פוסט מפעיל פעולה בעלת שם דינמי, {status}_{post_type}. מכיוון שהפוסט מזויף, הסטטוס והסוג יכולים להיות כל דבר — כולל parse ו-request, מה שמפיק את הוק parse_request ומתחיל מחדש את צינור הבקשה מההתחלה בזמן שזהות המנהל המושאלת עדיין בתוקף. בקשת האצווה המקורית הכילה תת-בקשה שיצרה מנהל חדש; היא נכשלה במעבר הראשון כאורח והצליחה בהרצה החוזרת. משם התוקף מתחבר לחשבון החדש הזה ומעלה תוסף דלת אחורית מקובץ ZIP, וזהו ביצוע קוד.

A self-built HTML card titled 'Six moves from a SELECT to a shell', drawn as six numbered panels in two columns of three. Panel 1, fabricate posts: a UNION injection over the posts collection returns attacker-shaped rows, which WordPress stores in its per-request WP_Post cache. Panel 2, seed embed rows: embedding a local post by relative path writes stored oembed_cache rows, and WordPress never checks that the referenced post exists. Panel 3, content stays fixed: reconciling memory against the database overwrites post_content, the one field a changeset needs for its JSON. Panel 4, break the cycle check: a fabricated parent loop triggers WordPress's own cycle fix, an update that resets post_parent without touching post_content. Panel 5, borrow admin authority: a past-dated customize_changeset whose entries carry user_id 1 is applied as the administrator. Panel 6, replay as admin: a fabricated post with status parse and type request fires the parse_request hook, rerunning the batch so the admin-creation subrequest succeeds. A dark footer bar states that the new administrator then logs in and uploads a backdoor plugin from a ZIP file, which is code execution. No photographs, logos or personal names appear.

לטכניקה יש תנאי נלווה. The Hacker News, תוך ציטוט של Cloudflare, דיווח כי CVE-2026-63030 מאפשר הרצת קוד מרחוק רק כשאין שימוש במטמון אובייקטים מתמשך; ההזרקה עצמה קיימת החל מ-WordPress 6.8, ואילו השרשרת המלאה דורשת 6.9 או מאוחר יותר. בהתקנה סטנדרטית אין מטמון אובייקטים מתמשך, ולכן הניסוח של Searchlight בדבר "ללא תנאים מוקדמים" וההסתייגות של Cloudflare מתארים את אותו מקרה ברירת מחדל מכיוונים שונים.

מה שהמסמכים הראשוניים מבססים

הודעות האבטחה של WordPress עצמה הן החיזוק החזק ביותר, משום שזהו היצרן שמודה במנגנון ומשחרר את התיקון. GHSA-ff9f-jf42-662q, שדורגה כקריטית, מתארת חולשת בלבול בנתיב אצווה ב-REST API ב-WordPress 6.9 ומעלה, שמשתלבת עם ההזרקה כדי להגיע לביצוע קוד, ומייחסת קרדיט לאדם קיוס ב-Assetnote וב-Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, שדורגה כבינונית, מתארת את ההזרקה של author__not_in מ-WordPress 6.8 ומעלה, ומציינת ששתי הבעיות תוקנו ב-WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 וב-WordPress 7.1 beta2. רשומות ה-NVD עבור שני ה-CVE, שנוקדו על ידי ה-CNA של WPScan ולא על ידי NIST, נושאות ציון 9.8 עבור CVE-2026-63030 עם הווקטור AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, ו-5.9 עבור CVE-2026-60137 עם AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — פגיעות נגישה מרשת שאינה דורשת הרשאות במקרה הראשון, ואחת שדורשת מורכבות תקיפה גבוהה ומניבה השפעה על סודיות בלבד במקרה השני. שדה חומרת הפגיעות של הארכיון עצמו עבור רשומה זו מציין "גבוהה", בעוד ש-WordPress מתייג את פגיעות האצווה כ"קריטית"; מדובר בשני סולמות נפרדים המיושמים על שרשרת שלמה ועל רכיב בודד, ולא במחלוקת על הבאגים עצמם.

רשומות הקטלוג של CISA, כפי שהן משתקפות בשדות ההעשרה של NVD, נוספו ב-21 ביולי 2026, עם מועדי תיקון של 24 ביולי עבור CVE-2026-63030 ו-4 באוגוסט עבור CVE-2026-60137. CISA מכנה את הראשונה "פגיעות התנגשות פרשנות בליבת WordPress" ואת השנייה "פגיעות הזרקת SQL בליבת WordPress". Searchlight פרסמה גם בודק ציבורי בכתובת wp2shell.com כדי שמפעילים יוכלו לבדוק מופע מבלי להמתין לחתימת סורק.

השחזור הבלתי־תלוי מתועד בידי Searchlight עצמה, ולפיכך מדובר בטענה בנוגע לצדדים שלישיים ולא בדיווח מפי צד שלישי: על פי הכתוב מ־20 ביולי, Calif ו-Hacktron בנו מחדש את השרשרת המלאה לפני שהופיעו הוכחות היתכנות נוספות ב-GitHub. מה שניתן לאימות באופן בלתי־תלוי הוא ההשפעה — הוכחות היתכנות, תעבורת ניצול וטלמטריית ספקים בתוך ימים, כמפורט להלן.

A self-built HTML card titled 'Four days from advisory to catalog', drawn as a vertical timeline of five dated rows against a blue rule, the last row in amber. 17 July 2026, disclosure: Searchlight Cyber publishes the wp2shell advisory with the mechanics withheld and WordPress releases 7.0.2, with 6.9.5, 6.8.6 and 7.1 beta2 listed as carrying the same fixes. 18 July 2026, first exploitation: watchTowr reports that by the early hours of Saturday morning UTC successful exploitation was already well underway, initially to exfiltrate hashed credentials. 20 July 2026, full account: Kues publishes the GPT-5.6 Sol Ultra write-up while Wiz publishes an in-the-wild report, with 60 percent of WordPress-using organisations holding a vulnerable instance and 25 percent exposed to the internet, falling to 50 and 10 percent within 24 hours. 21 July 2026, CISA KEV: both CVEs enter the Known Exploited Vulnerabilities catalog. 24 July and 4 August, remediation due: CISA's two deadlines. A source line at the bottom names the WordPress advisories, The Hacker News for watchTowr, Wiz, and the cisaExploitAdd and cisaActionDue fields in NVD records. No photographs, logos or personal names appear.

מה שנטען אך לא הוכח

שני קרדיטים עבור הזרקה אחת אינם מתיישבים ברשומה הציבורית. הודעת האבטחה של WordPress עבור CVE-2026-60137 קובעת שהפגם "התגלה ונחשף באופן אחראי כצוות על ידי TF1T, dtro ו-haongo". התיאור של Searchlight מציג את אותה הזרקה לפני אימות כמו זו שהרצת המודל שלה חשפה, ואינו מזכיר את הצוות הזה; הודעת האבטחה של WordPress מעניקה קרדיט ל-Kues רק עבור הבלבול בנתיב האצווה, ואינה מזכירה מודל. אף אחד מהמסמכים אינו מסביר את החפיפה, ושום דבר שהמאמר הזה איתר אינו פותר אותה — האפשרות ששני אלה היו ממצאים עצמאיים של אותו באג אינה נשללת, והאפשרות שאחד הדוחות הוא גילוי מחדש מאוחר יותר אינה מבוססת אף היא. הרשומה אינה מכריעה בכך, וגם המאמר הזה לא.

המספר בכותרת של הפוסט של Searchlight מ-20 ביולי אינו נתמך בגוף הפוסט עצמו. נוסח הכותרת הוא: "מתווכי אקספלוייטים משלמים 500,000 דולר עבור RCE ב-WordPress. מצאתי אחד עם GPT5.6 Sol Ultra וב-25 דולר". הגוף מתעד את ה-25 דולר ואת עשר השעות במונחים מדויקים; הוא אינו כולל שמות מתווכים, אין בו הצעות, אין בו התכתבות ואין בו מקור לנתון של 500,000 דולר. לא נמצא דוח עצמאי שנכתב עבור הכתבה הזו ומאשש מחיר ששולם או הוצע עבור wp2shell. יש לקרוא את ה-500,000 דולר כמסגור של הכותרת, ולא כמחיר שוק מבוסס.

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

ניצול לאחר פרסום האזהרה

ג'ייק נוט, חוקר אבטחה ראשי ב-watchTowr, אמר ל-The Hacker News כי "עד לשעות המוקדמות של שבת בבוקר (UTC), הניצול המוצלח כבר היה בעיצומו, כשבתחילה נעשה שימוש בקוד ניצול פומבי כדי להעביר החוצה אישורי גישה מגובבים, ולאחר מכן הרצת קוד מרחוק לאחר שפרטים נוספים פורסמו ברבים." אותו דוח מצטט טלמטריית KEVIntel המקשרת בין 13 כתובות IP ייחודיות, משווייץ, גרמניה, הממלכה המאוחדת, אינדונזיה, ליטא, הולנד וסינגפור, לבין ניצול של CVE-2026-63030, ומצטט את מייסד KEVIntel, Ryan Dewhurst, שאמר כי הבקשות תאמו הוכחות היתכנות זמינות לציבור, וכי נעשה שימוש בכל המטענים – עיוורים, מבוססי UNION ומבוססי בוליאני.

חוקרי Wiz, שחר דורפמן וגילי טיקוצ'ינסקי, שפרסמו ב-20 ביולי, נתנו לכך קנה מידה: 60% מהארגונים שהשתמשו ב-WordPress החזיקו לפחות מופע פגיע אחד בזמן פרסום ה-CVEs, ו-25% חשפו שרת פגיע לאינטרנט — נתונים שירדו ל-50% ול-10% בתוך 24 שעות עם תחילת התקנת התיקונים. הם תיעדו העלאות תוספים זדוניים דרך מתקין הניהול, מיפוי משתמשים מול נקודת הקצה users, ניסיונות להכללת קבצים מקומיים נגד wp-config, וגישה לפאנל הניהול שהחזירה HTTP 200 — הסימן המזהה של התחברות מוצלחת ולא של בדיקה. התוכנה הזדונית שמצאו נעה בין דלת אחורית PHP מינימלית בת שורה אחת לבין webshell בגודל 150 KB שהוסווה כתוסף אבטחה לגיטימי של WordPress בשם CMSmap, עם מודולים לניהול קבצים, גישה למסד נתונים, סריקת פורטים והסלמת הרשאות.

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

מה השתנה לאחר מכן, ומה נשאר פתוח

עבור מפעילים, נתיב התגובה היה קצר. עדכון ל-WordPress 7.0.2, WordPress 6.9.5 או WordPress 6.8.6 הוא התיקון. חלופות החירום של Searchlight, עבור אתרים שלא יכלו להתעדכן מיד, היו לחסום גישה אנונימית ל-batch API — או באמצעות התקנת תוסף שחוסם לחלוטין גישה אנונימית ל-REST API, או על ידי חסימה של /wp-json/batch/v1 וגם ?rest_route=/batch/v1 בחומת אש של יישומי אינטרנט. החברה הזהירה ששניהם עלולים להשפיע על שימוש לגיטימי באתר ויש להתייחס אליהם כאמצעים זמניים עד שהעדכון יגיע. הבודק הציבורי ב-wp2shell.com בודק מופע ישירות. רשומות הקטלוג של CISA הוסיפו שעון ציות: תיקון עד 24 ביולי עבור CVE-2026-63030 ועד 4 באוגוסט עבור CVE-2026-60137.

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

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

wp2shell: RCE בפורדפרס סטנדרטי, שנמצא בתוך עשר שעות תמורת 25 דולר

שני באגים, והמערכים שמאבדים סנכרון

הרצת המודל: פרומפט מתמטי, המכוון אל בסיס קוד

מ-SELECT לקריאה בלבד ועד להרשאות מנהל

מה שהמסמכים הראשוניים מבססים

מה שנטען אך לא הוכח

ניצול לאחר פרסום האזהרה

מה השתנה לאחר מכן, ומה נשאר פתוח

מוצר

משאבים

לספקים

הצטרפו לקהילה שלנו

מהבלוג

ספקי מודלים