CVE-2026-119977: Уразливість RCE у ядрі WordPress, яку експлуатують під час оновлень програмного забезпечення

У WordPress Core виявлено вразливість високої важливості, яка активно використовується в атаках, змушуючи Агентство кібербезпеки та інфраструктурної безпеки США (CISA) додати цю вразливість до каталогу відомих експлуатованих вразливостей (KEV). Відстежувана як CVE-2026-119977, вразливість має CVSS бал 8.1 і може дозволити неавтентифікованому зловмиснику виконати довільний код на вразливому сервері під час оновлення WordPress Core.

Вразливість походить від гонки станів типу time-of-check time-of-use (TOCTOU) у процесі оновлення WordPress. Під час повних оновлень Core WordPress тимчасово зберігає файли інсталяції в передбачуваних, доступних через веб-локації. Зловмисники можуть повторно досліджувати ці локації та намагатися досягти компонентів інсталятора під час короткого періоду, коли відбувається оновлення.

WordPress вирішив цю проблему у версії 7.1.4, випущеній 28 жовтня 2026 року. Вразливість стосується версій WordPress з 4.7 по 7.1.3, при цьому виправлення безпеки також було назад портовано на відповідні старіші галузі. WordPress підкреслює, що підтримується лише останній випуск.

Ризик вийшов за межі теоретичної експлуатації. Телеметрія Wordfence, про яку повідомляє The Hacker News, зафіксувала понад 18 500 запитів, які націлювалися на шляхи до інсталяторів setup-config.php під час перших 21 годин після розкриття. Пізніше CISA підтвердило наявність доказів експлуатації та вимагало від відповідних федеральних цивільних агентств США усунути вразливість до 6 листопада 2026 року.

Команди з безпеки можуть використовувати платформу SOC Prime, щоб підвищити охоплення виявлення нових методів експлуатації та виявити підозрілу активність, пов’язану з вразливими системами, що доступні з Інтернету. Виявляйте експлуатацію CVE-2026-119977, спостерігаючи за аномальними запитами до місць оновлення WordPress, несподіваним виконанням PHP, нещодавно створеними адміністративними обліковими записами, підозрілими файлами та поведінкою після експлуатації.

Контент для виявлення може бути недоступним для кожного CVE. Перевірте платформу SOC Prime для актуального охоплення. Якщо відповідні виявлення ще не доступні, перевірте знову, оскільки нові загрози і контент для виявлення додаються постійно.

Зв’язатися з відділом продажів

Аналіз CVE-2026-119977

CVE-2026-119977 класифікується як гонка станів TOCTOU за CWE-367 та має бал CVSS 3.1 8.1. Його показник відображає експлуатацію на основі мережі, що не вимагає привілеїв або взаємодії з користувачем, з високим потенційним впливом на конфіденційність, цілісність і доступність. Складність атаки оцінюється як високий, оскільки успішна експлуатація залежить від досягнення вразливого ресурсу під час вузького вікна оновлення.

CVE-2026-119977 впливає на випуски WordPress Core з версії 4.7 по 7.1.3. Слабкість не пов’язана з плагіном третьої сторони або темою, вона існує в самому механізмі оновлення Core.

Проблема виникає під час повних оновлень Core. WordPress тимчасово витягає новий пакет у місце для зберігання під директорією wp-content/upgrade, перш ніж замінити існуючу установку. У постраждалих випусках частини цього місця для зберігання можуть бути передбачуваними і досяжними з веб, поки оновлення триває.

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

Це створює незвичайну модель експлуатації. Вразливий вебсайт WordPress не обов’язково постійно експлуатується. Замість цього зловмисник має перехопити сайт під час короткого періоду, коли повне оновлення пакету виставляє тимчасові файли зберігання (staging). Дослідники вказують, що можливість може тривати лише кілька секунд.

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

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

Перша телеметрія Wordfence показала понад 18 500 запитів на шляхи інсталяторів у перші 21 години. GBHackers пізніше повідомили майже 59 000 заблокованих спроб протягом 24-годинного періоду, тоді як The Hacker News згадує додаткову телеметрію, що демонструє продовження експлуатаційної активності.

Незалежна телеметрія-пастка, згадана The Hacker News, зафіксувала спроби експлуатації 30 жовтня, додатково підкріплюючи рішення CISA класифікувати цю вразливість як активно експлуатовану. Додавання CISA цієї вразливості до KEV значно підвищує нагальність для організацій, які управляють публічною інфраструктурою WordPress.

На момент написання, переглянуті джерела не документують наявність широкодоступного, публічно підтвердженого репозиторію PoC для CVE-2026-119977. Однак, публічний експлуатаційний код не є необхідним для встановлення ризику, оскільки спроби експлуатації вже були спостережені у великому масштабі, і CISA підтвердило активну експлуатацію.

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

WordPress нагородив дослідника безпеки Умутая Байрама за розкриття слабкості процесу оновлення. Версія 7.1.4 була випущена 28 жовтня 2026 року, а запис CVE був опублікований 31 жовтня.

Для виявлення CVE-2026-119977 захисники повинні приділяти особливу увагу веб-запитам, що націлюються на незвичайні шляхи під wp-content/upgrade, особливо запити, що посилаються на збережені копії setup-config.php. Повторювані запити через кілька можливих директорій зберігання можуть вказувати на автоматизоване зондування, що намагається виграти гонку станів.

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

Публічні звіти не ідентифікували всебічний набір індикаторів компрометації (IOC) для CVE-2026-119977 від конкретних зловмисників, таких як стабільні домени командування та управління або хеші шкідливих програм. Це робить виявлення на основі поведінки особливо важливим. Запити на передбачувані шляхи зберігання, підозріла активність під час вікна оновлення та модифікації після компрометації надають більш стійкі можливості для відстеження, ніж покладатися виключно на статичні індикатори.

Пом’якшення CVE-2026-119977

Основним заходом по пом’якшенню CVE-2026-119977 є негайне оновлення WordPress. WordPress 7.1.4 містить виправлення безпеки, а виправлення також були доступні або назад портовані для відповідних старіших гілок випусків. Організації повинні пріоритезувати міграцію до останньої активно підтримуваної версії WordPress, а не покладатися на підтримку безпеки для застарілих випусків.

Адміністратори повинні виконати наступні дії:

1. Оновіть установки WordPress, що доступні з Інтернету, до версії 7.1.4 або пізнішої.
2. Переконайтеся, що автоматичні оновлення були успішно завершені, а не просто припускайте, що оновлення застосовано.
3. Інвентаризуйте старіші установки WordPress, включаючи забуті розробницькі, пробні і застарілі сайти.
4. Перегляньте журнали веб-сервера і WAF для запитів, що націлюються на wp-content/upgrade і шляхи до інсталяторів setup-config.php.
5. Досліджуйте несподівані PHP файли, нові облікові записи адміністраторів WordPress, несанкціоновані плагіни та незрозумілі зміни в конфігурації.
6. Перевіряйте вихідні з’єднання і дочірні процеси веб-сервера для ознак активності після експлуатації.
7. Забезпечте, щоб захист WAF працював досить рано в ланцюзі запиту, щоб покрити прямі запити до тимчасових PHP файлів.
8. Розгляньте можливість обмеження прямого веб-доступу до тимчасових директорій оновлень, де це операційно можливо.

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

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

Проведіть огляд логів доступу навколо точного часові оновлення. Запити до постраждалих шляхів зберігання, які відбулися безпосередньо перед або під час оновлення, заслуговують додаткового дослідження. Команди з безпеки повинні потім корелювати ці запити зі змінами у файловій системі, модифікації облікових записів WordPress, виконання PHP, підозрілими мережевими з’єднаннями та іншими індикаторами після експлуатації.

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

Інформація про включення CISA вразливості до KEV підтверджує, що усунення має розглядатися як невідкладний оперативний пріоритет, а не як рутинна задача виправлення. Федеральні цивільні виконавчі агентства були направлені вирішити цю проблему до 6 листопада 2026 року.