CVE-2026-119977: чому оновлення WordPress саме стало вразливістю

Парадоксальна ситуація, яка трапляється в кібербезпеці нечасто: щоб закрити критичну вразливість, потрібно оновити WordPress. Але саме процес цього оновлення на короткий проміжок часу відкриває сайт для атаки — навіть після того, як виправлення вже випущено. Йдеться про CVE-2026-119977 — вразливість у процесі оновлення ядра WordPress, яку CISA вже внесла до каталогу відомих експлуатованих вразливостей (KEV). Для українських власників сайтів, де WordPress є однією з найпопулярніших CMS, це означає одне: оновлюватись треба, але робити це треба правильно.

Що таке CVE-2026-119977

CVE-2026-119977 — це вразливість типу TOCTOU (time-of-check to time-of-use, «гонка» між перевіркою та використанням) у механізмі оновлення ядра WordPress. Їй присвоєно оцінку CVSS 8.1 — рівень «High». Вразливість виявив дослідник Umut Bayram з компанії Picus Security, а ідентифікатор CVE надав постачальник безпекових рішень Wordfence. WordPress офіційно подякував Байраму за виявлення слабкості в процесі оновлення.

Суть проблеми проста, але витончена. Під час оновлення ядра WordPress завантажує нову версію, розпаковує її у тимчасову теку, перевіряє файли, копіює їх поверх живої інсталяції і лише потім видаляє тимчасову теку. Проблема — у проміжку між розпакуванням і копіюванням. Тимчасова копія містить, зокрема, інсталятор WordPress (wp-admin/setup-config.php), який доступний через вебсервер і виконується без налаштованого конфігураційного файла. Ім'я тимчасової теки передбачуване — воно утворюється з назви пакета оновлення.

Як працює атака: гонка між розпакуванням і копіюванням

Атака не потребує жодного облікового запису. Зловмисник діє повністю анонімно — достатньо знайти правильний момент і передбачуваний шлях.

Сценарій такий. Коли сайт оновлюється «повним» пакетом (complete package), нова версія розпаковується у теку на кшталт wp-content/upgrade/wordpress-7.1.4/. Оскільки ця тека лежить у публічній частині сайту, а PHP-файли в ній виконуються за запитом, зловмисник може звернутися до інсталятора безпосередньо. Ситуацію погіршує ще одна деталь: рутинне очищення перед розпакуванням видаляло з теки wp-content/upgrade/ файл index.php, який зазвичай блокує перегляд списку файлів — тож на серверах з увімкненим лістингом директорій випадкова назва теки могла бути просто видимою.

До виправлення сценарій був ще небезпечнішим. Атакувальник міг записати у тимчасову копію власний wp-config.php, який під час копіювання файлів затирав живий конфігураційний файл. Після цього сайт починав «дивитися» на порожню базу даних під контролем зловмисника, WordPress показував екран налаштування, і атакувальник створював першого адміністратора. На типовому сайті з однією інсталяцією далі достатньо завантажити шкідливий плагін, щоб виконати довільний PHP-код із правами вебсервера.

Wordfence зафіксував, що вікно вразливості в лабораторних умовах тривало лічені секунди. Patchstack оцінює складність атаки як високу. Один запит навряд чи спрацює — але безперервне автоматичне «полінгування» суттєво підвищує шанси, і саме такий патерн зафіксовано в реальному трафіку атак.

Чому оновлення, що виправляє баг, теж небезпечне

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

WordPress 7.1.4 виправляє вразливість трьома змінами:

1. Випадкове ім'я тимчасової теки — до назви додається 16-символьний випадковий суфікс (class-wp-upgrader.php).
2. Збереження index.php у теці оновлення — щоб сервер з увімкненим лістингом директорій не розкривав назву випадкової теки.
3. Виключення wp-config.php з копіювання під час оновлення ядра (update-core.php).

Але перші дві зміни «живуть» у старому коді, який виконує розпакування. Під час першого оновлення на сайтах версії 5.9 і новіше ім'я теки все ще утворюється з назви завантаженого файла — тобто залишається передбачуваним востаннє. Третя зміна (пропуск wp-config.php) спрацьовує одразу, бо файл update-core.php завантажується вже з нового пакета.

Практичний наслідок: під час того самого оновлення, яке має закрити вразливість, зловмисник все ще може дістатися тимчасового інсталятора за передбачуваним шляхом, налаштувати його зі своєю базою даних, увійти та виконати PHP-код із правами вебсервера, перш ніж тимчасова тека буде видалена. Це не дозволяє йому підмінити живий wp-config.php (це вже заблоковано), але дає змогу читати й записувати файли в живій інсталяції WordPress.

Хто під загрозою

Вразливість зачіпає WordPress від версії 4.7 до 7.1.3. Виправлення випущено 28 жовтня 2026 року у версії 7.1.4 і бекпортовано в усі підтримувані гілки аж до 4.7 (4.7.39, 4.8.34, 4.9.35, 5.x, 6.x, 7.0.8 тощо).

Важливі нюанси:

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

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

Вирішальним чинником, як наголошує Байрам, є не «повний чи частковий» пакет, а те, чи оновлювач, уже встановлений на сайті, отримав виправлення.

Як атакували: хронологія та масштаби

Швидкість, з якою зловмисники підхопили вразливість, показова. За даними Wordfence, спроби атак почалися через дев'ять хвилин після того, як компанія розгорнула правило міжмережевого екрана для цієї вади в день випуску виправлення. Раніше Wordfence повідомляв про майже 63 000 спроб атак на цю вразливість.

Характерна деталь: два найактивніші джерела атак упродовж близько 14,5 години періодично перевіряли невеликі групи сайтів. Така поведінка, за оцінкою Wordfence, збігається зі спробами «зловити момент», коли конкретний сайт оновлюється — тобто зловмисники свідомо полюють саме на вікно оновлення.

3 листопада 2026 року CISA додала CVE-2026-119977 до каталогу KEV, підтвердивши активну експлуатацію в реальних умовах. Федеральним цивільним агенціям США було дано кінцевий термін для виправлення — 6 листопада. Власні технічні розбори також опублікували Picus Security, Beazley Security, Patchstack, Ostorlab та інші компанії.

Чому це важливо саме зараз

Історія CVE-2026-119977 показує ширший тренд, про який варто знати кожному, хто адмініструє вебсайти. По-перше, WordPress залишається однією з найбільш атакованих платформ у світі — варто лише з'явитися вразливості в ядрі, як до неї миттєво прикута увага і дослідників, і зловмисників. Джон Странд із Black Hills Information Security порівнює цю увагу з «Оком Саурона»: щойно з'являється одна вразливість, навколо технології утворюється «купа людей, які копають в одному напрямку».

По-друге, сама швидкість появи експлойтів зростає. Umut Bayram у коментарі TechFinitive зазначив, що AI-інструменти роблять подібні дослідження доступними значно ширшому колу людей — зловмисникам включно. «Якщо дослідник-початківець може знайти двадцятирічний RCE за один день, то зможе й атакувальник», — каже він. Це прямий аргумент на користь того, що реагування не можна відкладати.

По-третє, сам висновок дослідника про валідацію безпеки. «Валідація більше не може чекати наступного планового тесту, — радить Байрам. — Вона має запускатися одразу, щойно щось змінилося: вийшов новий CVE, з'явилася консультація, хтось змінив правило фаєрвола. Це і є сигнал».

Як захиститись: покрокові дії

1. Оновіть WordPress до 7.1.4 негайно — або встановіть бекпорт для вашої гілки. Це першочерговий крок.
2. Заблокуйте вебдоступ до теки wp-content/upgrade перед оновленням. Це пряма рекомендація дослідника Umut Bayram: саме так ви закриваєте вікно, яке відкривається під час встановлення виправлення. Для Apache — правило в .htaccess, для Nginx — відповідний location-блок із забороною.
3. Перевірте, що оновлення реально встановилося — у розділі «Dashboard → Updates» (Оновлення). Це стосується й сайтів із увімкненими автоматичними фоновими оновленнями: вони встановлюють виправлення через той самий механізм.
4. Проведіть аудит на ознаки компрометації. Генеральний директор BreachLock Сімант Сігал радить шукати: неочікувані файли в тимчасових теках оновлення, невідомі адміністративні облікові записи, змінений код тем чи плагінів і незвичний вихідний трафік з вебсервера.
5. Для сайтів на WordPress 4.6 і старіших виправлення не існує — єдиний вихід це міграція на підтримувану версію.
6. Зменшіть привілеї вебсервера та переконайтеся, що PHP у теці оновлення не може виконуватися через веб. Найменші привілеї обмежують наслідки, навіть якщо вікно атаки спрацює.

Варто знати: офіційний анонс WordPress 7.1.4 не пропонує обхідного рішення (workaround). Тому блокування вебдоступу до wp-content/upgrade лишається практичним способом знизити ризик у момент оновлення, а для сайтів, які не можна оновити негайно, саме таке блокування суттєво зменшує ймовірність успішної атаки.

Якщо ви підозрюєте, що ваш сайт уже міг бути скомпрометований, перевірте, чи не злиті ваші облікові дані, за допомогою нашого інструмента перевірки витоків. А якщо ви хочете глибше розібратися, як влаштований захист сучасних вебзастосунків, радимо наш матеріал про навчання кібербезпеці.

Висновок

CVE-2026-119977 — рідкісний випадок, коли сама процедура оновлення стає вектором атаки, а «виправлення» не дає повного захисту, поки його встановлюють. Це важливий урок для всіх, хто адмініструє сайти: оновлення — не одномоментна кнопка, а процес із власним вікном ризику. Правильна відповідь — оновлюватися швидко, але з контролем: блокувати вебдоступ до службової теки, перевіряти факт встановлення і проводити аудит після. А сам Umut Bayram наголошує на ширшому висновку: валідація безпеки не повинна чекати наступного планового тесту — вона має запускатися одразу, щойно з'явився новий CVE чи консультація.