Вразливість PHP2Shell: що робити власнику сайту зараз

Наприкінці жовтня 2026 року в самому інтерпретаторі PHP знайшли дві критичні вразливості, і за повідомленнями дослідників їх уже використовують у реальних атаках. Вони зачіпають не якусь одну CMS, а будь-який сайт, що працює на PHP: WordPress, OpenCart, Joomla, Drupal чи самописний код. Нижче: що відомо, як за п'ять хвилин перевірити свою версію, що зробити сьогодні і що робити, якщо оновитись одразу не виходить.

Що відомо

Усе нижче взято з публікацій Patchstack і watchTowr. Це свіжі повідомлення, деталі можуть уточнюватися, тому дивіться також офіційне оголошення PHP.

• Вразливості мають номери CVE-2026-109618 і CVE-2026-109619, обидві оцінені в 9.2 за CVSS v4.0 (критичний рівень).
• Автентифікація зловмиснику не потрібна: достатньо надіслати сайту запит.
• Помилка в самому PHP, а не в плагіні чи темі. Перша пов'язана з нестачею пам'яті посеред обробки запиту, друга з тим, що стан запиту лишається в пам'яті після її звільнення і потрапляє в наступний запит того ж процесу.
• Зачеплені всі способи запуску PHP для вебу: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, FrankenPHP. За оцінкою Patchstack, найризикованіший mod_php.
• watchTowr фіксує спроби експлуатації в мережі пасток з 21 жовтня 2026 року; Patchstack пише, що хостинг-партнери повідомляли про активні інциденти. На момент публікації CISA ще не додала ці вразливості до каталогу відомих експлуатованих.
• За даними Wiz, які наводить Patchstack, через вразливості можна не лише виконати код, а й прочитати пам'ять процесу, де бувають паролі, токени й ключі API.

У цифрах

• За даними W3Techs на 27 жовтня 2026 року PHP використовують 69,2% сайтів, для яких відомо мову сервера. Серед них на PHP 8 працює 65,6%, на PHP 7 26,6%, на PHP 5 7,7%. Тобто приблизно кожен третій сайт на PHP (34,4%) стоїть на версії 7 або старшій, для яких офіційних виправлень немає. Розбивки W3Techs за мінорними версіями ми не наводимо: у «вісімці» є і 8.0 та 8.1, які теж без виправлень.
• Наш власний зовнішній вимір українських сайтів (114 сайтів, серпень-вересень 2026): 50 працюють на WordPress, WooCommerce або OpenCart, тобто на PHP. Версію PHP відкрито показують у заголовках відповіді лише 7 із цих 50. Із цих семи 6 на гілках без підтримки безпеки (5.5, 7.3 чотири сайти, 7.4), а сьомий на 8.3.33, що нижче виправленої 8.3.36.
• Це мала вибірка, і вона показує лише тих, хто не приховує версію. Решта 43 сайти можуть бути в будь-якому стані, ззовні цього не видно. Також заголовок із версією не доводить вразливості: хостинг міг перенести виправлення в старий пакет. Тому перевіряти версію треба зсередини.

Чи зачіпає це мій сайт

Якщо сайт працює на PHP, так, якщо версія не оновлена. Виправлені версії:

Номер версії може вводити в оману: хостинг-провайдери й дистрибутиви часто переносять виправлення в старі пакети, не змінюючи номера. За повідомленнями виробників, cPanel (ea-php 7.4–8.1), CloudLinux, TuxCare і Hostinger випустили виправлені збірки й для старих гілок. Тому для 8.1 і старших дивіться не лише на номер, а й на дату збірки та журнал змін пакета (виправлення від 21 жовтня 2026 року і пізніші), і перевіряйте у хостера письмово.

Сайти на Next.js, Node.js чи статичні самі по собі не зачеплені, але на тому ж сервері часто лежить старий WordPress чи пошта з панеллю на PHP. Тому перевіряти треба сервер, а не лише основний сайт.

Як перевірити версію за п'ять хвилин

1. У панелі хостингу (cPanel, ISPmanager, Plesk) знайдіть розділ «Версія PHP» або «PHP Selector».
2. Якщо є SSH: php -v. Це версія для командного рядка, веб може працювати на іншій.
3. У WordPress: «Інструменти → Здоров'я сайту → Інформація → Сервер».
4. Звіряйте не лише мажорну гілку, а й точний номер: наприклад, 8.3.35 ще вразлива, а 8.3.36 уже ні.
5. Пам'ятайте про піддомени, тестові копії й старі сайти на тому ж акаунті: кожен може працювати на своїй версії.

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

1. Оновіть PHP до виправленої версії вашої гілки. На спільному хостингу це зазвичай перемикач у панелі; якщо виправленої версії там ще немає, напишіть у підтримку хостера.
2. Перезапустіть усі процеси PHP після оновлення, інакше старий код ще працює в пам'яті.
3. Перевірте сумісність сайту на копії. Перехід, наприклад, із 7.4 на 8.4 ламає застарілі плагіни й модулі, тому робити його одразу на бойовому сайті ризиковано.
4. Якщо оновити неможливо одразу, зменште ризик тимчасовими мірами, які називають Patchstack і розробники PHP: вимкнути session.upload_progress.enabled, обмежити розмір і кількість полів запиту на рівні вебсервера, використати правила WAF (наприклад, Cloudflare). Це закриває лише відомі шляхи, повного захисту не дає: PHP прямо каже, що єдиний надійний шлях це оновлення.
5. Не лишайте сайт на PHP 8.1 і старших без плану. Для них нових виправлень від PHP уже не буде.

Якщо сайт могли зламати

Вразливість діє нижче рівня застосунку, тому журнали сайту можуть нічого не показати. Тривожні ознаки: нетипові запити з великим тілом (multipart), раптові помилки 500 і нестача пам'яті, несподівані перезапуски процесів PHP, дивні або надто великі значення cookie PHPSESSID.

Якщо є підозра:

• змініть паролі до адмінки, бази, FTP/SSH і ключі API, бо пам'ять процесу могли прочитати;
• перевірте, чи не з'явились нові файли й адміністратори, і порівняйте файли з чистою копією;
• відновіть з резервної копії, зробленої до 20 жовтня, і лише після оновлення PHP.

Чому «просто оновити» не завжди просто

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

Що можемо зробити ми

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

Власний досвід. Наш рушій інтернет-магазинів Stable ми вже переводимо на виправлену збірку: образи хмарної версії й демо зібрані на PHP 8.5.12. Сам рушій у релізі працює на Laravel 13 (він вимагає PHP 8.3 і новіший). Так само ведемо нові магазини на Laravel: беремо виправлений PHP, а не лишаємо збірку «як було». Якщо ваш магазин працює на старому PHP чи OpenCart, про перенесення на Stable Shop читайте тут.

Жоден підхід не дає стовідсоткової гарантії. Оновлення й гарденінг сильно знижують ризик, але не замінюють регулярних резервних копій і моніторингу.

Джерела: Patchstack, watchTowr, підтримувані версії PHP.