21 жовтня PHP випустила термінові оновлення проти двох критичних вразливостей, відомих як PHP2Shell. За офіційним повідомленням, за певних умов вони дозволяють виконати чужий код на сервері без входу в обліковий запис. Для власника сайту головне зараз — з’ясувати, чи встановив хостинг виправлення саме для PHP, і отримати підтвердження для свого домену.
Що сталося і чому це стосується WordPress
Йдеться про CVE-2026-109618 та CVE-2026-109619. The PHP Foundation описує помилки в обробці нестачі пам’яті та залишкового стану між запитами. Це проблеми середовища виконання, на якому працюють різні вебзастосунки. Дослідження й перевірку проводили кілька команд, зокрема із застосуванням ШІ; підготовка патчів і рішення щодо випуску залишалися роботою людей. Тому формулювання «ШІ сам зламав увесь інтернет» не передає змісту події.
Команда WordPress окремо наголосила: ці вразливості не є специфічними для CMS, і спеціального оновлення WordPress для них не планують. Наявність останньої версії CMS або плагіна безпеки не підтверджує, що сервер уже виправлено. Перевірити показану версію PHP можна в адмінці: «Інструменти» → «Здоров’я сайту» → «Інформація» → «Сервер». У панелі хостингу також часто є відповідний розділ.
Які версії містять виправлення
Проєкт PHP назвав такі релізи з виправленнями. Для звичайних збірок потрібен цей реліз або новіший у відповідній гілці; для пакетів із перенесеними патчами дивіться уточнення нижче.
| Гілка PHP | Реліз із виправленнями |
|---|---|
8.2 | 8.2.35 |
8.3 | 8.3.36 |
8.4 | 8.4.27 |
8.5 | 8.5.12 |
Є важлива деталь: постачальник Linux або хостинг може перенести виправлення у свій пакет зі старішим номером PHP. Наприклад, AlmaLinux опублікувала перелік власних виправлених пакетів і застерегла, що короткої версії з php -v недостатньо для перевірки. Тому запитуйте повний номер пакета та підтвердження щодо обох CVE. Водночас просто відповідь «у вас PHP 8.3» теж нічого не доводить.
Наш практичний висновок: не змінюйте всі налаштування сайту лише через відмінність номера в таблиці. Спершу уточніть походження пакета. І навпаки, загальна фраза хостингу про «захищені сервери» має бути доповнена конкретною відповіддю, чи застосовано ці два виправлення до середовища, яке обслуговує ваш сайт. Збережіть номер звернення й час підтвердження — це допоможе не повертатися до невизначеності наступного дня.
Що написати хостингу
Можна надіслати коротке звернення: «Перевірте, будь ласка, PHP для мого домену. Чи встановлено виправлення CVE-2026-109618 і CVE-2026-109619? Який повний номер пакета використовується? Чи застосовано його до всіх процесів, що обслуговують сайт, і чи потрібні додаткові дії з мого боку?» Якщо на акаунті кілька сайтів, перелічіть їх: одна відповідь щодо головного домену не обов’язково описує інші середовища.
У випадку власного VPS перевірку виконує адміністратор. NCSC радить інвентаризувати системи з PHP, зокрема компоненти всередині інших продуктів, і пріоритетно працювати з доступними з інтернету системами. Практично це означає врахувати також тестові піддомени, старі магазини та допоміжні панелі. Оновлення одного сервісу не є підтвердженням для решти.
Як підготувати сайт до оновлення
У рекомендаціях WordPress перед зміною PHP є резервна копія та перевірка сумісності теми й плагінів. Для цього термінового виправлення узгодьте з хостингом найкоротший безпечний шлях: патч підтримуваної гілки або потрібне оновлення середовища. Підготовка не повинна перетворитися на відкладення проблеми на тижні. Копія має охоплювати і файли, і БД; загальний підхід пояснює правило 3–2–1.
Після оновлення ми радимо перевірити не лише головну сторінку. Відкрийте адмінку, кілька матеріалів, пошук, форму зворотного зв’язку та завантаження зображень. Для магазину додайте кошик і тестовий сценарій оформлення замовлення. Зафіксуйте час і точний текст помилки, якщо вона з’явиться. Такі спостереження корисніші для підтримки, ніж повідомлення «після оновлення все зламалося».
Чи достатньо захисту CDN або плагіна
Фільтрація запитів може зменшити ризик окремих атак, але офіційні рекомендації не вважають тимчасові обмеження повною заміною патча. Якщо швидко встановити виправлення або прийнятні тимчасові заходи неможливо, NCSC рекомендує розглянути відключення системи до усунення ризику. Це рішення слід узгодити з адміністратором, який бачить конфігурацію, залежності й наслідки простою конкретного сервісу.
Вразливий сайт і зламаний сайт — різні висновки
Сама новина не доводить, що ваш сайт уже скомпрометовано. Якщо є незнайомі облікові записи, сторонні перенаправлення або інші незрозумілі зміни, інструкція WordPress щодо зламу радить документувати симптоми та час їх появи. Передайте ці дані хостингу або фахівцю з реагування. Встановлення патча усуває вразливість, але не є автоматичним підтвердженням очищення наслідків попереднього проникнення.
Долучайтеся до розмови
Пишіть по суті й поважайте інших читачів. Перший коментар може з’явитися після перевірки редакцією.