Команда безпеки PHP оголосила про дві критичні вразливості з оцінкою CVSS v4.0 9.2 і запланувала позаплановий реліз безпеки на 21 жовтня 2026 року о 14:00 UTC. За даними дослідників із watchTowr, обидві вразливості дають змогу віддаленого виконання коду (RCE). Патчі отримають лише чотири підтримувані гілки — з 8.2 по 8.5. За підрахунками компанії Mallory, близько 884 000 хостів із доступом до інтернету працюють на застарілих версіях PHP і не отримають виправлень від вендора. Експлуатація в реальних атаках на момент публікації не зафіксована, але досвід із подібними вразливостями PHP показує, що атаки можуть початися протягом доби після розкриття деталей.
Що відомо про вразливості
Офіційне повідомлення PHP підтверджує існування двох критичних вразливостей, але не розкриває технічних деталей, уражених версій і навіть ідентифікаторів CVE. Повна інформація має бути опублікована разом із релізом. Ідентифікатори CVE-2026-109618 і CVE-2026-109619 фігурують у публікаціях дослідників і у витоку на Hacker News, але PHP у своєму повідомленні їх не називає.
Тут важливо відділити підтверджені факти від непідтверджених тверджень. Офіційно встановлено таке:
- Обидві вразливості оцінені командою безпеки PHP у CVSS v4.0 9.2 (Critical)
- Патчі випускаються для гілок PHP 8.2, 8.3, 8.4 і 8.5
- Технічні деталі, зокрема вразливий компонент і вектор атаки, наразі не розкриті
У витоку на Hacker News від 20 жовтня згадувалася оцінка CVSS 10.0 і твердження про те, що вразливості стосуються всіх версій, починаючи з PHP 5. Однак оцінка 10.0 — це число з неперевіреного витоку, а не офіційний рейтинг вендора. Як зазначає watchTowr у своєму FAQ, заявлене охоплення «починаючи з PHP 5» не підтверджене офіційним вендорським повідомленням, так само як не встановлені технічні причини вразливостей і вимоги до конфігурації для їх експлуатації.
Матриця вразливих версій та масштаб проблеми
На підставі доступних даних вимальовується така картина:
- Гілки 8.2–8.5 — підтримувані, отримають патчі. За даними Mallory, виправлені версії: 8.2.35, 8.3.36, 8.4.27 і 8.5.12 (ці номери версій вказані Mallory, а не в офіційному повідомленні PHP)
- PHP 8.1 і старші — гілки, що досягли кінця життєвого циклу (end of life), вендорського патча не отримають
- PHP 5 і далі — непідтверджений діапазон уразливості з витоку
Саме останній пункт створює найбільшу невизначеність. Якщо вразливості справді стосуються версій аж до PHP 5 включно, масштаб проблеми суттєво зростає. За підрахунками Mallory, із приблизно 1,5 мільйона інтернет-доступних хостів, які повідомляють версію PHP через HTTP-банери в Shodan, 883 717 (59%) працюють на гілках, які не отримають виправлень. Ще 740 000 хостів повідомляють про наявність PHP без указання версії. Ці цифри стосуються банерів, а не підтверджено вразливих систем або унікальних організацій, але вони вказують на значний потенційний масштаб впливу.
Статус експлуатації
За даними watchTowr, станом на 21 жовтня 2026 року експлуатацію в реальних атаках не зафіксовано. Huntress повідомляє, що станом на 20 жовтня не спостерігала експлуатації в середовищі своїх партнерів, не відтворила proof of concept і не мала інформації про публічний код експлойта. Вразливості не внесені до каталогу CISA Known Exploited Vulnerabilities. Підтверджених індикаторів компрометації (IOC) на момент публікації також немає.
Водночас відсутність зафіксованої експлуатації — це оцінка, обмежена в часі. Для порівняння: коли в червні 2024 року була розкрита CVE-2024-4577 (вразливість PHP у режимі CGI на Windows), спроби експлуатації були зафіксовані Akamai на honeypot серверах протягом 24 годин.
Хронологія витоку та реакції
Ситуація розвивалася нестандартно. 20 жовтня на Hacker News з’явився допис з інформацією про дві RCE-вразливості в PHP, нібито з оцінкою CVSS 10.0, із зазначенням CVE-ідентифікаторів і датою розкриття — 22 жовтня (четвер). Автор допису визнав, що його джерело — «trust me, bro». Після цього watchTowr підтвердила в X, що витік реальний, вразливості перебували під ембарго, і всі мали чекати четверга. PHP опублікував своє повідомлення того ж вечора, о 19:33 UTC, призначивши реліз на середу — на день раніше за дату, вказану у витоку. Повідомлення містить застереження: реліз може бути пришвидшений, якщо деталі вразливостей стануть публічними або з’являться свідчення активної експлуатації.
Витік розкрив факт існування вразливостей, оцінку, дату й CVE-ідентифікатори, але не механізм роботи вразливостей. Це важлива відмінність: інформації для створення експлойта у витоку не було.
Практичні рекомендації
PHP не опублікував тимчасових рішень (workaround). До виходу патча рекомендується такий набір дій, заснований на рекомендаціях Huntress і CERT-EU:
- Інвентаризація: виявте всі інсталяції PHP, включно з вбудованим PHP у вендорських пристроях, застосунках Windows і панелях керування (cPanel, Plesk)
- Готовність до оновлення: підготуйтеся до встановлення патча одразу після виходу релізу. Інтернет-доступні системи — у першу чергу. Перевірте наявність бекпортованих пакетів у вашому дистрибутиві Linux або в постачальника хостингу
- Застарілі версії: системи на PHP 8.1 і старших необхідно оновити, вивести з інтернету або розмістити за VPN чи WAF
- Ізоляція: CERT-EU рекомендує розглянути ізоляцію інтернет-доступних PHP-застосунків від публічних мереж до виходу виправлення
- Моніторинг процесів: налаштуйте сповіщення під час запуску php-fpm, php-cgi, httpd або apache2 оболонок, інтерпретаторів чи засобів завантаження. На Linux-серверах без EDR можна використовувати process-watcher від Флоріана Рота — інструмент логує кожну програму, запущену процесом PHP, із командним рядком. Важливо: він фіксує процес уже після запуску і, за словами автора, «нічого не запобігає»
- Реагування на інцидент: у разі виявлення підозрілої активності ізолюйте сервер, збережіть логи вебсервера й PHP, перевірте наявність вебшелів, нових файлів у корені сайту, нових задач cron і облікових записів
Пріоритет патчінгу слід вибудовувати з урахуванням того, що системи на застарілих гілках PHP (8.1 і старші) не отримають вендорського виправлення. За даними Mallory, таких інтернет-доступних хостів — близько 884 000. Для цих систем єдині варіанти — оновлення до підтримуваної гілки, обмеження мережевого доступу або розміщення за WAF. Організаціям на підтримуваних гілках (8.2–8.5) необхідно встановити патч одразу після його публікації, починаючи з інтернет-доступних серверів.
Реліз має прояснити ключові невідомі: які саме версії уражені, який компонент PHP містить вразливість, чи вимагає експлуатація певного режиму роботи PHP або конфігурації, і як сам вендор описує вразливості. До цього моменту всі дії мають превентивний характер, а найважливіший крок — забезпечити готовність до негайного оновлення підтримуваних гілок та ізолювати або вивести з експлуатації системи на застарілих версіях PHP.
