Виправлення WordPress для експлуатованої вразливості може короткочасно відкрити деякі сайти під час оновлення

Деякі сайти WordPress можуть залишатися відкритими для атак під час встановлення виправлення для активно експлуатованої вразливості, за словами Умута Байрама, дослідника 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 з тимчасової копії вже не перезаписує справжній. Байрам сказав, що часткове відкриття залежить від вмісту пакета, а сайт переходить до повного пакета, якщо контрольні суми не збігаються або під час перевстановлення. Вирішальним фактором є те, чи вже виправлений встановлений оновлювач.

Що мають робити адміністратори

Байрам рекомендує заблокувати веб-доступ до 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, компанія з безпеки WordPress, яка й призначила ідентифікатор CVE, побачила, що спроби почалися через дев'ять хвилин після розгортання правила брандмауера у день випуску; два найактивніші джерела перевіряли невеликі групи сайтів приблизно 14,5 години, що, за словами компанії, узгоджується зі спробами вловити момент оновлення сайту. Оцінка в записі CVE становить 8,1 з 10 за шкалою CVSS, тоді як WordPress оцінює вразливість як низьку. У публічних репозиторіях GitHub з'явився код, який його автори описують як експлойт; один із них твердить, що код працює і на сайтах, які під час оновлення повним пакетом досі використовують передбачувану папку. Чи працює цей код, не встановлено. Для сайтів, що після випуску залишилися на вразливій версії, Wordfence радить шукати неочікувані запити до PHP-файлів під wp-content/upgrade, невідомі облікові записи адміністраторів, плагіни, які ніхто не встановлював, і PHP-файли там, які ніхто не розміщував.

Джерела: The Hacker News