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

ვინ არის საფრთხის ქვეშ

ყველა განახლება ინსტალერს არ ამჟღავნებს. სრული პაკეტები მას ყოველთვის შეიცავს; ნაწილობრივი პაკეტი საიტს მხოლოდ მაშინ გამოამჟღავნებს, თუ ის ინსტალერის ფაილებს შეიცავს. ავტომატური განახლებები იმავე განახლების მექანიზმს იყენებს. 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-CLI-ის wp core update ამის შემცვლელი არ არის. WordPress 4.6 და უფრო ადრეული ვერსიები უსაფრთხოების განახლებებს არ იღებენ, ხოლო ხარვეზი 2.7 ვერსიიდან მოდის, რომელიც 2008 წელს გამოვიდა.

ექსპლუატაცია და შემოწმებები

CISA-მ ხარვეზი კატალოგში აქტიური ექსპლუატაციის მტკიცებულების საფუძველზე შეიტანა, თუმცა თავდასხმები არ აღუწერია. Wordfence-მა, რომელმაც CVE იდენტიფიკატორი მიანიჭა, შენიშნა, რომ მცდელობები გამოშვების დღეს ფაირვოლის წესის ჩართვიდან ცხრა წუთში დაიწყო; ორი ყველაზე აქტიური წყარო მცირე ჯგუფებს დაახლოებით 14,5 საათის განმავლობაში ამოწმებდა, რაც ემთხვევა საიტის განახლების მომენტის დაჭერის მცდელობას. CVE-ის ჩანაწერში ხარვეზის შეფასება CVSS სკალაზე 10-დან 8,1-ია, მაშინ როცა WordPress-ის საკუთარი გაფრთხილება ხარვეზს დაბლად აფასებს. საჯარო GitHub-ის რეპოზიტორიებში გამოჩნდა კოდი, რომელსაც ავტორები ხარვეზის ექსპლოიტად აღწერენ; ერთი მათგანის მტკიცებით, მისი კოდი მუშაობს იმ საიტებზეც, რომლებიც სრული პაკეტის განახლებისას კვლავ პროგნოზირებად საქაღალდეს იყენებს. დადგენილი არ არის, მუშაობს თუ არა ეს კოდი. Wordfence-ის რეკომენდაციით, შეამოწმეთ wp-content/upgrade-ის ქვეშ PHP ფაილებზე მოულოდნელი მოთხოვნები, არავისთვის ცნობილი ადმინისტრატორის ანგარიშები, არავის მიერ დაყენებული პლაგინები და იქ არავის მიერ მოთავსებული PHP ფაილები.

წყაროები: The Hacker News