פגיעות בוורדפרס CVE-2026-119977: אתרים שנפרצו במהלך עדכונים וכיצד להגן על שלכם

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

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

הפגיעות בקצרה

• מה זה: תנאי מרוץ (מחלקה TOCTOU) בתהליך עדכון הליבה המלא של וורדפרס.
• חומרה: CVSS 8.1 (גבוה).
• גרסאות מושפעות: וורדפרס 4.7 עד 7.1.3 כולל.
• מה התוקף צריך: גישת HTTP בלבד לאתר. אין צורך באימות ואין צורך בפעולת מנהל.
• פעולה: ב-3 בנובמבר 2026, CISA הוסיפה את הפגיעות לקטלוג הפגיעויות המנוצלות (KEV) שלה. Wordfence רשמה יותר מ-18,500 בקשות לנתיבים הפגיעים ב-21 השעות הראשונות לאחר חשיפת הפרטים.

איך פועלת המתקפה

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

1. מוריד את הארכיון עם הגרסה החדשה.
2. מחלץ אותו לתיקייה זמנית בפנים wp-content/upgrade/.
3. מעתיק את הקבצים לאתר החי.
4. מוחק את התיקייה הזמנית.

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

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

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

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

ציר זמן

גרסאות קבועות

התיקון הועבר חזרה לכל ענף נתמך עד גרסה 4.7. אנו ממליצים לעדכן לגרסה העדכנית ביותר, 7.1.4.

גרסאות 4.6 ומעלה לא קיבלו תיקון. יש לעדכן אתרים אלה לגרסה עדכנית או להוציא אותם משירות.

שלב 1. בדוק את גרסת וורדפרס שלך

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

עם WP-CLI:

wp core version

אם יש לכם מספר אתרים בשרת, תוכלו למצוא כל התקנת וורדפרס והגרסה שלה כך:

find /var/www -path '*/wp-includes/version.php' -exec grep -H "wp_version =" {} \;

חלף /var/www עם הספרייה שבה נמצאים האתרים שלך.

שלב 2. חסום גישה ל-wp-content/upgrade/ (עבור VPS ושרתים ייעודיים)

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

nginx

הוסף את זה לאתר שלך server בלוק:

location ^~ /wp-content/upgrade/ {
    deny all;
}

בדוק את התצורה וטען מחדש את nginx:

nginx -t && systemctl reload nginx

אפאצ'י ולייטספיד

הוסף זאת ל .htaccess קובץ בשורש האתר, מֵעַל הסטנדרטי # BEGIN WordPress בלוק:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

אם יש לך גישה לתצורת המארח הווירטואלי של אפאצ'י, עדיף לחסום את הספרייה שם:

<Directory "/var/www/example.com/wp-content/upgrade">
    Require all denied
</Directory>

החלף את הנתיב בנתיב שלך וטען מחדש את Apache:

apachectl configtest && systemctl reload apache2

ב-AlmaLinux, Rocky ומערכות אחרות מבוססות RHEL, השירות נקרא httpd.

תבדוק שהבלוק עובד

curl -I https://example.com/wp-content/upgrade/

התגובה צריכה להחזיר קוד 403.

שלב 3. צור גיבוי

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

wp db export ~/backup-$(date +%F).sql
tar -czf ~/site-files-$(date +%F).tar.gz -C /var/www/example.com .

אם יש לך VPS, אתה יכול גם לצלם תמונת מצב של השרת בלוח הבקרה.

שלב 4. עדכון וורדפרס

דרך פאנל הניהול או WP-CLI

אם חסמת את הגישה אל wp-content/upgrade/ (שלב 2), עדכן כרגיל — מפאנל הניהול או באמצעות WP-CLI:

wp core update
wp core update-db
wp core version

הפקודה האחרונה אמורה להציג את 7.1.4 או את הגרסה המתוקנת עבור הענף שלך.

ידנית, ללא חלון התקפה

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

cd /tmp
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
rsync -a --exclude 'wp-content' --exclude 'wp-config.php' /tmp/wordpress/ /var/www/example.com/
rm -rf /tmp/wordpress /tmp/latest.tar.gz

לאחר מכן שחזר את בעלות הקובץ (משתמש שרת האינטרנט עשוי להיות שונה, לדוגמה nginx or apache) ולעדכן את מסד הנתונים:

chown -R www-data:www-data /var/www/example.com
wp core update-db

במקום הפקודה האחרונה, ניתן לפתוח https://example.com/wp-admin/upgrade.php בדפדפן שלך.

אל תשכחו תוספים וערכות נושא

wp plugin update --all
wp theme update --all

שלב 5. בדוק את האתר שלך לאיתור סימנים של פריצה

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

בקשות למתקינים זמניים ביומנים:

# nginx
grep -E "wp-content/upgrade/.*\.php" /var/log/nginx/access.log*

# Apache
grep -E "wp-content/upgrade/.*\.php" /var/log/apache2/access.log*

בקשות עם 200 קוד תגובה חשודים במיוחד.

קובץ wp-config.php מוחלף: בדוק את תאריך השינוי של הקובץ ואת הגדרות החיבור למסד הנתונים.

ls -l /var/www/example.com/wp-config.php
grep -E "DB_(NAME|USER|HOST)" /var/www/example.com/wp-config.php

שלמות קובץ ליבה:

wp core verify-checksums

קבצי PHP ומנהלים לא מוכרים:

find /var/www/example.com/wp-content/upgrade /var/www/example.com/wp-content/uploads -name "*.php"
find /var/www/example.com -name "*.php" -mtime -10
wp user list --role=administrator

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

אם קבלן מתחזק את האתר שלך

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

זקוק לעזרה?

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