PHP2Shell — спільна назва двох критичних вразливостей у ядрі PHP: CVE-2026-109618 і CVE-2026-109619. Обидві отримали оцінку 9,2 — Critical за системою CVSS v4.0 і можуть дати змогу зловмиснику без автентифікації виконувати код на вразливому сервері. 21 жовтня 2026 року команда PHP випустила термінові виправлення.
47
Для адміністраторів головний крок — оновити PHP. Повідомлення про спроби експлуатації, зокрема про спостереження в пастці Amazon до публічного розкриття, — привід не зволікати. Але спроба атакувати приманку не доводить, що зловмисник проник у справжню систему.
48
36
У чому полягають уразливості PHP2Shell
Дві помилки мають різні описані механізми:
- CVE-2026-109618 пов’язана з нестачею пам’яті. Коли PHP обробляє ситуацію, у якій пам’ять вичерпано, виконання може перерватися, поки внутрішні дані запиту ініціалізовані лише частково. Під час очищення PHP може помилково обробити некоректні дані як дійсні.
58
- CVE-2026-109619 пов’язана із застарілим внутрішнім станом. За описом, дані запиту можуть залишатися доступними після звільнення пам’яті, у якій вони зберігалися. Це створює проблему типу use-after-free — використання пам’яті після її звільнення.
9
Вразливості стосуються обробки спеціально сформованих HTTP-запитів, зокрема multipart/form-data — формату, який зазвичай використовують для передавання файлів через вебформи.
47 Якщо атаку успішно проведено, код виконується з правами облікового запису вебпроцесу. Це не означає автоматичного доступу адміністратора чи root.
1
Чому оцінка — 9,2 і чого вона не показує
Обидві вразливості мають оцінку 9,2 із 10 — Critical — за CVSS v4.0. Серед ключових причин серйозності — можливість віддаленого виконання коду без автентифікації: для спроби атаки зловмиснику не потрібно входити в обліковий запис на вразливому сервері.
47
Надані матеріали не містять повних векторів CVSS, тому за ними неможливо точно розкласти оцінку на окремі параметри. Високий рейтинг характеризує серйозність вразливості, але сам по собі не визначає ймовірність атаки на конкретний сервер і не свідчить про успішне проникнення.
Які версії PHP уразливі та що встановити
У звітах зазначено, що вразливий діапазон починається з PHP 5.4.
55 Для гілок PHP 8.x термінові виправлення доступні в таких версіях:
| Гілка PHP |
Виправлена версія |
| 8.2 |
8.2.35 |
| 8.3 |
8.3.36 |
| 8.4 |
8.4.27 |
| 8.5 |
8.5.12 |
Ці версії випустили 21 жовтня 2026 року. Оновіть PHP до відповідної виправленої версії або новішої версії тієї самої гілки.
47
Перелік охоплює гілки 8.2–8.5. Якщо система працює на старішій або непідтримуваній гілці, перевірте рекомендації постачальника PHP чи операційної системи щодо виправлень і переходу на іншу версію. Не вважайте, що одна з наведених версій безпосередньо підходить для таких систем.
Розкриття вразливостей і спроби експлуатації: це ще не підтверджені злами
Інформація про вразливості стала публічною 20 жовтня — раніше за заплановане розкриття 22 жовтня. Наступного дня PHP випустив термінові виправлення.
8
42 Джерела підтверджують передчасне розкриття та прискорений випуск оновлень, але не доводять, що причиною став помилково опублікований демонстраційний ролик Calif.
Amazon Threat Intelligence повідомила про спробу експлуатації PHP2Shell, яку зафіксувала телеметрія пастки MadPot 17 жовтня — за чотири дні до публічного розкриття. Amazon також повідомила, що приблизно під час випуску оновлень 21 жовтня виявила експлойти-підтвердження концепції. Телеметрія пастки показує активність проти системи-приманки, а не підтверджене проникнення в реальну організацію.
48
Cloudflare повідомила, що розгорнула захисні правила приблизно під час розкриття вразливостей; у тогочасних повідомленнях також ішлося про трафік атак і спроби експлуатації, помічені компаніями з кібербезпеки.
55
35 Водночас оцінки масштабів і результативності атак різнилися: одні постачальники безпекових рішень заявляли про активну або масову експлуатацію, а інші тогочасні матеріали зазначали, що державні установи не підтвердили успішних атак.
33
36
Наявні дані дають підстави серйозно ставитися до спроб експлуатації, але не дозволяють прирівнювати кожну спробу до успішного зламу чи стверджувати, що атаки були масштабними. Під час оцінювання ризиків важливо розрізняти ці поняття.
Що робити до встановлення оновлення
Основний спосіб усунення ризику — встановити виправлену версію PHP. AWS зазначає, що повне виправлення можливе лише через оновлення. Якщо негайно встановити його не можна, тимчасово зменшити ризик може блокування multipart-завантажень файлів. Це не замінює оновлення.
47
48
Канадський Центр кібербезпеки опублікував критичне попередження про ці вразливості та ризик виконання коду без автентифікації.
2 У наданих джерелах також повідомляється, що NSA рекомендувало відключити системи від мережі, якщо їх неможливо негайно оновити.
27 Дотримуйтеся відповідних рекомендацій постачальника й державних органів, зокрема якщо PHP входить до складу продукту або оновлюється хостинг-провайдером.
Практичний висновок простий: з’ясуйте, де у вас працює PHP, встановіть відповідне виправлення та уважно перевіряйте сигнали безпеки. Серйозність PHP2Shell вимагає швидких дій, але спроба атаки, працездатний експлойт і підтверджений злам робочої системи — різні речі.