PHP випустив виправлення для двох критичних вразливостей, CVE-2026-109618 та CVE-2026-109619, які дослідники назвали PHP2Shell. Усі підтримувані версії PHP необхідно оновити якнайшвидше. За інформацією PHP, обидві вразливості можуть дозволити віддалене виконання коду без автентифікації. Команда безпеки PHP оцінила кожну з них у 9,2 бала за CVSS v4.0.
21 жовтня 2026 року вийшли версії PHP 8.5.12, 8.4.27, 8.3.36 та 8.2.35, у яких ці вразливості виправлено. Життєвий цикл PHP 8.1 і старіших версій завершився, тому вони більше не отримують офіційних оновлень. Водночас команда безпеки PHP опублікувала мінімальні виправлення, перенесені у вихідний код PHP 7.4, 8.0 та 8.1. Наразі не повідомлялося про випадки використання цих вразливостей у реальних атаках, і жодна з них не внесена до каталогу CISA KEV. Своєчасне встановлення оновлень допоможе запобігти атакам із їх застосуванням. Зокрема, спроби експлуатації попередньої критичної вразливості PHP, CVE-2024-4577, розпочалися вже протягом доби після її оприлюднення.
Оновлення підтримуваних версій PHP – відносно просте завдання. Значно складніше виявити всі встановлені екземпляри PHP у мережі. Це стосується як систем, недоступних для зовнішнього спостереження, так і версій, які проєкт PHP більше не оновлює. CERT-EU та Федеральне відомство з інформаційної безпеки Німеччини (BSI) опублікували рекомендації з безпеки для обидвох вразливостей.
Що означає PHP2Shell для версій PHP із завершеним життєвим циклом
Наразі PHP підтримує чотири гілки версій: 8.2 та 8.3 отримують лише виправлення безпеки, тоді як 8.4 та 8.5 перебувають на етапі активної підтримки. Підтримка безпеки PHP 8.2 завершується 31 грудня 2026 року.
Життєвий цикл усіх старіших гілок уже завершився:
- PHP 8.1 – 31 грудня 2025 року.
- PHP 8.0 – 26 листопада 2023 року.
- PHP 7.4 – 28 листопада 2022 року.
- PHP 5.6 – 31 грудня 2018 року.
У повідомленнях PHP зазначено, що всі версії, старіші за 8.2.35, вразливі. Для гілок із завершеним життєвим циклом PHP рекомендує використовувати виправлення, перенесені до відповідних версій розробниками дистрибутивів або постачальниками довгострокової підтримки (LTS). Крім того, команда безпеки PHP опублікувала мінімальні виправлення у вихідному коді PHP 7.4, PHP 8.0 та PHP 8.1 для тих, хто самостійно збирає програмне забезпечення. Старіші гілки, зокрема PHP 5.6, не отримують жодного з цих варіантів патчів. Проте перш ніж усунути вразливості в таких системах, необхідно визначити, де саме вони працюють.
В інтернеті досі використовується велика кількість застарілих PHP. За результатами підрахунку банерів Shodan, проведеного Mallory 20 жовтня 2026 року, близько 884 000 доступних з інтернету хостів повідомляють про використання версій PHP із завершеним життєвим циклом. Це становить 59% від приблизно 1,5 млн хостів, які взагалі розкривають інформацію про версію PHP. Ще близько 740 000 хостів не розкривають свою версію PHP. Важливо, що ці цифри отримані на основі банерів служб і не означають, що вразливість усіх зазначених систем підтверджена.
Відсутність інформації про версію PHP у банері не означає, що PHP не використовується на відповідному сервері. PHP також працює у складі панелей керування, таких як cPanel і Plesk, систем керування вмістом та програмного забезпечення інших виробників. У таких випадках оновлення залежать від графіків відповідних постачальників або можуть взагалі не встановлюватися.
Оцінка ризиків PHP2Shell
Інформація про обидві вразливості потрапила у відкритий доступ до запланованого узгодженого розкриття. Через це PHP випустив виправлення на день раніше від початково визначеної дати. Станом на 21 жовтня 2026 року watchTowr та BSI повідомляють про відсутність підтверджених випадків експлуатації цих вразливостей у реальних атаках. Жодна з них також не внесена до каталогу CISA KEV. Водночас можливість практичного використання вразливостей підтверджена. У повідомленні PHP зазначено, що віддалене виконання коду без автентифікації вдалося підтвердити через HTTP для mod_php зі стандартними обмеженнями на вхідні дані та використання пам’яті.
Раніше зловмисники вже демонстрували здатність швидко розпочинати експлуатацію вразливостей PHP. Коли в червні 2024 року було оприлюднено інформацію про критичну вразливість CVE-2024-4577, компанія Akamai зафіксувала перші спроби її використання на своїх системах-пастках протягом доби.
Технічні подробиці CVE-2026-109618 та CVE-2026-109619 у PHP
За оцінкою PHP, під загрозою перебувають усі екземпляри, які обробляють вебзапити. Це стосується PHP-FPM, Apache з mod_php, php-cgi, FrankenPHP та LiteSpeed. Найвищий рівень ризику виробник визначає для mod_php, оскільки запит без автентифікації може спричинити атаку ще до початку виконання коду застосунку. В обох повідомленнях серед типів вразливостей зазначено використання пам’яті після її звільнення (use-after-free, CWE-416). У ChangeLog обидві вразливості наведено в межах одного виправлення ядра PHP – «Avoid state corruption via bailout» (запобігання пошкодженню стану під час аварійного завершення виконання).
CVE-2026-109618
- CVSS 9.2 – Критична
- EPSS: очікується перевірка
Віддалене виконання коду (RCE) через пошкодження даних у пам’яті внаслідок її вичерпання (OOM) (GHSA-w8hw-w9fx-j79w). Якщо PHP вичерпує доступну пам’ять у момент, коли внутрішні дані запиту ініціалізовані лише частково, процедура очищення після обробки запиту може помилково сприйняти некоректні дані як дійсні.
CVE-2026-109619
- CVSS 9.2 – Критична
- EPSS: очікується перевірка.
Віддалене виконання коду (RCE) через використання застарілого глобального стану (GHSA-6wmf-4rv5-p3rp). Внутрішній стан, пов’язаний з одним запитом, може зберігатися в постійному робочому процесі навіть після звільнення виділеної для нього пам’яті. Унаслідок цього наступний запит, який обробляє той самий робочий процес, може використати цей стан.
Повні технічні подробиці наведено в повідомленнях PHP.
Вразливі версії PHP та способи усунення CVE-2026-109618 і CVE-2026-109619
Усі підтримувані екземпляри необхідно оновити до версій PHP 8.5.12, 8.4.27, 8.3.36 або 8.2.35 відповідно до використовуваної гілки. У разі використання версії із завершеним життєвим циклом рекомендовано перейти на підтримувану гілку. Оскільки підтримка безпеки PHP 8.2 завершується 31 грудня 2026 року, доцільніше обрати PHP 8.4 або 8.5. Якщо оновлення до підтримуваної гілки поки неможливе, необхідно перевірити наявність виправлень, перенесених до відповідних версій постачальником дистрибутива або LTS. Альтернативний варіант – самостійна збірка PHP із використанням виправленого вихідного коду для версій 7.4, 8.0 та 8.1.
Якщо негайне встановлення оновлень неможливе, рекомендуються зміни конфігурації, які зменшують ризик експлуатації через окремі шляхи атаки. Наприклад:
- Встановлення memory_limit=-1 для зниження ризику експлуатації CVE-2026-109618.
- Встановлення session.upload_progress.enabled=0 для зниження ризику експлуатації CVE-2026-109619.
PHP наголошує, що ці заходи не гарантують безпеку встановлених екземплярів. Єдиним способом повністю усунути вразливості залишається інсталяція оновлень. CERT-EU також рекомендує ізолювати доступні з інтернету застосунки від публічних мереж до встановлення виправлень.
Розробники дистрибутивів Linux іноді переносять патчі до власних пакетів PHP без зміни номера версії. За інформацією PHP, розробники дистрибутивів і постачальники LTS отримали виправлення заздалегідь. Тому необхідно перевірити наявність оновлених пакетів у відповідного постачальника. Якщо PHP постачається у складі панелей керування, систем керування вмістом або програмно-апаратних комплексів, інформацію про оновлення необхідно уточнювати у відповідного виробника.
| Гілка PHP | Статус | Версія з виправленням | Примітки |
| 8.5 | Активна підтримка до 31 грудня 2027 року | 8.5.12 | |
| 8.4 | Активна підтримка до 31 грудня 2026 року | 8.4.27 | |
| 8.3 | Лише виправлення безпеки до 31 грудня 2027 року | 8.3.36 | |
| 8.2 | Лише виправлення безпеки до 31 грудня 2026 року | 8.2.35 | Рекомендовано перейти на 8.4 або 8.5 |
| 8.1 і старіші | Життєвий цикл завершено | Офіційної версії з виправленням немає | Визначені як вразливі. Доступні мінімальні виправлення у вихідному коді для 7.4, 8.0 та 8.1. Наявність пакетів із перенесеними виправленнями необхідно перевіряти у постачальника дистрибутива або LTS. |
Як виявити вразливі екземпляри PHP з OPENVAS (Enterprise)
В OPENVAS SCAN (Enterprise версії сканера мережевих вразливостей) перевірки CVE-2026-109618 та CVE-2026-109619 працюють як під час сканування з автентифікацією, так і без неї. Проте ці два методи дозволяють отримати різну інформацію.
Сканування без автентифікації виявляє лише ті дані, які сервер надає ззовні. Якщо хост приховує версію PHP, сканер не може визначити, яка саме версія використовується. У такому випадку достовірність результатів залежить від точності інформації про версію, яку передає сервер.
Під час сканування з автентифікацією виконується вхід до системи та перевірка встановленого програмного забезпечення. Завдяки цьому PHP можна виявити на кожному хості, який сканується з використанням облікових даних, незалежно від того, чи розкриває сервер інформацію про його версію.
Для поглибленого пошуку на хостах Windows перед скануванням необхідно увімкнути виявлення портативних застосунків. Для цього потрібно:
- Відкрити конфігурацію сканування для редагування, наприклад копію Full and fast.
- Прокрутити сторінку до розділу Network Vulnerability Test Preferences.
- Знайти параметр Options for Local Security Checks.
- Для параметра Enable Detection of Portable Apps on Windows встановити значення yes.
- Зберегти зміни.
Сканування з автентифікацією потребує більше часу та створює більше навантаження на системи, що перевіряються. Тому його охоплення та час проведення необхідно планувати з урахуванням цих особливостей.
Висновок
CVE-2026-109618 та CVE-2026-109619 – дві критичні вразливості PHP, які можуть дозволити віддалене виконання коду без автентифікації.
PHP усунув їх у версіях 8.5.12, 8.4.27, 8.3.36 та 8.2.35. Для гілок із завершеним життєвим циклом усунення вразливостей залежить від доступності виправлень, перенесених до старіших версій.
Наразі випадків експлуатації цих вразливостей не зафіксовано. Однак спроби використання попередньої критичної вразливості PHP, CVE-2024-4577, розпочалися вже протягом доби після її оприлюднення. Тому фахівцям із кібербезпеки необхідно якнайшвидше встановити оновлення, а потім виявити всі раніше не враховані екземпляри PHP. Особливу увагу слід приділити версіям із завершеним життєвим циклом, хостам, які приховують інформацію про версію PHP, а також екземплярам PHP, що постачаються у складі іншого програмного забезпечення.
