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

חולשת XSS מוחזר (Reflected Cross-Site Scripting) בטופס התחברות היא הממצא הנפוץ ביותר שנסגר בלי טיפול אמיתי. הוא מגיע לדוח בסיווג בינוני, כרטיס התיקון אומר “לקודד את הודעת השגיאה”, והוא ממתין מאחורי מה שבאמת בוער ברבעון הנוכחי.

CVE-2026-64638 היא בדיוק הממצא הזה, בליבת וורדפרס, בעמוד התחברות שעונה בחלק עצום מהאינטרנט הציבורי. החולשה נמצאה ודווחה באחריות על ידי צוות pwn.ai, והיא מדורגת 8.9 בסולם CVSS 4.0 — משום שבין ה־XSS המוחזר לבין PHP שרץ על השרת עומדים שישה שלבים נוספים, וכל אחד מהם כבר נשלח כחלק מהליבה.

וורדפרס תיקנה אותה בגרסה 7.0.3 ב־6 באוגוסט 2026, והחזירה את התיקון (backport) ל־24 ענפי תחזוקה, עד גרסה 4.7.34.

הגרסה במשפט אחד. ה־XSS אינו דורש חשבון כלל. הרצת הקוד (RCE) דורשת דבר אחד נוסף שהתוקף אינו יכול לייצר בעצמו: מנהל מחובר שילחץ פעם אחת על עמוד שבשליטת התוקף.

הסייג הזה חשוב לתיעדוף, והוא בדיוק החלק שנופל כשהסיפור מתגלגל ברשת בתור “הרצת קוד לא מאומתת בוורדפרס”. זו אינה חולשת zero-click. היא גם לא קשה — הקליק הוא קליק רגיל, בעמוד שנראה רגיל לחלוטין.

למה זה רלוונטי במיוחד לארגונים בישראל

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

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

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

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

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

האם אנחנו חשופים?

השאלה הראשונה והיחידה שחשובה היא באיזו גרסת משנה אתם נמצאים, והתשובה אינה “אנחנו על 6.8, שזה ישן אבל בסדר”. התיקון הוחזר אחורה (backport), ולכן 6.8.7 מוגנת ו־6.8.6 אינה.

פרסמנו בודק פסיבי שמסיק את גרסת הוורדפרס של אתר מנקודות קצה ציבוריות בלבד — ללא ניסיונות התחברות, ללא payloads, ובלי דבר ש־WAF אמור לתעד כתקיפה:

← wp-check.ionsec.io

הכלי קורא את תגית ה־generator, את ה־feed, את הקובץ readme.html, את מחרוזות ?ver= על נכסי הליבה ואת אינדקס ה־REST, מצליב אותם מול הטבלה שלמעלה, ומציין אילו סימנים לא הסכימו זה עם זה. סרקו רק דומיינים שבבעלותכם או שקיבלתם הרשאה לבדוק.

שלב 1 — שני מפענחים, מחרוזת אחת

נקודת ההזרקה (injection point) היא הודעת השגיאה של התחברות כושלת. הפונקציה wp_authenticate_username_password() בקובץ wp-includes/user.php מחזירה את שם המשתמש שנשלח אל תוך העמוד, לאחר סינון. שני מנגנוני סינון שונים נוגעים במחרוזת הזו, והם אינם מסכימים על השאלה מהי תגית.

הפונקציה strip_tags() של PHP דורשת שאחרי הסימן < יבוא שם התגית מיד. שכבת KSES של וורדפרס סלחנית יותר, ומתייחסת לרווח שאחרי הסוגר כאל רווח לבן בתוך תגית תקינה לחלוטין:

strip_tags('<area id=test>');    // ''                  — נמחק
strip_tags('< area id=test>');   // '< area id=test>'   — שורד
// …ואז KSES מפענחת את השורד הזה כאלמנט <area> אמיתי.

התגית <area> נמצאת ברשימת ההיתר של KSES, יחד עם המאפיינים id, class, href ו־name. זו רשימה קצרה מאוד. היא גם, כפי שמתברר, בדיוק מספיקה.

מחלקת החולשות הזו — מסנן ומפענח (parser) שאינם מסכימים על אותם בתים — מתועדת היטב תחת השם Parsing Differentials, והיא מאותה משפחה של mXSS. הלקח ההגנתי חורג הרבה מעבר לוורדפרס: אם שתי שכבות במערכת שלכם מפענחות HTML, הן חייבות להיות אותו מפענח. בכל מקום שבו הן אינן, רשימת ההיתר היא המלצה בלבד.

שלב 2 — DOM Clobbering דרך רשימת ההיתר

לא ניתן להשתמש בתגית <script> — KSES לעולם לא תאשר אותה. ולכן לא נעשה שימוש בשום סקריפט של התוקף.

וורדפרס טוענת את הקובץ wp-admin/js/user-profile.js בעמוד ההתחברות. הסקריפט הזה קיים עבור מסך איפוס הסיסמה, והוא אינו אמור לעשות דבר בטופס התחברות. שתיים מההתנהגויות שלו נגישות בכל זאת:

• סביב שורה 620, בעת טעינת המסמך, הוא מריץ $('.reset-pass-submit').find('.wp-generate-pw').trigger('click')
• סביב שורה 562, הוא רושם delegated handler — מאזין אירועים מואצל — תחת #color-picker עבור אלמנטים התואמים ל־.color-option

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

< area id=ajaxurl href=/test>
< div id=color-picker class=reset-pass-submit>
< button class="wp-generate-pw color-option">X

השורה הראשונה היא DOM Clobbering: אלמנט בעל id הופך למאפיין של אובייקט window, ולכן window.ajaxurl — שהסקריפט קורא כדי להחליט לאן לשלוח את בקשתו — הוא כעת אובייקט HTMLAreaElement שבשליטת התוקף. שתי השורות הנותרות גורמות לסקריפט להפעיל את עצמו בעת טעינת העמוד, ללא שום אינטראקציה.

התוקף לא הריץ ולו שורה אחת של JavaScript משלו. הוא סיפק שמות עצם, ונתן לסקריפט של וורדפרס עצמה לספק את הפעלים.

שלב 3 — לגרום ל־REST API להחזיר סקריפט להרצה

הפונקציה $.post() של jQuery ממירה למחרוזת כל מה שמועבר לה ככתובת. המרה למחרוזת של HTMLAreaElement מחזירה את ערך ה־href שלו. וכך המשתנה הגלובלי שהושתל הופך ליעד הבקשה, והתוקף בוחר אותו:

< area id=ajaxurl href=/?rest_route=/&_method=GET&_jsonp=alert&_envelope=1>

שלושה פרמטרים מתועדים של REST עושים כאן את העבודה:

• _jsonp עוטף את התשובה בקריאה ל־callback ומגיש אותה עם Content-Type: application/javascript. jQuery מזהה את סוג התוכן הזה ומריצה את הגוף דרך jQuery.globalEval().
• _method=GET דורס את הפועל, כך שבקשת POST מגיעה לנתיב שמקבל GET בלבד.
• _envelope=1 עוטף את הסטטוס האמיתי בתוך גוף תשובה עם קוד 200, כך שכשל אימות אינו עוצר את הרצף.

שם ה־callback מאומת מול הביטוי הרגולרי ^[a-zA-Z0-9_.]+$. בנקודה זו יש לתוקף יכולת לקרוא לפונקציות שרירותיות ב־origin של האתר — והיכולת הזו מוגשת לו על ידי ה־REST API של האתר עצמו.

ראוי לציין: המחקר המקורי מדווח שהמסלול הזה שרד מדיניות אבטחת תוכן (CSP) מבוססת nonce עם strict-dynamic. הדבר עקבי עם ההתנהגות הידועה של DOM Clobbering כפרימיטיב לעקיפת CSP: הסקריפט שרץ הוא סקריפט שהעמוד כבר סמך עליו, ול־CSP אין שום דעה על השאלה מאיזה משתנה גלובלי הוא קרא כתובת.

שלב 4 — הנקודה שבביטוי הרגולרי

הביטוי ^[a-zA-Z0-9_.]+$ מתיר נקודות. נקודה משמעה מעבר בין מאפיינים, ומעבר בין מאפיינים מחלון בן מגיע אל החלון שפתח אותו:

_jsonp=window.opener.approve.click

זוהי טכניקת Same Origin Method Execution (SOME), שתוארה על ידי בן חייק בכנס Black Hat EU בשנת 2014. התוקף אינו יכול לקרוא את תוכן העמוד של החלון הפותח — מדיניות ה־Same-Origin עדיין חלה — אך אין לו צורך בכך. הוא צריך רק לקרוא למתודה אחת בתוכו, והחלון הפותח הוא ההפעלה המאומתת של המנהל.

ההמלצה למניעת SOME לא השתנתה מזה אחת־עשרה שנים, וכדאי לחזור עליה כי החולשה הזו היא מופע ישיר שלה: שם ה־callback ב־JSONP חייב להיות allowlist סגור, לא מחלקת תווים.

שלב 5 — הנפקת Application Password

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

עמוד התוקף פותח חלון בן ריק, מנווט את החלון הראשי אל /wp-admin/authorize-application.php האמיתי — מסך וורדפרס אמיתי, בדומיין האמיתי, עם תעודת TLS אמיתית — ומורה לחלון הבן להפעיל את השרשרת שלמעלה כשהקריאה מכוונת אל כפתור האישור של החלון הפותח.

קליק אחד של המנהל מוביל את auth-app.js עד הסוף. וורדפרס מנפיקה Application Password ומחזירה אותה בהפניה (redirect), בתוך מחרוזת השאילתה:

/?site_url=…&user_login=admin&password=XXXXXXXXXXXX

לתוקף יש כעת פרטי גישה עמידים ברמת מנהל, ששורדים החלפת סיסמה ואינם מכוסים על ידי אימות רב־שלבי (MFA) של האתר.

שלבים 6 ו־7 — מ־Application Password ל־PHP

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

בעזרת אימות HTTP Basic וה־Application Password הגנובה, התוקף מפרסם עמוד המכיל תגית <script>. בהתקנה של אתר יחיד, מנהלים מחזיקים בהרשאת unfiltered_html, ולכן דבר אינו מסנן אותה:

POST /wp-json/wp/v2/pages
Authorization: Basic <base64 של admin:app-password>

{"title":"x","status":"publish","content":"<script>…</script>"}

הסקריפט הקבוע הזה מושך את ה־nonce של העלאת התוספים, ושולח קובץ ZIP אל /wp-admin/update.php?action=upload-plugin.

והנה החלק ששווה להפנים גם אם לעולם לא תפעילו וורדפרס שוב: תוסף אינו חייב להיות מופעל כדי לרוץ. ההעלאה מחלצת את הקבצים אל /wp-content/plugins/, והתיקייה הזו מוגשת על ידי שרת הרשת. פנייה ישירה לקובץ ה־PHP שהועלה מריצה אותו. אין שלב הפעלה לביקורת, אין פעולת מנהל לבדיקה, ואין שורה ברשימת התוספים שנראית חשודה.

ה־PoC שפורסם הוא כמה שורות שמחזירות כותרת HTTP ומריצות פקודת מערכת — מספיק כדי להוכיח הרצה, ומאותו רגע מדובר בבעיית post-exploitation רגילה בתשתית שלכם.

זיהוי

אם אתם שואלים אם נפגעתם לפני שעדכנתם, אלה הממצאים. הם זולים לחיפוש והם שורדים בלוגי גישה רגילים.

בנקודת הקצה של ההתחברות — ה־parsing differential מותיר חתימה ייחודית מאוד, כי הרווח שאחרי הסוגר הוא כל התרגיל:

POST /wp-login.php  עם log= שמכיל "< area", "< div", "< button"

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

ב־REST API — הפרמטרים הגלובליים האלה כמעט אינם מופיעים בתעבורה לגיטימית באתר מודרני:

_jsonp=          כל בקשת REST שנושאת אותו בכלל
_jsonp=a.b.c     ערך המכיל נקודה — זהו הסימן ל־SOME, לא callback רגיל
_envelope=1      בשילוב עם _method=GET בנתיב שהיה אמור לסרב

בזרימת ה־Application Passwords — זהו הסימן ברמת הוודאות הגבוהה ביותר, כי זו הנקודה שבה התקיפה מפסיקה להיות איסוף מודיעין:

• Application Password שנוצרה תוך שניות מבקשה אל authorize-application.php
• הפניה או referrer המכילים יחד את site_url=, user_login= ו־password=
• כל Application Password ששמה אינו מוכר לכם, בכל חשבון מנהל

במערכת הקבצים ובנתיב ההעלאה — סוף השרשרת:

• POST /wp-admin/update.php?action=upload-plugin מכתובת שמעולם לא ניהלה את האתר
• קבצי PHP חדשים תחת /wp-content/plugins/ השייכים לתוסף שמעולם לא הופעל
• בקשות GET ישירות לקובץ .php בתוך תיקיית תוסף, במקום ל־index.php

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

תיקון

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

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

הקשחה מעבר לעדכון

אלה המלצות של IONSEC, ואינן חלק מהתיקון של היצרן. כל אחת מהן שוברת חוליה אחרת בשרשרת, וזו הנקודה — הסיבה שהחולשה הזו קיבלה ציון 8.9 היא שאף חוליה לא נשאה את המשקל לבדה.

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

add_filter( 'wp_is_application_passwords_available', '__return_false' );

כבו את JSONP ב־REST API. הוא קיים עבור צרכני cross-origin שקדמו ל־CORS. אם אין לכם כזה, זהו משטח תקיפה נטו:

add_filter( 'rest_jsonp_enabled', '__return_false' );

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

define( 'DISALLOW_FILE_MODS', true );

מנעו הרצת PHP במקומות שבהם PHP לעולם לא אמור לרוץ. התיקייה /wp-content/uploads/ היא המקרה הקלאסי, אך תיקיית התוספים ראויה לאותה בחינה — כפי שמראה שלב 7, המאפיין שקובע הוא נגיש־וניתן־להרצה, ולא מותקן־ומופעל.

חסמו את נקודת ההעלאה בקצה. לנתיב /wp-admin/update.php?action=upload-plugin יש מקור לגיטימי אחד בלבד: המנהלים שלכם. הגבילו אותו לפי כתובת מקור ברמת ה־CDN או ה־WAF.

נטרו סקריפטים בעמודים שלא אמורים להכיל אותם. שלב ההשתרשות מסתמך על unfiltered_html. התרעה על עמוד שפורסם ותוכנו מכיל תגית <script> תופסת את שלב 6 לפני ששלב 7 מתרחש.

מה זה באמת אומר על תיעדוף

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

כל רכיב בשרשרת הזו היה ידוע, מתועד, ובבידוד — משעמם. הפרש פענוח במסנן. סקריפט איפוס סיסמה שנטען בעמוד הלא נכון. שם callback ב־JSONP המאומת בביטוי רגולרי במקום מול allowlist. Application Password המוחזרת בתוך מחרוזת שאילתה. תיקיית תוספים שמריצה קבצים שהועלו אליה. כל אחד מאלה, כשהוא מדווח לבדו, הוא נמוך או בינוני ונקרא כמו תחזוקה שוטפת.

מורכבים יחד, הם 8.9 והרצת קוד.

כשחולשת XSS מוחזר חוזרת ממבדק, השאלה המועילה אינה “כמה חמור ה־XSS הזה”. היא: מה כבר טעון בעמוד הזה, ומה הוא יעשה אם אספק לו את שמות העצם הנכונים?

מקורות

1. pwn.ai — XSS2Shell: WordPress Preauth XSS to RCE Chain (CVE-2026-64638), המחקר המקורי — https://pwn.ai/blog/xss2shell
2. וורדפרס — GHSA-52p2-r8wf-jcrf, ההודעה הרשמית עם רשימות הגרסאות החשופות והמתוקנות במלואן — https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-52p2-r8wf-jcrf
3. WordPress News — WordPress 7.0.3 release, 6 באוגוסט 2026 — https://wordpress.org/news/2026/08/wordpress-7-0-3-release/
4. Patchstack — WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed — https://patchstack.com/articles/wordpress-7-0-3-released-12-vulnerabilities-found-and-fixed/
5. The Hacker News — New WordPress Pre-Auth XSS Could Lead to PHP Code Execution — https://thehackernews.com/2026/08/new-wordpress-pre-auth-xss-could-lead.html
6. Search Engine Journal — WordPress Security Release 7.0.3 Fixes High Severity XSS Vulnerability — https://www.searchenginejournal.com/wordpress-security-release-7-0-3-fixes-high-severity-xss-vulnerability/584927/
7. בן חייק — Same Origin Method Execution, Black Hat EU 2014, הפרימיטיב של שלב 4 — https://blackhat.com/docs/eu-14/materials/eu-14-Hayak-Same-Origin-Method-Execution-Exploiting-A-Callback-For-Same-Origin-Policy-Bypass-wp.pdf
8. Invicti — Same Origin Method Execution, כולל allowlist לשמות callback ב־JSONP כפתרון — https://www.invicti.com/web-application-vulnerabilities/same-origin-method-execution-some
9. PortSwigger Research — DOM Clobbering Strikes Back, הפרימיטיב של שלב 2 — https://portswigger.net/research/dom-clobbering-strikes-back
10. PortSwigger Research — Bypassing CSP via DOM Clobbering — https://portswigger.net/research/bypassing-csp-via-dom-clobbering
11. TU Braunschweig — Bypassing HTML Sanitizers via Parsing Differentials, מחלקת החולשות של שלב 1 — https://www.ias.cs.tu-bs.de/publications/parsing_differentials.pdf
12. Sonar — mXSS: The Vulnerability Hiding in Your Code — https://www.sonarsource.com/blog/mxss-the-vulnerability-hiding-in-your-code/
13. WordPress Developer Resources — פרמטרים גלובליים של ה־REST API‏ (_jsonp,‏ _envelope,‏ _method) — https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/
14. WordPress Developer Resources — מדריך אימות וסיסמאות יישום — https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/
15. Rapid7 — CVE-2026-63030: wp2shell, שרשרת ההרצה הנפרדת בליבת וורדפרס שתוקנה שלושה שבועות קודם לכן — https://www.rapid7.com/blog/post/etr-cve-2026-63030-wp2shell-a-critical-remote-code-execution-vulnerability-in-wordpress-core/
16. IONSEC — Tikun13 Checker, כלי קוד פתוח לבדיקת יישום תיקון 13 — https://www.ionsec.io/resources/tikun13checker