WordPress-ის დაუცველობა CVE-2026-119977: საიტების გატეხვა განახლების დროს და როგორ დავიცვათ თქვენი

2026 წლის ოქტომბრის ბოლოს WordPress-ის განახლების მექანიზმში აღმოაჩინეს დაუცველობა: CVE-2026-119977 . ის საშუალებას აძლევს თავდამსხმელს, რომელსაც არ აქვს შესვლის სახელი და პაროლი, შეასრულოს თვითნებური კოდი სერვერზე — მაგრამ მხოლოდ საიტის განახლების დროს. დაუცველობა უკვე გამოიყენება რეალურ შეტევებში.

ქვემოთ მოცემულია, თუ როგორ მუშაობს ის, ვის ეხება ეს და რა უნდა გააკეთოთ თქვენი საიტის დასაცავად.

დაუცველობა მოკლედ

• რა არის ეს: რასის პირობა (TOCTOU კლასი) WordPress-ის სრული ბირთვის განახლების პროცესში.
• სიმძიმე: CVSS 8.1 (მაღალი).
• დაზარალებული ვერსიები: WordPress 4.7-დან 7.1.3-ის ჩათვლით.
• რა სჭირდება თავდამსხმელს: საიტზე მხოლოდ HTTP წვდომა. ავტორიზაცია და ადმინისტრატორის ქმედება არ არის საჭირო.
• ექსპლუატაცია: 2026 წლის 3 ნოემბერს, CISA-მ დაუცველობა დაამატა თავის ცნობილ ექსპლუატირებულ დაუცველობათა (KEV) კატალოგს. დეტალების გამჟღავნებიდან პირველი 21 საათის განმავლობაში Wordfence-მა დაუცველ ბილიკებზე 18,500-ზე მეტი მოთხოვნა დააფიქსირა.

როგორ მუშაობს შეტევა

სრული ძირითადი განახლების დროს, WordPress აკეთებს შემდეგს:

1. იტვირთება არქივი ახალი ვერსიით.
2. ამოაქვს ის დროებით საქაღალდეში შიგნით wp-content/upgrade/.
3. ფაილების კოპირება რეალურ საიტზე.
4. დროებით საქაღალდეს შლის.

პრობლემა ის არის, რომ დროებითი საქაღალდე მდებარეობს პროგნოზირებადი გზა და არის ხელმისაწვდომია ბრაუზერიდანშიგნით არის WordPress-ის სრული ასლი, მათ შორის setup-config.php ინსტალერი.

განახლების გაშვებისას, თავდამსხმელს შეუძლია გახსნას ეს ინსტალერი და გაეცნოს მას. შედეგად, მათ შეუძლიათ ჩაანაცვლონ მოქმედი ვერსია. wp-config.php და საიტს საკუთარ ცარიელ მონაცემთა ბაზაზე მიმართავენ. შემდეგ WordPress გთავაზობთ „ინსტალაციას“ — თავდამსხმელი ასრულებს მას, ხდება ადმინისტრატორი და სერვერზე საკუთარ PHP კოდს უშვებს.

შეტევის ფანჯარა განახლებას რამდენიმე წამში სჭირდება. ეს პრაქტიკაში შეტევის განხორციელებას ართულებს, თუმცა მასობრივი სკანერები მუდმივად იკვლევენ დაუცველ ბილიკებს და ზუსტად ამ დროის იმედოვნებენ, რომ ისინი ერთმანეთს დაემთხვევა.

ვერსია 7.1.4 შემთხვევითობის პრინციპით არჩევს დროებითი საქაღალდის სახელს, ამატებს დაცვას პირდაპირი წვდომისგან და ბლოკავს კონფიგურაციის დროებითი ასლიდან გადატანას.

Timeline

ფიქსირებული ვერსიები

გამოსწორება ყველა მხარდაჭერილ შტოზე 4.7 ვერსიამდე დაინგრა. გირჩევთ, განაახლოთ ის უახლეს ვერსიამდე, 7.1.4.

4.6 და უფრო ძველ ვერსიებს პრობლემა არ გამოუსწორებიათ. ეს საიტები საჭიროებენ განახლებას მიმდინარე ვერსიამდე ან მათი მომსახურებიდან ამოღებას.

ნაბიჯი 1. შეამოწმეთ თქვენი WordPress-ის ვერსია

ადმინისტრატორის პანელში: დაფა → განახლებები . ნუ დაეყრდნობით ავტომატურ განახლებებს — შესაძლოა, ისინი არ გაშვებულიყო: შესაძლოა, გამორთული ყოფილიყო, ფაილის ნებართვების გამო ვერ მოხერხებულიყო ან დანამატმა გადაფარა.

WP-CLI-ით:

wp core version

თუ სერვერზე რამდენიმე საიტი გაქვთ, შეგიძლიათ იპოვოთ WordPress-ის ყველა ინსტალაცია და მისი ვერსია შემდეგნაირად:

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

Replace /var/www დირექტორიასთან, სადაც თქვენი საიტები მდებარეობს.

ნაბიჯი 2. wp-content/upgrade/-ზე წვდომის დაბლოკვა (VPS და დედიკირებული სერვერებისთვის)

ეს ყველაზე მნიშვნელოვანი ღონისძიებაა. ის ხურავს შეტევის ფანჯარას თქვენი WordPress-ის ვერსიის მიუხედავად და არ უშლის ხელს განახლებებს: WordPress ამ საქაღალდესთან მუშაობს ფაილური სისტემის მეშვეობით და არა ვებგვერდის საშუალებით. ეს გააკეთეთ განახლებამდე , რადგან შეტევა ზუსტად განახლების დროს ხდება.

nginx

დაამატეთ ეს თქვენს საიტზე server ბლოკი:

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

კონფიგურაციის შემოწმება და nginx-ის გადატვირთვა:

nginx -t && systemctl reload nginx

Apache და LiteSpeed

დაამატეთ ეს .htaccess ფაილი საიტის root-ში, ზემოთ სტანდარტული # BEGIN WordPress ბლოკი:

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

თუ თქვენ გაქვთ წვდომა Apache ვირტუალური მასპინძლის კონფიგურაციაზე, უფრო საიმედოა იქ დირექტორიის დაბლოკვა:

<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. WordPress-ის განახლება

ადმინისტრაციული პანელის ან WP-CLI-ის მეშვეობით

თუ წვდომა დაბლოკილი გაქვთ wp-content/upgrade/ (ნაბიჯი 2), განაახლეთ ჩვეულებისამებრ — ადმინისტრაციული პანელიდან ან WP-CLI-ის გამოყენებით:

wp core update
wp core update-db
wp core version

ბოლო ბრძანება უნდა აჩვენებდეს 7.1.4 ვერსიას ან თქვენი ტოტის ფიქსირებულ ვერსიას.

ხელით, შეტევის ფანჯრის გარეშე

თუ ვებ სერვერის დონეზე დირექტორიაზე წვდომის დაბლოკვა შეუძლებელია (მაგალითად, მის კონფიგურაციაზე წვდომა არ გაქვთ), უფრო უსაფრთხოა ხელით განახლება. არქივი ამოღებულია საიტის root-ის გარეთ და ფაილები კოპირდება მასზე შეხების გარეშე. 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*

მოთხოვნები a-თი 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 ოქტომბრამდე შექმნილი სარეზერვო ასლიდან, განაახლეთ WordPress და შეცვალეთ ყველა პაროლი: ადმინისტრატორის, მონაცემთა ბაზის, FTP და SSH.

თუ თქვენს ადგილს კონტრაქტორი უვლის

გაუგზავნეთ მათ ეს სტატია და სთხოვეთ, დაადასტურონ, რომ საიტი განახლდა გამოსწორებულ ვერსიამდე და შემოწმდა დაზიანების ნიშნები.

დახმარება მჭირდება?

არ ხართ დარწმუნებული, რომ ამის მოგვარებას თავად შეძლებთ, ან საეჭვო ფაილები იპოვეთ? დაუკავშირდით ჩვენს დახმარების გუნდს — ჩვენ დაგეხმარებით ამის მოგვარებაში.