Автооновлення WordPress не є доказом безпеки: що перевірити в першу годину

00:00 — замініть «має бути» на перевірений факт

Колега пише: «Автооновлення ж увімкнене». Інший додає: «Перед сайтом є WAF». Але ніхто не може одразу назвати фактичну версію WordPress, показати успішне оновлення або підтвердити, що захисне правило справді блокує запити, а не лише записує їх у журнал.

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

17 липня 2026 року Cloudflare оприлюднила результати скоординованої роботи з командою безпеки WordPress щодо двох проблем у REST API: SQL-ін’єкції з високим рівнем небезпеки та критичної RCE. Захист на рівні WAF корисний, але джерело прямо наголошує: він не замінює оновлення WordPress.

00:05 — знайдіть версію кожного сайту

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

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

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

00:15 — правильно визначте зону ризику

За повідомленням Cloudflare, межі двох проблем різняться:

• версії до 6.8 не уражені саме цими двома вразливостями;
• гілка 6.8 потрапляє в зону ризику SQL-ін’єкції;
• версії від 6.9 також потрапляють у зону ризику SQL-ін’єкції;
• RCE стосується версій від 6.9, якщо немає постійного кешу об’єктів;
• виправлені релізи для відповідних гілок — 6.8.6, 6.9.5 та 7.0.2.

У конфігурації й документації постійний кеш об’єктів часто називається persistent object cache. Не вважайте його наявність загальним захистом: ця умова змінює оцінку RCE, але не усуває окрему SQL-ін’єкцію.

Так само фраза «версія до 6.8 не уражена» не означає, що старий WordPress безпечний загалом. Вона стосується лише двох описаних проблем. Застаріла інсталяція може мати інші відомі вразливості й потребує окремого плану оновлення.

00:25 — перевірте, що WAF блокує, а не спостерігає

WAF може дати час на оновлення, якщо правило застосоване до потрібного сайту й має дію Block. Режим Log лише створює запис про збіг. Запит при цьому може дійти до WordPress.

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

Для Cloudflare відповідні події можна переглядати в Security Events, а стан правил — у налаштуваннях керованих наборів. В інших продуктах назви й можливості відрізняються. Потрібно знайти їхній еквівалент, а не припускати, що будь-який WAF уже має таке саме покриття.

Не копіюйте експлуатаційний запит у виробничий сайт, щоб «перевірити блокування». Безпечніше звірити конфігурацію, побачити подію від офіційного правила та використати схвалений постачальником спосіб тестування. І не вимикайте правило відразу після першого хибного спрацювання: спочатку спробуйте звузити виняток.

00:35 — установіть справжнє виправлення

Створіть придатну для відновлення резервну копію або знімок, але не перетворюйте це на багатогодинну передумову. Оновіть підтримувану гілку до 6.8.6, 6.9.5 або 7.0.2 відповідно до вашої версії та плану сумісності.

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

Не прибирайте WAF-захист одразу після патчу. Спершу підтвердьте версію на всіх вузлах і завершіть первинний перегляд журналів.

00:50 — перевірте сліди, не роблячи передчасних висновків

Визначте період ризику. Мінімум перегляньте події від моменту публічного повідомлення; краще — від останнього підтвердженого безпечного стану, якщо журнали це дозволяють.

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

Збіг правила WAF означає, що запит відповідав умові правила. Це не є автоматичним доказом виконання коду або доступу до даних. Водночас відсутність подій теж не доводить безпеку: журнал міг мати короткий термін зберігання, правило могло бути вимкнене, а частина трафіку — обходити WAF.

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

Коли першу годину можна завершити

Робота має чіткий результат: для кожного сайту відома фактична версія; установлено відповідний виправлений реліз; дія WAF перевірена; винятки переглянуті; визначений період ризику; журнали первинно проаналізовані; подальший моніторинг має власника.

Найнебезпечніший антишаблон тут — вважати налаштування доказом результату. «Автооновлення ввімкнене» не дорівнює «патч установлений». «WAF працює» не дорівнює «правило блокує». Перша година потрібна саме для того, щоб прибрати цю різницю.

Джерела

• Cloudflare, «Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities»: https://blog.cloudflare.com/wordpress-vulnerabilities/