Критична вразливість PHP CVSS 10.0: що робити до виходу патчу

Команда розробників PHP анонсувала два критичні оновлення безпеки — CVE-2026-109618 та CVE-2026-109619, обидва з максимальним балом CVSS 10.0. Це означає віддалене виконання коду без автентифікації: зловмиснику не потрібні ні пароль, ні обліковий запис, ні дія з боку адміна. Достатньо дотягнутися до вразливого сервера по мережі.

PHP працює під приблизно сімдесятьма відсотками сайтів, які взагалі розкривають свій бекенд. Це WordPress, Drupal, Laravel, самописні двигуни новинних видань — зокрема і значна частина українського медійного сегмента. Якщо ваш сайт на PHP, цей текст про вас, і прочитати його варто до того, як патч вийде, а не після того, як хтось його проаналізує й напише експлойт.

Чому «до патчу» — це окреме вікно ризику

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

Тобто небезпечні не стільки дні перед релізом, скільки проміжок між релізом і вашим оновленням. Якщо ви дізнаєтесь про патч із новин за тиждень, ви вже в зоні масового сканування. Підготуватися треба зараз, щоб у день релізу дія була однією командою, а не дослідженням.

Що зробити вже сьогодні

• Дізнайтеся свою версію PHP. На сервері — php -v у консолі. Якщо консолі немає, створіть тимчасовий файл із <?php phpinfo();, відкрийте його в браузері й одразу видаліть. Запишіть версію — вона знадобиться, щоб звіритися зі списком уразливих, коли той опублікують.
• Перевірте, хто взагалі оновлює PHP. На керованому хостингу це робить провайдер — напишіть у підтримку й спитайте, коли планують накотити патч. На власному VPS це ваша відповідальність, і тут потрібен план.
• Увімкніть WAF або mod_security. Якщо користуєтесь Cloudflare чи іншим хмарним захистом, переконайтеся, що керований набір правил активний — вендори зазвичай випускають віртуальні патчі ще до того, як ви оновите сам PHP. На Apache з mod_security тримайте базові правила OWASP CRS увімкненими.
• Зробіть бекап бази і файлів. Не тому, що оновлення щось зламає, а тому, що якщо вас уже встигли скомпрометувати, чистий бекап — єдиний спосіб повернутися без слідів зловмисника в коді.

WAF — це тимчасова ширма, а не рішення. Він фільтрує відомі шаблони атак, але проти свіжого експлойту під конкретну вразливість може й не спрацювати. Єдина надійна відповідь — оновлена версія PHP.

День релізу

Коли патч вийде, звіртеся зі списком уразливих версій. Якщо ваша там — оновлюйтеся в той самий день, не чекаючи «зручного вікна». Для більшості це apt update && apt upgrade або оновлення через панель хостингу. Після цього перевірте php -v ще раз і переконайтеся, що сайт відкривається без помилок.

Редакціям варто мати цей сценарій записаним заздалегідь: хто саме натискає кнопку, о котрій, і хто перевіряє, що видання після оновлення живе. Критична вразливість у PHP — це не подія для технічного відділу десь збоку. Для медіа, що віддає трафік через власний сайт, це питання, чи буде цей сайт завтра вашим.