התיקון של WordPress לחולשה מנוצלת יכול לחשוף אתרים מסוימים לזמן קצר במהלך העדכון

אתרים מסוימים של WordPress עדיין יכולים להיות מותקפים בזמן שהם מתקינים את התיקון לחולשה שמנוצלת באופן פעיל, לפי Umut Bayram, החוקר ב-Picus Security שמצא אותה. העדכון שמתקין את התיקון עדיין מחלץ קבצים באמצעות הקוד הישן והלא מתוקן של האתר, כך שתוקף שפועל ברגע הנכון יכול להריץ קוד על השרת. החולשה מזוהה כ-CVE-2026-119977 ומשפיעה על WordPress 4.7 עד 7.1.3.

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

WordPress שחררה את התיקון בשבוע שעבר בגרסה 7.1.4 ובעדכונים תואמים לענפים ישנים עד 4.7. CISA הוסיפה את החולשה לקטלוג החולשות המנוצלות הידועות שלה מוקדם יותר השבוע. במהלך עדכון ליבה בחבילה מלאה, WordPress מחלצת עותק של הגרסה החדשה לתיקייה זמנית בתוך wp-content/upgrade, כולל המתקין, ושרת האינטרנט בדרך כלל יכול להגיע אליה. תוקף בלי חשבון שיכול לקבוע את שם התיקייה ולהגיע למתקין לפני מחיקתו יכול להריץ קוד. התיקון נותן לתיקייה שם אקראי, אבל העדכון שמתקין אותו משתמש בקוד הישן. בגרסה 5.9 ואילך הקוד הישן הזה נותן לתיקייה שם לפי הקובץ שהורד, כך שאפשר לחזות את השם בפעם האחרונה. לפני התיקון יכול היה תוקף להשתמש במתקין כדי לכתוב קובץ תצורה חדש, wp-config.php, לתוך העותק הזמני, והעדכון היה מעתיק אותו על הקובץ האמיתי של האתר; החלק בתיקון שמונע זאת פועל כבר במהלך העדכון שמתקין אותו, מפני ש-WordPress מעבירה את הקבצים למקומם בקוד החדש. תוקף שתופס את החלון הזה עדיין יכול להקים את העותק הזמני עם מסד נתונים משלו, להתחבר אליו ולהריץ PHP בהרשאות שרת האינטרנט לפני מחיקת העותק, ומשם לקרוא או לכתוב קבצים באתר החי.

מי חשוף

לא כל עדכון חושף את המתקין. חבילות מלאות כוללות אותו תמיד; חבילה חלקית חושפת אתר רק אם במקרה יש בה את קובצי המתקין. עדכונים אוטומטיים משתמשים באותו מעדכן. The Hacker News בדק את שירות העדכונים של WordPress.org: בתוך ענף, למשל מ-7.1.3 ל-7.1.4, הוא הציע חבילה חלקית, גם לעדכונים אוטומטיים, ואילו מעבר מענף ישן יותר, למשל מ-7.0.7 ל-7.1.4, הוצע רק בחבילה מלאה. בגרסאות 4.4 עד 5.8 הקוד הישן מוסיף תווים אקראיים שמסתירים את שם התיקייה, אלא אם האתר מדליף אותו בדרך אחרת. אחרי התקנת 7.1.4 או תיקון הענף, עדכונים מאוחרים יותר משתמשים בשם אקראי, וקובץ wp-config.php בעותק הזמני אינו מועתק יותר על הקובץ האמיתי. Bayram אמר שהחשיפה בחבילה חלקית תלויה במה שיש באותה חבילה, ואתר עובר לחבילה מלאה אם סכומי הבדיקה אינם תואמים או בעת התקנה מחדש. הגורם המכריע הוא אם המעדכן שכבר מותקן באתר תוקן.

מה על מנהלים לעשות

ההמלצה הראשונה של Bayram היא למנוע משרת האינטרנט להגיש את wp-content/upgrade בכלל. WordPress עובדת עם התיקייה ישירות על הדיסק, כך שחסימת גישה מהאינטרנט אינה שוברת עדכונים. ב-Nginx הוסיפו location ^~ /wp-content/upgrade/ { deny all; }. ב-Apache הוסיפו Require all denied בבלוק תיקייה עבור התיקייה הזו. בקובץ .htaccess הוסיפו RedirectMatch 403 ^/wp-content/upgrade/ מעל כללי השכתוב, אבל אל תשימו קובץ .htaccess בתוך התיקייה, מפני שהמעדכן הישן מוחק שם הכול לפני שהוא מחלץ את החבילה. ודאו שבקשה מחזירה 403. עדכנו ל-7.1.4 או למהדורה המתוקנת של הענף שלכם. עדכון ידני מחוץ לשורש האינטרנט הוא המסלול הבטוח הנוסף: גבו את הקבצים ואת מסד הנתונים, חלצו את המהדורה החדשה בתיקייה ששרת האינטרנט אינו מגיש, העתיקו את קובצי הליבה למקומם בלי לגעת ב-wp-config.php וב-wp-content, ואז הריצו את עדכון מסד הנתונים. WP-CLI wp core update אינו תחליף. WordPress 4.6 וגרסאות קודמות אינן מקבלות עוד עדכוני אבטחה, והחולשה חוזרת עד גרסה 2.7, שיצאה ב-2008.

ניצול ובדיקות

CISA ביססה את הוספת החולשה לקטלוג על ראיות לניצול פעיל, אבל לא תיארה את התקיפות. Wordfence, חברת האבטחה של WordPress שהקצתה את מזהה ה-CVE, ראתה ניסיונות שהחלו תשע דקות אחרי שהפעילה כלל חומת אש ביום השחרור; שני המקורות העמוסים ביותר בדקו קבוצות קטנות של אתרים במשך כ-14.5 שעות, וזאת, לפי החברה, מתיישב עם ניסיונות לתפוס את הרגע שבו אתר מתעדכן. הציון ברשומת ה-CVE הוא 8.1 מתוך 10 בסולם CVSS, בעוד שההתראה של WordPress עצמה מדרגת את החולשה כנמוכה. קוד שהמחברים שלו מתארים כניצול הופיע במאגרי GitHub ציבוריים, ואחד מהם אומר שהוא עובד גם באתרים שעדיין משתמשים בתיקייה צפויה בזמן עדכון בחבילה מלאה; אם הקוד עובד, לא הוכח. לאתרים שנשארו בגרסה פגיעה אחרי השחרור, Wordfence ממליצה לחפש בקשות לא צפויות לקבצי PHP תחת wp-content/upgrade, חשבונות מנהל שאיש אינו מזהה, תוספים שאיש לא התקין וקבצי PHP שם שאיש לא שם.

מקורות: The Hacker News