Дві критичні вразливості в PHP: які сайти під загрозою і як оновитися

PHP 21 жовтня випустили екстрене оновлення безпеки, яке закриває дві критичні вразливості, CVE-2026-109618 і CVE-2026-109619. Через них зловмисник без логіну може віддалено запустити свій код на сервері, і такі атаки вже почалися. Обидві PHP оцінили на 9,2 з 10 за шкалою CVSS 4.0. Виправлення вийшли у версіях 8.5.12, 8.4.27, 8.3.36 і 8.2.35. За словами PHP, під загрозою всі установки PHP, які обслуговують сайти. Найбільший ризик там, де PHP підключений до вебсервера Apache як модуль.

Нових офіційних версій для PHP 8.1 і старіших не буде. Для 7.4, 8.0 і 8.1 команда безпеки PHP виклала мінімальні виправлення у вихідному коді, і ставити їх доведеться самостійно, збираючи PHP з коду. Деякі дистрибутиви Linux і компанії, які підтримують старі версії PHP, випускають свої виправлення.

Якщо у вас є проєкти на PHP, зверніть особливу увагу! Насамперед це:

• самописні проєкти на PHP і кастомні фреймворки
• панелі керування хостингом (cPanel, Plesk, DirectAdmin тощо) та самописні білінги й панелі хостерів
• сайти на WordPress

Що робити, якщо у вас сайт на WordPress

WordPress працює на PHP, тому вразливість у PHP зачіпає і сайти на WordPress. Mark Williams-Cook, директор SEO-агенції, у своєму дописі в LinkedIn попрощався з кількома мільйонами сайтів на WordPress, бо патч отримає тільки PHP 8. За статистикою версій PHP на WordPress.org, 36% сайтів на WordPress працюють на PHP 8.1 або старішому, з них 22% на PHP 7.4 і старіших версіях.

Оновлення WordPress, плагінів чи тем тут не допоможе. Захищає тільки виправлена версія PHP на сервері, де працює сайт.

1. Подивіться, на якій версії PHP працює сайт. В адмінці WordPress відкрийте Інструменти → Здоров'я сайту → вкладка Інформація → блок Сервер, рядок Версія PHP. Те саме видно в панелі хостингу.
2. Якщо там 8.2, 8.3, 8.4 або 8.5, номер має бути не меншим за 8.2.35, 8.3.36, 8.4.27 або 8.5.12. Якщо він менший, напишіть у підтримку хостингу й спитайте, чи вже стоїть виправлення. Деякі хостери ставлять його без зміни номера версії.
3. Якщо там 8.1, 8.0, 7.x або нижче, офіційного оновлення від PHP для вашої версії не буде. Сайт треба перевести на PHP 8.2 або новішу. Поки цього не зробили, спитайте хостера, чи поставив він виправлення для старої версії. На більшості хостингів версію PHP перемикають у панелі. Якщо не знаєте як, попросіть про це підтримку хостингу або розробника, бо після перемикання старі тема чи плагіни можуть перестати працювати.
4. Якщо сайт обслуговує розробник або агенція, перешліть їм цю новину.

Окремо нагадуємо, що 22 вересня WordPress випустили версію 7.1.2 з виправленням критичної вразливості в самому WordPress. Якщо в адмінці досі пропонують оновити WordPress, оновіть і його.

Якщо сайт працює через Cloudflare

Андрій Ткаченко, веброзробник і керівник інженерної команди в MacPaw, підказав, що власникам сайтів за Cloudflare рвати на собі волосся не треба. Cloudflare 21 жовтня з 6:02 за Києвом увімкнули правила файрвола проти php2shell для всіх клієнтів.

• На безкоштовному тарифі захист працює автоматично, робити нічого не треба.
• На платних тарифах Pro, Business і Enterprise правила теж додані, але Cloudflare радять перевірити в налаштуваннях WAF, що вони блокують запити.

Оновити PHP все одно краще. Cloudflare теж радять це зробити, бо файрвол лише додатковий захист.

Як вимкнути сайт на час оновлення без шкоди для пошуку

John Mueller, який у Google керує командою зв'язків з вебмайстрами, порадив у LinkedIn, яку відповідь віддавати, поки сайт на PHP вимкнений для оновлення. Якщо ви вимикаєте сайти, щоб встигнути з позаплановим оновленням, сервер має віддавати код HTTP 503, тобто сервіс тимчасово недоступний. Сторінки, які не відповідають або віддають 404 чи 500, він радить не залишати. Код 503 можна віддати без PHP, наприклад перевести домен через DNS на інший сервер або налаштувати це в CDN.

За довідкою Google про коди відповіді сервера, сторінку з кодом 404 Google прибирає з індексу. На помилки сервера з кодами 5xx Google сповільнює сканування сайту. Сторінки, які віддають таку помилку довго, Google теж зрештою прибирає з індексу.

Mueller також пише, що сайт на власному сервері майже з будь-якою більш-менш сучасною CMS, найімовірніше, працює на PHP, і оновити його треба якнайшвидше.

Що відомо про вразливості php2shell

CVE-2026-109618 стосується того, як PHP поводиться, коли бракує пам'яті. PHP може обірватися посеред підготовки даних запиту, і потім ці недопрацьовані дані обробляються як правильні. CVE-2026-109619 стосується даних запиту, які лишаються в роботі вже після того, як пам'ять під них звільнили. Для PHP як модуля Apache, за словами PHP, показали атаку, яка спрацьовує від запиту без логіну ще до того, як запускається код сайту.

Дослідники називають ці дві вразливості php2shell.

Через ці вразливості вже атакують. Дослідники з watchTowr повідомили про атаки, які 21 жовтня побачили на своїх серверах-пастках. До релізу атак ніхто не помічав. До каталогу вразливостей, через які вже атакують, від американського агентства кібербезпеки CISA ці дві станом на вечір 21 жовтня не внесені. Коли в червні 2024 року розкрили попередню серйозну вразливість PHP, CVE-2024-4577, компанія Akamai побачили спроби атак на свої сервери-пастки вже за 24 години.

Як про вразливості стало відомо раніше

PHP планували розкрити деталі 22 жовтня. 20 жовтня анонімний користувач форуму Hacker News написав, що в PHP є дві вразливості з оцінкою 10 з 10, які зачіпають усі версії від PHP 5. Доказів він не мав. Того ж дня дослідники з компанії watchTowr підтвердили, що вразливості справжні і що на них діє ембарго, тобто домовленість не розкривати деталі до виходу патча. Увечері PHP опублікували оголошення і перенесли реліз на день раніше.

У своєму оголошенні PHP не перелічили, які саме версії вразливі. Оцінка 10 з 10 теж з анонімного допису.

Як Chainguard випустили виправлення раніше за PHP

21 жовтня о 10:41 за Києвом, більш ніж за шість годин до домовленого релізу, компанія Chainguard опублікувала свої збірки PHP з виправленням. Так пишуть PHP Foundation у своїй заяві про реліз і порушене ембарго. Chainguard, як і інші дистрибутиви, отримали виправлення заздалегідь, щоб їхні клієнти встигли оновитися. За словами PHP Foundation, після публікації збірок будь-який зловмисник міг вивчити виправлення в готових файлах, поки решта користувачів PHP ще чекала релізу.

Dan Lorenc з Chainguard пояснив це рішення в LinkedIn. За його словами, команда Chainguard самостійно знайшла ту саму вразливість своїм інструментом і AI-моделлю, яку попросили просто знайти серйозні вразливості в PHP. Збірки вони випустили, бо інші компанії з безпеки, які брали участь у розкритті, підтвердили, що через ці вразливості вже атакують. Ще одна причина, за його словами, у тому, що інформації про майбутні виправлення в мережі було вже багато. Він вибачився перед командою PHP за додатковий стрес і назвав такі ситуації новою нормою. Chainguard, за його словами, останні три місяці щодня працюють із сотнями подібних розкриттів.

PHP Foundation пишуть, що серед кодів атаки, які з'явилися після витоку, робочих до моменту релізу не знайшли. Появу таких кодів прискорило відео з демонстрацією атаки, яке помилково опублікувала дослідницька компанія Calif. Ще PHP Foundation пишуть, що через пошук вразливостей за допомогою AI команда безпеки PHP отримує значно більше звітів, ніж раніше.

Скільки серверів працюють на старих версіях PHP

За підрахунком компанії Mallory, який наводить The Hacker News, 20 жовтня близько 884 тис. серверів в інтернеті показували у відповіді PHP 8.1 або старішу версію. Це 59% з приблизно 1,5 млн серверів, які показують номер версії PHP. Ще 740 тис. серверів показують, що працюють на PHP, але без номера версії. Mallory рахували через Shodan, пошуковик пристроїв в інтернеті, і з цього підрахунку не видно, скільки серверів справді вразливі.

Що робити адміністраторам серверів

Ці кроки The Hacker News зібрали з рекомендацій компанії Huntress і CERT-EU, команди реагування на кіберзагрози установ ЄС.

• Знайти всі місця, де працює PHP, включно з PHP у панелях керування хостингом на кшталт cPanel і Plesk і в готових програмах для серверів.
• Оновити PHP до 8.5.12, 8.4.27, 8.3.36 або 8.2.35, спершу на серверах, доступних з інтернету. У пакетах дистрибутивів Linux виправлення можуть вийти з іншим номером версії.
• Сервери на PHP 8.1 і старіших перевести на 8.2 або новішу. Якщо це неможливо, поставити виправлення від дистрибутива або зібрати PHP з мінімальними виправленнями від PHP для 7.4, 8.0 чи 8.1. Поки нічого з цього не зроблено, сховати сервер від публічного доступу, наприклад за VPN або файрволом для вебзастосунків.
• Стежити, чи процеси PHP-FPM, PHP-CGI або вебсервера Apache не запускають командний рядок, інтерпретатори чи програми для завантаження файлів.
• Якщо знайшли підозріле, відключити сервер від мережі, зберегти логи вебсервера й PHP і шукати веб-шели (файли, через які зловмисник керує сайтом), нові файли в корені сайту, нові завдання за розкладом і нові акаунти.

Тимчасові налаштування, якщо оновитися одразу не можна

PHP дали налаштування, які зменшують ризик, поки сервер не оновлено. Безпечним сервер вони не роблять, повністю проблему вирішує тільки оновлення, пишуть PHP.

Проти CVE-2026-109618:

memory_limit = -1
post_max_size = 8M

Рядок memory_limit = -1 знімає обмеження пам'яті для PHP. Його PHP радять задати через php_admin_value у налаштуваннях пулу PHP-FPM або в конфігу Apache. Значення post_max_size = 8M PHP радять для сайтів без завантаження файлів. Для сайтів, куди завантажують файли, радять 32M. Значення upload_max_filesize має бути меншим за post_max_size. Обмеження пам'яті процесу RLIMIT_AS і RLIMIT_DATA PHP радять не використовувати, бо саме вони можуть викликати вразливий збій.

Проти CVE-2026-109619:

session.upload_progress.enabled = 0

Цей рядок треба прописати в php.ini, у налаштуваннях пулу PHP-FPM або в конфігу сервера і перезапустити всі процеси PHP. Через ini_set() чи файл .user.ini він не спрацює. На PHP 8.5 PHP радять ще fatal_error_backtraces = 0 з перезапуском процесів.

Про цей рядок нам ще до релізу PHP написав підписник Litl, DevOps-інженер, з посиланням на розбір незалежного дослідника. PHP потім підтвердили цей рядок у своєму оголошенні як захід проти CVE-2026-109619.

Приховати помилки через error_reporting, display_errors чи символ @ не допоможе.

19 жовтня ми писали про заражене оновлення SEO-плагіна Rank Math PRO і кроки очищення сайту після зламу.