WordPress 7.1.4: вразливість уже атакують. Як за хвилину перевірити, чи оновився ваш сайт — це питання, яке після 3 листопада 2026 року варто поставити кожному власнику сайту на WordPress. 28 жовтня вийшло термінове оновлення безпеки 7.1.4, яке закриває 22 вразливості. Найнебезпечніша з них дозволяє виконати чужий код на сервері в момент оновлення сайту, а 3 листопада американське агентство кібербезпеки CISA внесло її до каталогу вразливостей, які вже використовують в атаках.
Більшість сайтів отримали 7.1.4 автоматично — WordPress сам ставить такі оновлення у фоні. Але «більшість» не означає «ваш». Автооновлення можуть бути вимкнені, не спрацювати через налаштування хостингу чи права на файли, а старі копії сайту на піддоменах часто взагалі ніхто не оновлює. Тому перевірити версію краще самостійно, а не припускати, що все гаразд.
Нижче розберемо, що саме виправили в 7.1.4, чому про цю вразливість заговорили знову, як за хвилину дізнатися версію свого сайту, чому WordPress іноді не оновлюється сам і що зробити після оновлення.
Читайте також цікаву статтю на тему: що робити власнику сайту, коли знаходять критичну діру в PHP.
Потрібна консультація зі створення або просування сайту?
Відповімо на питання й підкажемо, з чого почати — безкоштовно.
Що сталося: WordPress 7.1.4 і 22 закриті вразливості
28 жовтня 2026 року команда WordPress випустила версію 7.1.4. Це не реліз із новими функціями, а чисте оновлення безпеки: у ньому немає змін в інтерфейсі чи редакторі, зате закрито 22 вразливості (такий підрахунок наводять дослідники Patchstack та профільні видання; в офіційному анонсі частина проблем об’єднана в спільні пункти). Офіційна рекомендація розробників WordPress коротка: оновити сайти негайно.
Виправлення стосуються не лише останньої версії. Їх перенесли в усі старші гілки, які ще отримують оновлення безпеки, — аж до 4.7. Тобто сайт на 6.9 чи 7.0 не мусить переходити на 7.1, але має отримати свою виправлену версію. А от сайти на WordPress 4.6 і старших жодних виправлень не отримали взагалі.
Що саме виправили
- Вразливість у процесі оновлення, яка за певних умов дозволяє виконати чужий код на сервері (remote code execution, RCE). Саме вона найнебезпечніша.
- Понад десяток сценаріїв збереженого XSS — коли в контент сайту можна вбудувати шкідливий скрипт, який потім виконується в браузері адміністратора чи відвідувача. Ішлося про розмітку блоків, блоки зображень і плейлистів, рубрики, пагінацію коментарів, логіни користувачів, запити на видалення персональних даних, Customizer та Interactivity API.
- Витоки інформації: неопубліковані зміни з Customizer могли бути видимі неавторизованим відвідувачам, а нотатки до записів — користувачам, які не мають права редагувати сам запис.
- Відмова в обслуговуванні через Interactivity API — спосіб «покласти» окремі сторінки.
- Оновлення кореневих сертифікатів, вбудованих у WordPress, після відкликання сертифікатів центру eMudhra. Від цього залежать захищені з’єднання, які сайт робить сам: оплати, API, оновлення.
Для більшості XSS-вразливостей зловмисник має вже мати обліковий запис на сайті — наприклад, автора чи контриб’ютора. Тому найбільший ризик вони несуть сайтам, де пишуть кілька людей, є блоги з гостьовими авторами або відкрита реєстрація. Вразливість в оновленні — інша історія: для неї обліковий запис не потрібен.
Чому про цю вразливість заговорили знову 3 листопада
Коли 7.1.4 тільки вийшов, дослідники Patchstack оцінили експлуатацію RCE-вразливості як складну: атака можлива лише протягом кількох секунд, поки триває оновлення. Багато хто заспокоївся — мовляв, теоретична загроза, і автооновлення все одно все закриють.
3 листопада 2026 року агентство кібербезпеки США CISA внесло цю вразливість (CVE-2026-119977, «Time-of-check Time-of-use race condition у ядрі WordPress») до свого каталогу Known Exploited Vulnerabilities. У цей каталог потрапляють лише вразливості, для яких є підтвердження реальних атак. Державним установам США, за даними профільних видань, дали на оновлення лише кілька днів. Для власника звичайного сайту висновок простий: це вже не теоретична загроза, а інструмент, який хтось використовує.
Чим ризикує сайт, який не оновився
Виконання коду на сервері — найгірший сценарій для сайту. Зловмисник може залишити собі «чорний хід» (бекдор), додати прихованого адміністратора, вбудувати спам-посилання чи редирект на шахрайські сайти, вкрасти дані замовлень і клієнтів, розсилати спам із вашого хостингу. Часто власник дізнається про злам не одразу, а тоді, коли Google позначає сайт як небезпечний, хостинг блокує акаунт або клієнти скаржаться на дивні переадресації.
Як працює атака під час оновлення — простими словами
Коли WordPress оновлює сам себе, плагін чи тему, він спершу розпаковує завантажений архів у тимчасову папку wp-content/upgrade, а потім копіює файли на місце. До версії 7.1.4 назву цієї папки можна було передбачити, а захисний файл, що забороняє переглядати її вміст, видалявся під час прибирання. У результаті на кілька секунд у відкритій частині сайту лежала повна копія WordPress — разом зі сторінкою первинного встановлення.
Якщо зловмисник встигав звернутися до цієї копії саме в цей момент, він міг запустити «встановлення WordPress» зі своєю базою даних і отримати можливість виконувати код на вашому сервері. Звичайні плагіни безпеки тут не допомагають: тимчасова копія завантажує власні файли й не бачить захисту, налаштованого в основному сайті.
У 7.1.4 до назви тимчасової папки додають випадкові символи, захисний файл більше не видаляється, а конфігурація сайту не копіюється в робочу папку. Важливий нюанс: «вікно» для атаки відкривається під час кожного оновлення, зокрема автоматичного. Саме тому оновлення до 7.1.4 закриває проблему, а додаткова заборона доступу до папки wp-content/upgrade на рівні сервера — хороша страховка на майбутнє.
Як за хвилину перевірити, чи оновився ваш сайт
Перевірка справді займає хвилину, якщо у вас є доступ до адмінки. Якщо доступу немає або сайт веде підрядник — попросіть його надіслати скріншот із версією, це нормальне прохання.
Спосіб 1. Консоль WordPress
Увійдіть в адмінку і відкрийте «Консоль → Оновлення». Угорі сторінки WordPress пише, яка версія встановлена і чи є новіша. Версію також видно внизу будь-якої сторінки адмінки, праворуч, і в блоці «На виду» на головній сторінці консолі.
Спосіб 2. «Здоров’я сайту»
Відкрийте «Інструменти → Здоров’я сайту». Тут WordPress не лише показує версію, а й перевіряє, чи працюють фонові оновлення. Якщо є проблеми з автооновленнями, із запланованими завданнями або з правами на файли, ви побачите їх у списку рекомендацій. Цей екран варто відкрити навіть тоді, коли версія вже правильна.
Спосіб 3. Пошта адміністратора
Після успішного автооновлення WordPress надсилає лист «Your site has updated to WordPress 7.1.4» (або аналогічний українською) на email адміністратора сайту. Якщо листа немає, це ще не означає, що оновлення не відбулося, — але варто перевірити, на яку адресу взагалі приходять листи від сайту. Нерідко там досі стоїть пошта колишнього розробника.
Яка версія вважається безпечною
- гілка 7.1 — 7.1.4 і новіші;
- гілка 7.0 — 7.0.8;
- гілка 6.9 — 6.9.11;
- гілка 6.8 — 6.8.12;
- старші гілки — остання версія своєї гілки (наприклад, 6.4.14), аж до 4.7.39;
- WordPress 4.6 і старший — виправлень немає, такий сайт потребує повного оновлення.
Якщо ваш сайт на старій гілці, він захищений від цієї вразливості, але не отримує нових функцій і швидше «старіє». Планувати перехід на актуальну версію все одно варто — краще спокійно, з тестовою копією, ніж у паніці після зламу.
Чому WordPress може не оновитися сам
Фонові оновлення в WordPress увімкнені за замовчуванням для мінорних версій і оновлень безпеки. Проте на практиці ланцюжок «вийшов реліз → сайт оновився» рветься частіше, ніж здається. Ось найчастіші причини.
Автооновлення вимкнули свідомо
Розробник міг вимкнути їх у файлі конфігурації або плагіном керування оновленнями, щоб «нічого не зламалося». Логіка зрозуміла, але тоді хтось має оновлювати сайт вручну. Якщо цього «когось» немає, сайт роками залишається на старій версії.
Не працюють заплановані завдання (WP-Cron)
Перевірку оновлень WordPress запускає через свій планувальник завдань. Якщо планувальник вимкнений без заміни на системний cron, якщо хостинг блокує внутрішні запити сайту до самого себе або якщо сторінки повністю віддаються з кешу і PHP майже не запускається, перевірка оновлень просто не відбувається. Зовні сайт працює нормально, а оновлення тихо зупиняються.
Немає прав на запис або закінчилося місце
Щоб оновитися, WordPress має записати нові файли. Неправильні права доступу, інший власник файлів або переповнений диск на хостингу — і оновлення завершується помилкою. Після серйозної невдалої спроби WordPress надсилає лист адміністратору і може не повторювати автооновлення, доки його не оновлять вручну.
Сайт під системою контролю версій
Якщо на сервері в папці сайту є службова папка Git чи SVN, WordPress вважає, що оновленнями керує розробник, і сам ядро не оновлює. Це правильна поведінка — але тоді оновлення має бути частиною процесу розробника.
Забуті копії сайту
Тестові піддомени, старі версії до редизайну, копії «на всяк випадок» — їх ніхто не відкриває, а отже й не оновлює. Коли ми після виходу 7.1.4 перевірили сайти, які обслуговуємо, всі робочі сайти вже стояли на новій версії завдяки автооновленням. А от кілька старих тестових копій на тому ж хостингу залишилися на версіях 6.x і 7.1.1. Вони не були доступні з інтернету, але це хороший приклад: перевіряти треба не лише головний сайт, а все, що лежить поруч.
Що зробити після оновлення
Оновлення до 7.1.4 закриває вразливість, але не скасовує наслідків, якщо сайт уже встигли атакувати. Тому після оновлення варто зробити кілька простих перевірок — особливо якщо сайт довго стояв на старій версії.
- Перевірте, що сайт працює. Відкрийте головну, кілька сторінок послуг, форму заявки, кошик і оплату, якщо це магазин. Оновлення безпеки рідко щось ламають, але перевірка займає п’ять хвилин.
- Подивіться список адміністраторів. «Користувачі → Усі користувачі», фільтр за роллю «Адміністратор». Кожного незнайомого — з’ясувати і видалити.
- Перевірте папку wp-content/upgrade. Поза моментом оновлення в ній має бути лише службовий файл index.php. Інші PHP-файли там — привід для детальної перевірки.
- Попросіть заборонити доступ до wp-content/upgrade з інтернету. Це одне правило в налаштуваннях вебсервера (.htaccess або конфігурації Nginx). Оновлень воно не ламає, бо WordPress працює з цією папкою напряму, а не через браузер.
- Перевірте автооновлення плагінів і тем. Ядро — лише частина історії: більшість зламів WordPress відбувається через застарілі плагіни.
- Переконайтеся, що є свіжа резервна копія, яка зберігається не лише на тому ж сервері, — і що її реально можна відновити.
Якщо щось із цього здається складним або на сайті щось уже виглядає підозріло, краще не відкладати. Це саме та робота, яку закриває технічне обслуговування сайту з контролем оновлень і бекапів: перевірка версій, моніторинг і реакція на такі новини входять у щомісячну роботу, а не робляться «колись потім».
Кого ця новина стосується найбільше
Оновитися мають усі сайти на WordPress, але для деяких ризик і наслідки помітно вищі. Якщо ваш сайт у списку нижче, перевірку краще зробити сьогодні.
- Інтернет-магазини. Дані клієнтів і замовлень, платіжні інтеграції — найцінніша здобич, а простій магазину коштує грошей щогодини.
- Сайти з кількома авторами або відкритою реєстрацією. Для них актуальні й XSS-вразливості, які потребують облікового запису.
- Сайти, які давно ніхто не обслуговує. Розробник зробив сайт кілька років тому, доступи загубилися, а оновлення «мали йти самі».
- Сайти на старих гілках WordPress. Особливо 4.6 і старші, які не отримали виправлення взагалі.
- Сайти з тестовими копіями й піддоменами. Головний сайт оновився, а копія на test.domain — ні.
- Сайти з власними доробками ядра чи старими темами. Тут оновлення відкладають через страх «злетить верстка» — і накопичують ризики.
Якщо сайт роками не оновлювався через кастомну тему чи несумісні плагіни, це окреме завдання: спочатку оновлення на тестовій копії, виправлення того, що зламалося, і лише потім — на робочому сайті. Таку роботу ми робимо в межах доопрацювання сайтів на WordPress.
Оновлення безпеки WordPress: чому їх стало більше
7.1.4 — уже не перше термінове оновлення безпеки ядра за літо й осінь 2026 року. Частково це наслідок того, що вразливості шукає більше людей і автоматизованих інструментів, зокрема з використанням штучного інтелекту. Частково — того, що WordPress залишається найпоширенішою платформою для сайтів, а отже, найпривабливішою ціллю.
Для бізнесу з цього випливає не «WordPress небезпечний», а «WordPress потребує обслуговування». Платформа швидко закриває знайдені проблеми, але захищеними є лише ті сайти, на яких виправлення справді встановлено. Між релізом і атакою сьогодні минають дні, а не місяці.
Типові помилки власників сайтів
- Вважати, що автооновлення спрацювали, і не перевіряти версію.
- Вимкнути автооновлення «щоб нічого не зламалося» і ніколи не оновлювати сайт вручну.
- Не мати доступу до адмінки власного сайту — усі паролі в колишнього підрядника.
- Отримувати системні листи WordPress на пошту, яку ніхто не читає.
- Забувати про тестові копії, піддомени й старі версії сайту на тому ж хостингу.
- Оновити ядро, але залишити застарілі плагіни й теми.
- Користуватися «піратськими» плагінами й темами, які не оновлюються взагалі.
- Оновлювати без резервної копії, а потім нічого не мати для відкату.
- Тримати бекапи лише на тому ж сервері, що й сайт.
- Роками сидіти на старій гілці WordPress через страх, що «злетить» тема.
- Не перевіряти список адміністраторів після новин про вразливості.
- Ігнорувати попередження у «Здоров’ї сайту».
- Покладатися лише на плагін безпеки — він не захищає від усіх сценаріїв, зокрема від цього.
- Дізнаватися про злам від клієнтів або з попередження Google, а не з моніторингу.
Чек-лист: перевірка сайту після виходу WordPress 7.1.4
- Версія WordPress — 7.1.4 або виправлена версія вашої гілки.
- У «Здоров’ї сайту» немає критичних проблем.
- Фонові оновлення працюють — WordPress не пише про проблеми з ними.
- Заплановані завдання (WP-Cron або системний cron) виконуються.
- Email адміністратора актуальний, листи від сайту приходять.
- Лист про оновлення до 7.1.4 отримано або оновлення перевірено вручну.
- Тестові копії та піддомени теж оновлені або видалені.
- У списку адміністраторів немає незнайомих облікових записів.
- Паролі адміністраторів надійні й не використовуються деінде.
- У wp-content/upgrade немає сторонніх PHP-файлів.
- Доступ до wp-content/upgrade з інтернету заборонено на рівні сервера.
- Плагіни й теми оновлені, невикористані — видалені.
- Немає «піратських» плагінів і тем.
- Є свіжа резервна копія поза сервером сайту.
- Відновлення з бекапу хоча б раз перевірено.
- Сайт відкривається, форми й оплата працюють.
- Google Search Console не повідомляє про проблеми безпеки.
- Відома відповідальна людина, яка стежить за оновленнями.
Часті питання
Варто зробити дві речі: переконатися в «Здоров’ї сайту», що автооновлення працюють і надалі, та швидко переглянути список адміністраторів. Якщо сайт оновився вчасно, наслідків атаки майже напевно немає, але перевірка займає кілька хвилин.
Оновлення безпеки в межах однієї гілки (наприклад, із 7.1.3 до 7.1.4) змінюють дуже мало коду і майже ніколи не ламають сайти. Ризик вищий, якщо сайт роками не оновлювався і потрібно перескочити кілька великих версій, — тоді краще оновлювати спочатку тестову копію.
Ця конкретна вразливість — ні. Але принцип той самий для будь-якої CMS: оновлення безпеки треба встановлювати швидко, а їхню наявність — перевіряти, а не припускати.
Ознаки: незнайомі адміністратори, нові файли з дивними назвами, переадресації на сторонні сайти (часто лише для мобільних або для відвідувачів із Google), спам-сторінки в пошуку за запитом «site:ваш-домен», попередження від Google чи хостингу. Якщо бачите щось подібне — не видаляйте файли навмання, спершу зробіть копію і зверніться до фахівця.
Хвилина на перевірку версії дешевша за відновлення після зламу
WordPress 7.1.4 закриває вразливість, яку вже використовують в атаках. Більшість сайтів отримали виправлення автоматично, але саме ті, що «випали» з автооновлень, і стають цілями. Тому відкрийте «Консоль → Оновлення» і «Здоров’я сайту» сьогодні, а не тоді, коли щось піде не так.
Якщо ви не впевнені, хто відповідає за оновлення вашого сайту, — це і є головний висновок із цієї новини. Безпечний сайт — це не одноразова розробка, а регулярний догляд. Ми робимо створення сайтів на WordPress під ключ і далі беремо їх на ведення сайту з контролем оновлень, щоб такі новини для наших клієнтів закінчувалися листом «усе вже оновлено».
