Літо 2026 видалося важким для сайтів на WordPress: три критичні оновлення за півтора місяця, одне з них — з примусовим автооновленням. Розбираємо, що сталося і що перевірити власнику сайту сьогодні.
Хронологія
Травень: WordPress 7.0
20 травня вийшов WordPress 7.0 «Armstrong» — перший великий реліз року. Головне для власників: мінімальна версія PHP піднялася до 7.4. Сайти на PHP 7.2 і 7.3 просто не оновлюються до нової гілки й залишаються без патчів безпеки.
17 липня: екстрені 6.9.5 і 7.0.2
Дослідники безпеки з Assetnote (Searchlight Cyber) розкрили вразливість, названу wp2shell: віддалене виконання коду без авторизації. Це найгірший клас вразливостей — зловмиснику не потрібні ні пароль, ні обліковий запис.
WordPress випустив екстрені релізи з примусовим автооновленням, тобто оновлення розкотили навіть на сайти, де автооновлення було вимкнене (офіційна новина).
6 серпня: 7.0.3
Реліз лише з виправленнями безпеки — 12 вразливостей за раз (розбір релізу).
Далі: 7.0.4
Закриває виконання коду через завантаження файлу для користувачів рівня «автор» і вище на сайтах, що використовують Imagick і Ghostscript. Якщо у вас кілька редакторів або відкрита реєстрація — це саме про вас.
Чому це стосується звичайного сайту-візитівки
Поширена помилка: «у нас маленький сайт, кому ми потрібні». Масові зломи WordPress ніколи не вибирають жертву. Працює це так: з’являється публічний опис вразливості — за години запускаються сканери, які перебирають усі сайти підряд і б’ють по тих, хто не оновився.
Ситуація погіршилася ще й тому, що в WordPress 7.0 з’явився Abilities API та глибша інтеграція з AI — нові інтерфейси зловмисники теж сканують автоматизованими інструментами.
Наслідки типові й неприємні: сторінки з чужою рекламою, редиректи на сторонні сайти, розсилка спаму з вашого домену, а далі — позначка «небезпечний сайт» у Google і вилітання з видачі.
Що перевірити сьогодні
- Версія ядра. Консоль → Оновлення. Має бути актуальна гілка 7.0.x. Якщо бачите 6.x — ви пропустили щонайменше два критичні патчі.
- Версія PHP. У панелі хостингу. 7.4 — необхідний мінімум, робочий варіант — 8.2 або 8.3. На старих версіях сайт просто не отримає оновлень.
- Автооновлення ядра увімкнені хоча б для випусків безпеки.
- Плагіни й теми. Більшість зломів приходить не через ядро, а через плагіни. Видаліть усе, чим не користуєтесь: неактивний плагін теж є на диску й теж вразливий.
- Резервні копії. Не «вони начебто робляться», а перевірено відновленням. Бекап, з якого жодного разу не відновлювалися, — це припущення, а не бекап.
- Зайві точки входу. xmlrpc, відкрита реєстрація, старі облікові записи звільнених співробітників, файли з паролями й ключами у публічних папках.
Про файли, які «просто лежать поруч»
Окрема поширена проблема — резервні копії файлів прямо в теці сайту: functions.php.bak, config-old.php, dump.sql. Такі файли не виконуються сервером, а віддаються як звичайний текст: будь-хто, хто вгадає ім’я, прочитає ваш код, а іноді й доступи до бази чи ключі API.
Правило просте: резервні копії зберігаються поза кореневою текою сайту. Завжди.
Що робити, якщо оновлюватися страшно
Побоювання зрозуміле: оновив — і щось відвалилося. Робочий порядок:
- зробити повну копію — файли й база;
- оновити спочатку на тестовій копії, у хостингів це зазвичай робиться в один клік;
- перевірити головне: форми, кошик, оплату, адмінку;
- і лише потім оновлювати бойовий сайт.
При цьому пам’ятайте: за статистикою після виходу 7.0 близько 46% сайтів автооновилися протягом тижня без поломок. Ризик зламати сайт оновленням значно менший за ризик не оновитися.
Коротко
Три критичні релізи за півтора місяця — це не аномалія, а нова норма. Сайт без оновлень не «стоїть як стояв», він щодня стає вразливішим.
Якщо не хочете стежити за цим самі — ми беремо сайти на технічну підтримку, зокрема зроблені іншими підрядниками: оновлення, бекапи з перевіркою, моніторинг і аудит стану. Почати можна з аудиту — отримаєте перелік проблем із поясненням, що критично, а що почекає.
Telegram