Технології

Уразливість у WordPress: сайти залишаються під загрозою навіть під час встановлення оновлення

Редакція LinksGauge4 хв читання

Схема процесу оновлення WordPress із попередженням про ризик безпеки в папці upgrade

Головне за 30 секунд

  • Уразливість CVE-2026-119977 зачіпає версії WordPress від 4.7 до 7.1.3 та дозволяє виконати PHP-код із правами вебсервера.
  • Небезпека зберігається навіть під час оновлення до безпечної версії 7.1.4, оскільки старий код розпаковує файли в передбачувану папку.
  • Дослідник Умут Байрам рекомендує заблокувати вебдоступ до каталогу wp-content/upgrade/ або виконати оновлення вручну поза кореневою папкою.
  • CISA додала прогалину до каталогу активно експлуатованих уразливостей, а компанія Wordfence зафіксувала атаки вже через 9 хвилин після релізу правила фаєрволу.
Зміст

У чому суть уразливості та чому оновлення не є миттєвим порятунком

Дослідник з компанії Picus Security Умут Байрам (Umut Bayram) виявив критичну проблему в системі оновлень WordPress. Уразливість, що отримала ідентифікатор CVE-2026-119977, впливає на версії WordPress від 4.7 до 7.1.3 inclusive. Суть проблеми полягає в тому, що під час оновлення ядро сайту розпаковує новий дистрибутив у тимчасову папку всередині wp-content/upgrade. У цьому тимчасовому каталозі міститься новий інсталятор WordPress, до якого вебсервер за замовчуванням надає доступ із мережі.

Атака можлива навіть тоді, коли власник ресурсу запускає встановлення виправлення (версії 7.1.4 або відповідних оновлень для старих гілок). Оскільки процес розпакування виконує старий, ще не пропатчений код ядра, на версіях WordPress від 5.9 до 7.1.3 назва тимчасової папки формується на основі імені завантаженого файлу. Це робить її назву повністю передбачуваною для стороннього спостерігача.

Якщо зловмисник без облікового запису зможе вгадати назву цієї папки та звернутися до інсталятора до того, як система видалить тимчасові файли, він отримує можливість підключити власну базу даних, увійти в систему та виконати довільний PHP-код із правами вебсервера. Це дає повний доступ до читання та запису файлів основного сайту.

Які сайти перебувають у зоні найбільшого ризику

Рівень ризику залежить від типу пакунка оновлення та версії WordPress, яка використовується на сайті:

  • Повні пакунки (Complete packages): Завжди містять файли інсталятора, тому під час їх розпакування завжди виникає вікно для потенційної атаки. Вони використовуються під час переходу між різними гілками (наприклад, з 7.0.7 до 7.1.4), а також якщо контрольні суми файлів сайту не збігаються з офіційними або здійснюється перевстановлення.
  • Часткові пакунки (Partial packages): Зазвичай пропонуються для оновлень у межах однієї гілки (наприклад, з 7.1.3 до 7.1.4). Вони створюють ризик лише в тому випадку, якщо до списку змінених файлів потрапили файли інсталятора. Якщо їх там немає, тимчасова копія не зможе запуститися як інсталятор.
  • Старі версії (від 4.4 до 5.8): Старий код у цих версіях додає випадкові символи до назви тимчасової папки, що ускладнює її вгадування, якщо сайт не викриває цю назву через повідомлення про помилки.
  • Застарілі версії (4.6 і старші): WordPress 4.6 та раніші версії більше не отримують оновлень безпеки. За даними дослідника, проблема існує ще з версії WordPress 2.7, випущеної у 2008 році. Власникам таких ресурсів рекомендується терміново перейти на підтримувану версію.

Способи захисту та рекомендації щодо безпечного оновлення

Щоб усунути ризик атаки безпосередньо під час оновлення, дослідник радить заблокувати мережевий доступ до тимчасової папки. Оскільки сам WordPress працює з цією папкою безпосередньо на диску, обмеження вебдоступу не порушить процес оновлення.

Рекомендовані кроки для захисту:

  1. Налаштування Nginx: Додайте до конфігурації правило location ^~ /wp-content/upgrade/ { deny all; }.
  2. Налаштування Apache: Додайте директиву Require all denied всередині блоку <Directory> для відповідної папки у конфігурації віртуального хосту.
  3. Використання .htaccess: Додайте рядок RedirectMatch 403 ^/wp-content/upgrade/ у файл .htaccess, який розташований у кореневій папці WordPress (обов'язково вище основних правил перезапису). Важливо: не розміщуйте файл .htaccess у самій папці wp-content/upgrade, оскільки старий модуль оновлення повністю очищає її вміст перед розпакуванням.
  4. Переконайтеся, що запит до /wp-content/upgrade/ повертає помилку 403, після чого виконайте оновлення до версії 7.1.4.

Альтернативне безпечне рішення — ручне оновлення поза межами кореневого каталогу вебсервера (web root). Для цього потрібно зробити резервну копію, розпакувати новий реліз у закритій для вебдоступу папці, скопіювати файли ядра без заміни wp-config.php та папки wp-content, а потім запустити оновлення бази даних. Використання консольної утиліти WP-CLI (команда wp core update) не захищає від проблеми, оскільки вона запускає той самий механізм і розпаковує файли в ту ж папку.

Активність зловмисників та оцінка загрози

Агентство з кібербезпеки та захисту інфраструктури США (CISA) додало CVE-2026-119977 до каталогу відомих експлоатованих уразливостей через наявність даних про реальні атаки. Компанія Wordfence оцінила уразливість у 8.1 бала з 10 за шкалою CVSS і повідомила, що перші спроби атак було зафіксовано вже через 9 хвилин після випуску правила для фаєрволу. Джерела найбільшого трафіку сканували сайти протягом 14,5 години, намагаючись спіймати момент оновлення.

У лабораторних тестах вікно для здійснення атаки тривало лише кілька секунд. Офіційне повідомлення від WordPress класифікує уразливість як низьку. У публічних репозиторіях GitHub вже з'явився код, який описують як експлойт для цієї проблеми. Якщо сайт тривалий час залишався без оновлення, фахівці Wordfence рекомендують перевірити логи на наявність підозрілих запитів до PHP-файлів у директорії wp-content/upgrade або появу там сторонніх файлів.