Розробники PHP закрили дві критичні вразливості PHP2Shell, через які організації тимчасово відключали сайти, а адміністратори терміново готували оновлення. Виправлення вийшли 21 жовтня 2026 року. Проте сервер стає захищеним від цих помилок лише після встановлення патчів і перезапуску відповідних процесів.
Для відвідувачів це не привід припиняти користуватися інтернетом. Для власників сайтів робота ще триває: потрібно перевірити оновлення серверного середовища й з’ясувати, чи не скористався хтось уразливостями раніше.
Що виправили та які сервери під загрозою
PHP2Shell — спільна назва вразливостей CVE-2026-109618 і CVE-2026-109619. Обидві отримали оцінку 9,2 за CVSS 4.0 та за певних умов дозволяють віддалено виконувати код на сервері без автентифікації.
Проблеми пов’язані з обробкою пам’яті та внутрішнього стану PHP. Найвищим розробники вважають ризик для Apache з mod_php, але PHP-FPM та інші способи запуску PHP також потребують уваги. Назва CMS чи відсутність mod_php самі по собі не підтверджують безпеку конкретного сайту.
Після першого попередження про критичні вразливості PHP команда опублікувала виправлені версії:
- PHP 8.2.35 — для гілки 8.2.
- PHP 8.3.36 — для гілки 8.3.
- PHP 8.4.27 — для гілки 8.4.
- PHP 8.5.12 — для гілки 8.5.
Перелік випусків і рекомендації щодо встановлення наведені в офіційному повідомленні PHP. Оновлення WordPress, Drupal, тем або плагінів не замінює оновлення самого інтерпретатора.
PHP 8.1 і старіші гілки вже не отримують звичайних випусків безпеки від проєкту. Водночас команда надала мінімальні патчі для PHP 7.4, 8.0 та 8.1, призначені для самостійного збирання. Дистрибутиви Linux і постачальники розширеної підтримки також можуть переносити виправлення у свої пакети. Тому статус захисту слід уточнювати у постачальника, враховуючи повну версію пакета.
Чому вихід патчів не припинив небезпеку
Зловмисники не чекали, поки адміністратори завершать оновлення. Amazon Threat Intelligence виявила в телеметрії своїх серверів-приманок MadPot спробу експлуатації від 17 жовтня — ще до публічного розкриття технічних подробиць.
У повідомленні Amazon про ранні спроби атак зазначено, що після виходу виправлень нові демонстраційні експлойти з’явилися протягом кількох годин. Компанія рекомендує починати перевірку можливої компрометації щонайменше з 17 жовтня, а не лише з дати релізу.
Генеральний директор Cloudflare Метью Принс також повідомив про мільйони спроб експлуатації в мережі компанії. Це кількість спроб, а не підтверджених зламів. Вона не показує, скільки серверів атакувальники справді змогли скомпрометувати.
Тимчасове відключення сайту теж не доводить, що його зламали. Британський NCSC радить розглянути відключення системи, якщо оперативно встановити виправлення або застосувати тимчасові заходи неможливо. Це спосіб зменшити ризик на час робіт.
Правила вебфаєрвола й зміни конфігурації можуть перекривати окремі шляхи атаки. Однак команда PHP попереджає: універсального налаштування, яке повністю замінює виправлення обох помилок, немає.
Чому одну з проблем так довго виправляли
PHP Foundation повідомила, що перші ознаки проблеми з обробкою нестачі пам’яті, яка лежить в основі CVE-2026-109618, знайшли ще у 2024 році. Тоді потенційну експлуатацію припускали, але конкретного шляху до віддаленого виконання коду ще не встановили.
Запропоновані виправлення мали складні компроміси: могли порушувати сумісність, створювати нові можливості для відмови в обслуговуванні або вимагати змін у сторонніх розширеннях.
У поясненні PHP Foundation затримку прямо пов’язують також із нестачею ресурсів і процедурою ухвалення рішень. Команда почала змінювати процес, щоб рішення можна було приймати більшістю голосів, не очікуючи повного консенсусу.
Що перевірити власнику сайту
Я б почав із підтвердження від адміністратора або хостинг-провайдера: чи виправлене саме те PHP-середовище, яке обслуговує сайт. Самого повідомлення про доступність нової версії недостатньо.
- Уточніть статус пакета PHP. Він має містити виправлення обох CVE — у відповідному випуску проєкту або пакеті постачальника.
- Переконайтеся, що оновлення застосоване. Перезапустіть потрібні процеси PHP чи відповідну службу за інструкцією для свого середовища та перевірте роботу сайту.
- Перегляньте журнали. Враховуйте відомі спроби атак із 17 жовтня, а за наявності власних підозрілих подій — і раніший період.
- Перевірте зміни на сервері. Уваги потребують невідомі PHP-файли, сторонні процеси, нові облікові записи та незнайомі завдання за розкладом.
- За підозри на злам розпочніть розслідування. Потрібно оцінити доступ до бази даних, ключів API та інших секретів і визначити, які з них слід замінити.
Встановлення патча закриває вразливість, але не прибирає вже залишений зловмисником доступ. Тому перевірка наслідків важлива навіть після успішного оновлення.
Чи потрібно відвідувачам змінювати всі паролі
Саме повідомлення про PHP2Shell не є доказом витоку даних із конкретного сервісу. Основні дії зараз лежать на власниках серверів. Користувачам варто стежити за офіційними повідомленнями сайтів, користуватися унікальними паролями та двофакторною автентифікацією.
Якщо компрометацію підтвердять, потрібно виконати рекомендації відповідного сервісу. Успішний злам вебсервера потенційно дозволяє підміняти сторінки та збирати дані, тому незвичні форми входу, запити секретних фраз чи підозрілі підтвердження операцій потребують обережності.
Отже, виправлення вже є, але безпека конкретного сайту залежить від того, чи встановив їх його адміністратор і чи перевірив можливі наслідки попередніх атак. Говорити, що після релізу проблема автоматично зникла в усьому інтернеті, зарано.