PHP2Shell: критичні вразливості PHP, масові відключення сайтів у світі та заходи захисту HyperHost

21 жовтня 2026 року світова вебінфраструктура зіткнулася з однією з найсерйозніших загроз безпеці PHP за останні роки. Дві критичні вразливості, відомі під спільною назвою PHP2Shell, змусили державні установи, великі компанії та хостинг-провайдерів у різних країнах терміново переглядати безпеку своїх серверів. Деякі організації навіть тимчасово припинили роботу власних сайтів, щоб запобігти можливим атакам.

У Великій Британії стали недоступними десятки державних онлайн-сервісів, у Німеччині дослідники зафіксували масові відключення сайтів, а в Нідерландах обмеження зачепили навіть державні портали та інфраструктурні організації.

У HyperHost ми свідомо не поспішали публікувати новину про ці вразливості.

Нашим першочерговим завданням було не повідомити про загрозу раніше за інших, а організувати встановлення виправлень та забезпечити захист клієнтських сайтів.

Особливу увагу ми приділили не лише актуальним версіям PHP, а й застарілим, які офіційно вже не підтримуються розробниками. Завдяки використанню CloudLinux на наших серверах віртуального хостингу ми маємо можливість встановлювати спеціальні патчі безпеки навіть для PHP 5.x, 7.x та 8.1.

Розповідаємо, що саме сталося, чому загроза набула світового масштабу та які заходи ми вживаємо для захисту клієнтів.

Що сталося з PHP 21 жовтня 2026 року?

20 жовтня команда розробників PHP попередила про підготовку позапланового критичного оновлення безпеки. Наступного дня, 21 жовтня, були опубліковані виправлення для двох вразливостей:

• CVE-2026-109618 — порушення безпеки роботи з пам'яттю під час обробки помилок нестачі пам'яті (Out-of-Memory).
• CVE-2026-109619 — некоректне використання звільненої пам'яті через збереження застарілих посилань у внутрішньому стані PHP.

Обидві вразливості отримали оцінку 9,2 бала за шкалою CVSS 4.0, що відповідає критичному рівню небезпеки.

Головна проблема полягає в тому, що за певних умов зловмисник може використати спеціально сформований HTTP-запит для віддаленого виконання коду на сервері — Remote Code Execution (RCE).

Причому атака потенційно можлива без попередньої авторизації.

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

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

За певних умов їх експлуатація може призвести до виконання стороннього коду, отримання доступу до конфіденційних даних або порушення роботи сервера.

Небезпека особливо висока для публічно доступних вебсервісів, де PHP постійно обробляє запити користувачів.

Малюнок 1. Хронологія PHP2Shell: від витоку деталей до виправлень CloudLinux

Офіційні джерела: PHP Security Releases, NHS England — Critical Vulnerabilities in PHP, Red Hat Security Bulletin.

Масштаби PHP2Shell: чому у світі почали відключати сайти

Особливістю цього інциденту стала реакція організацій, які використовують PHP.

Зазвичай після виявлення вразливості адміністратори встановлюють оновлення безпеки, а користувачі можуть навіть не помітити проведених робіт.

Однак у випадку PHP2Shell ризики виявилися настільки серйозними, що багато організацій обрали більш радикальний варіант — тимчасово відключити потенційно вразливі вебресурси до встановлення патчів.

21 жовтня Європейська комісія, ENISA, CERT-EU, Europol EC3 та мережа національних команд реагування на комп'ютерні інциденти опублікували спільне попередження із закликом негайно захистити PHP-інфраструктуру.

Офіційна заява ENISA щодо критичних вразливостей PHP.

Велика Британія: десятки недоступних державних сервісів

У Великій Британії заходи реагування на PHP2Shell призвели до тимчасової недоступності 32 державних онлайн-сервісів. Ще чотири сервіси працювали з частковими обмеженнями.

На окремих вебресурсах користувачі отримували HTTP-помилку 503 Service Unavailable, що означає тимчасову недоступність сервісу.

Британський Національний центр кібербезпеки (NCSC) також надіслав близько 50 тисяч попереджень організаціям, які могли використовувати вразливе програмне забезпечення.

Водночас британські органи кібербезпеки повідомили, що на момент їхніх заяв не мали підтверджених свідчень успішної компрометації державних систем саме через PHP2Shell.

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

Джерело: The Guardian — Websites across world hit by millions of attempts to exploit PHP code flaw.

Німеччина: понад 1300 PHP-сайтів стали недоступними протягом кількох годин

Особливо показові результати дослідження компанії SecuSeek, яка проаналізувала стан вебінфраструктури одразу після публікації виправлень.

За даними дослідників, протягом приблизно 3–4 годин після виходу патчів 1339 PHP-сайтів організацій із досліджуваної вибірки критичних секторів стали недоступними, хоча раніше працювали.

Це становило 11% відповідних PHP-сайтів проти 2% сайтів без PHP.

Приблизно половина недоступних ресурсів розміщувалася на інфраструктурі німецького хостинг-провайдера Mittwald.

Примітно, що вже через вісім годин 74% цих сайтів знову стали доступними.

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

Джерело: SecuSeek — Measuring PHP2Shell Exposure in the First 24 Hours.

Нідерланди: недоступність урядових порталів і великих організацій

У Нідерландах тимчасові обмеження зачепили державні вебресурси, портовий сектор та інші організації.

Зокрема, повідомлялося про недоступність урядового порталу Overheid.nl, сайту порту Роттердам, ресурсів національної футбольної асоціації та окремих медичних установ.

За повідомленням Reuters, подібні запобіжні заходи застосовували також у Франції, Бельгії, Фінляндії, Чехії та інших країнах.

Обмеження торкнулися не лише державних ресурсів, а й великих міжнародних онлайн-платформ, зокрема окремих сервісів Wikimedia Foundation та Internet Archive.

Джерело: Reuters — Governments, companies take websites offline over PHP flaws.

Наскільки масштабною виявилася загроза?

Щоб оцінити потенційний вплив PHP2Shell, дослідники SecuSeek проаналізували понад 18 мільйонів вебсайтів у всьому світі та ресурси приблизно 22 тисяч організацій із критично важливих секторів.

Результати показали:

• 59% сайтів у досліджуваній вибірці використовували PHP.
• Приблизно 30% PHP-сайтів розкривали інформацію про встановлену версію PHP через HTTP-заголовки.
• Серед сайтів, для яких вдалося встановити версію PHP, 46% використовували PHP 8.1 або старіші версії, що вже не підтримуються основною командою розробників.

Ці цифри не можна безпосередньо переносити на весь інтернет, проте вони демонструють масштаби використання застарілих програмних середовищ.

Крім того, за повідомленнями Cloudflare та міжнародних ЗМІ, після розкриття технічних деталей вразливостей почали фіксувати масові спроби їх експлуатації.

PHP2Shell став не просто черговою вразливістю, а глобальним випробуванням готовності вебінфраструктури до критичних загроз.

Чому ми в HyperHost не поспішали публікувати новину

Ми уважно стежили за розвитком ситуації та появою виправлень для різних гілок PHP.

Проте від самого початку визначили для себе пріоритет: спочатку практичні заходи захисту, потім публічні повідомлення.

Ми переконані, що відповідальність хостинг-провайдера перед клієнтами полягає насамперед у забезпеченні надійної роботи інфраструктури.

Публікація повідомлення про критичну вразливість сама по собі не робить сайти безпечнішими. Для цього потрібна конкретна технічна робота: аналіз загрози, отримання перевірених патчів, оновлення серверного середовища та контроль результату.

Саме цим займалися наші системні адміністратори.

Для нас також було принципово важливо знайти рішення для клієнтів, які досі використовують застарілі версії PHP.

Адже далеко не кожен сайт можна негайно перевести на сучасну версію мови програмування.

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

Тому просте повідомлення «оновіть PHP до актуальної версії» не завжди є достатнім рішенням.

Ми прагнули забезпечити захист і таких проєктів.

Як ми захищаємо клієнтів HyperHost: патчі навіть для старих PHP

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

Однією з її важливих можливостей є підтримка альтернативних версій PHP — Alt-PHP.

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

У випадку PHP2Shell переваги такого підходу виявилися особливо важливими.

CloudLinux випустив патчі навіть для PHP, які офіційно більше не підтримуються

22 жовтня 2026 року CloudLinux підтвердив доступність виправлених збірок для підтримуваних ним гілок Alt-PHP та EA-PHP, включно із застарілими версіями.

Ідеться не лише про PHP 8.3, 8.4 або 8.5, а й про старіші гілки, зокрема PHP 5.x, PHP 7.x та PHP 8.1.

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

CloudLinux реалізував відповідні виправлення через механізм backporting — перенесення змін безпеки до попередніх версій програмного забезпечення.

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

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

Офіційне підтвердження CloudLinux: PHP2Shell — fixed Alt-PHP and EA-PHP packages and how to verify.

Чому це важливо для власників старих сайтів?

Розглянемо практичний приклад.

Сайт використовує PHP 7.4 та стару версію CMS. Перехід на PHP 8.3 може потребувати оновлення модулів, змін у програмному коді або повноцінного тестування сумісності.

Без спеціальних оновлень власник такого сайту опиняється перед складним вибором: термінова модернізація з ризиком порушення роботи або продовження використання вразливого середовища.

Механізм backport дозволяє зменшити цей ризик.

Після встановлення виправленої збірки CloudLinux сайт може продовжувати працювати на звичній версії PHP, але вже із захистом від конкретних вразливостей PHP2Shell.

Водночас необхідно підкреслити: наявність патчів для двох CVE не робить застарілу версію PHP повністю безпечною.

Такі версії можуть містити інші недоліки та обмеження сумісності. Тому ми й надалі рекомендуємо планувати поступовий перехід на актуальні підтримувані версії PHP.

Однак у критичній ситуації можливість отримати виправлення без негайної перебудови сайту має величезне практичне значення.

Чому після оновлення номер версії PHP може залишитися незмінним?

Це важливий технічний нюанс, який може викликати запитання у власників сайтів.

Офіційні виправлення PHP2Shell були включені до таких релізів:

Малюнок 2. Які гілки PHP виправлено офіційно, а які бекпортом
Але для застарілих гілок, наприклад PHP 7.2 та PHP 7.4, ситуація інша.

Останні офіційні релізи цих гілок — PHP 7.2.34 та PHP 7.4.33. Команда PHP більше не випускає для них нових стандартних версій.

Тому після встановлення спеціальних патчів CloudLinux номер версії може залишатися незмінним.

Наприклад, у налаштуваннях сайту й надалі відображатиметься PHP 7.4.33, хоча використовувана збірка вже міститиме виправлення CVE-2026-109618 та CVE-2026-109619.

Це нормальна особливість механізму backport, а не ознака відсутності оновлення.

Для перевірки можна використати функцію phpinfo(), яка відображає інформацію про середовище виконання PHP, зокрема дату збірки — Build Date.

Однак самої дати не завжди достатньо для підтвердження конкретного патча. Найточніший спосіб перевірки — звірити встановлений пакет із виправленою збіркою постачальника за її повним ідентифікатором і журналом змін.

На серверах HyperHost такі перевірки виконуються адміністраторами під час оновлення.

Якщо ви користуєтеся нашим хостингом і маєте запитання щодо встановленої версії PHP, рекомендуємо звернутися до технічної підтримки.

Cloudflare: додатковий захист ще до встановлення патчів

Окрему увагу під час інциденту PHP2Shell привернула робота Cloudflare.

21 жовтня компанія повідомила, що розробила та впровадила спеціальні механізми захисту через Web Application Firewall (WAF).

За інформацією Cloudflare, захисні правила були підготовлені в межах координованого реагування на вразливості, а відповідні засоби захисту стали доступними клієнтам приблизно за дев'ять годин до публічного розкриття деталей.

Зокрема, з 03:02 UTC 21 жовтня спеціальні WAF-механізми були активовані за замовчуванням для клієнтів Cloudflare, які використовують відповідний WAF, включно з безкоштовними тарифами.

Компанія також повідомила про виявлення реальних спроб атак і модифікацію зловмисниками шкідливих запитів для обходу захисних правил.

У відповідь Cloudflare застосував механізми аналізу HTTP-транзакцій, які дозволяють враховувати не лише характеристики запиту, але й відповідь сервера.

Це підвищує можливості виявлення складних атак, які важко ідентифікувати за одним окремим HTTP-запитом.

Детальний технічний опис опубліковано в офіційному блозі: Cloudflare deploys protections against PHP2Shell vulnerability.

Чому одного WAF недостатньо?

WAF є важливим, але додатковим рівнем захисту.

Його завдання — аналізувати вхідний трафік, виявляти підозрілі запити та блокувати характерні шаблони атак.

Однак WAF не усуває помилку безпосередньо в PHP. Тому навіть за наявності ефективного захисту на рівні Cloudflare необхідно встановлювати серверні оновлення безпеки.

Оптимальна модель захисту поєднує актуальне серверне програмне забезпечення, своєчасне встановлення патчів, контроль конфігурації та додаткові засоби фільтрації вебтрафіку.

Підключення Cloudflare через HyperHost

Ми рекомендуємо власникам сайтів використовувати багаторівневий підхід до безпеки.

Саме тому в HyperHost доступна послуга підключення та налаштування Cloudflare.

Використання Cloudflare допомагає додати захист вебзастосунку через WAF, протидію окремим видам мережевих атак та можливості CDN для оптимізації доставки контенту.

Що рекомендуємо власникам сайтів після PHP2Shell?

Незалежно від того, чи розміщуєте ви сайт на віртуальному хостингу, VPS або виділеному сервері, рекомендуємо перевірити його програмне середовище.
Малюнок 3. Рівні захисту сайту: від патча PHP до резервних копій

1. Перевірте встановлену версію PHP. Якщо сайт використовує застарілу гілку, уточніть у хостинг-провайдера, чи доступні для неї спеціальні виправлення безпеки.
2. Переконайтеся, що патчі встановлені. Наявність актуального номера версії або backport-виправлення необхідно перевіряти за даними відповідного постачальника програмного забезпечення.
3. Плануйте перехід на підтримувані версії PHP. Навіть якщо старий PHP отримав виправлення PHP2Shell, це не замінює планової модернізації проєкту. Ми рекомендуємо орієнтуватися на PHP 8.3 або новіші підтримувані гілки з урахуванням сумісності сайту.
4. Оновлюйте CMS, плагіни та бібліотеки. WordPress, Joomla, Drupal та інші системи також мають власні оновлення безпеки. Водночас оновлення самої CMS не виправляє вразливість у PHP runtime.
5. Використовуйте додатковий вебзахист. Налаштований WAF, зокрема Cloudflare, може суттєво зменшити ризики експлуатації відомих атак, але не замінює серверних виправлень.
6. Подбайте про резервні копії. Регулярне резервне копіювання та перевірена процедура відновлення залишаються необхідними незалежно від наявності інших засобів захисту.

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

Висновки: що насправді означає надійний хостинг

Інцидент PHP2Shell продемонстрував, що навіть давно відомі та широко використовувані технології можуть містити критичні вразливості.

Коли загроза зачіпає програмне забезпечення, від якого залежить робота величезної кількості вебсайтів, вирішального значення набуває не лише факт наявності патча.

Не менш важливі готовність інфраструктури до його встановлення, професійність системних адміністраторів, доступність спеціалізованих засобів захисту та здатність оперативно реагувати без необґрунтованих ризиків для клієнтів.

Саме тому ми в HyperHost зосередилися передусім на технічній роботі.

Завдяки використанню CloudLinux наші клієнти можуть отримувати виправлення критичних вразливостей PHP2Shell навіть для застарілих версій PHP, які вже не підтримуються основною командою розробників.

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

Ми продовжуємо впровадження та перевірку необхідних оновлень на нашій інфраструктурі й рекомендуємо всім власникам вебресурсів приділити належну увагу стану безпеки своїх сайтів.

Перевірити й за потреби оновити PHP на вашому сайті допоможе технічна підтримка HyperHost. Ще один рівень захисту дає Cloudflare з налаштуванням від HyperHost. Для самостійного адміністрування є VPS і виділені сервери.

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

Саме так ми розуміємо свою роботу в HyperHost.