Часті запитання
Які версії PHP вразливі?
Усі версії до 8.5.12, 8.4.27, 8.3.36 і 8.2.35 у підтримуваних гілках. Підтримку PHP 8.1 і старіших версій припинено, проєкт PHP не випускає для них оновлень; вважайте їх вразливими, доки постачальник не підтвердить перенесене виправлення.
Мій сайт не показує версію PHP. Я в безпеці?
Не обов’язково. Приховування версії (expose_php = Off) — добра практика, але воно нічого не виправляє. Перевірте на сервері командою php -v або зверніться до провайдера.
Перевірка показує стару версію, а хостинг каже, що її виправлено. Хто має рацію?
Можливо, обидва. Дистрибутиви Linux, як-от Debian, Ubuntu і RHEL, часто переносять виправлення безпеки, не змінюючи номер версії. Запитайте в хостингу, яку збірку пакета встановлено і чи згадуються в її журналі змін CVE-2026-109618 і CVE-2026-109619.
Чи вразливі WordPress, Laravel або моя CMS?
Вразливості містяться в самому PHP, тому під загрозою будь-який застосунок, що працює на вразливому PHP. Дослідники продемонстрували атаки без автентифікації на WordPress, Drupal і Joomla, але це лише приклади — достатньо навіть простої сторінки «Hello World». Оновлення WordPress чи плагінів проблему не вирішує — потрібно оновити PHP.
Чи можуть дані витекти, навіть якщо код не виконувався?
Так. CVE-2026-109619 може розкрити пам’ять процесу PHP — паролі, токени сесій, ключі API і сертифікати з інших запитів — без виконання коду зловмисником. Такі витоки не залишають файлів, і їх важко виявити, тому змініть секрети кожного сайту, який працював на вразливій версії в інтернеті.
Чи допомагає вимкнення session.upload_progress?
Ні. php.net наводить session.upload_progress.enabled=0 як частковий захід захисту для деяких підтверджених шляхів CVE-2026-109619. Він не покриває всіх варіантів і ніяк не допомагає проти CVE-2026-109618.
Чи достатньо міжмережевого екрана вебзастосунків?
WAF або обмеження запитів можуть знизити ризик на час оновлення, але проблеми полягають у тому, як PHP обробляє запити й пам’ять. Оновлення все одно необхідне.
Чи потрібно щось перезапускати після оновлення?
Так. PHP-FPM, Apache, LiteSpeed і довготривалі процеси продовжують виконувати старий код, доки їх не перезапустять. Контейнери потрібно пересоздати з нового образу.
Що насправді робить ця перевірка?
Вона надсилає один запит HEAD (або GET, якщо HEAD не дозволено) за вказаною вами адресою, виконує не більше трьох перенаправлень і читає заголовки відповіді, як-от X-Powered-By і Server. Вона ніколи не надсилає експлойти, великі запити чи файли і не сканує інші шляхи.
Чи законно перевіряти будь-який сайт?
Перевіряйте лише сайти, якими ви володієте або які вам дозволено оцінювати. Запит нічим не відрізняється від звичайного відвідування, але відповідальність за коректне використання лежить на вас. Ми обмежуємо кількість перевірок для кожної мережі та кожного сайту.
Чи повністю виправлено PHP 8.5.12?
22 жовтня 2026 року з’явилися повідомлення про збій у 8.5.12, але їх не було підтверджено як віддалено експлуатовану вразливість. Ми стежимо за php.net; якщо вийде новий випуск, сайт буде оновлено, а дата «останньої перевірки» зміниться.
Де прочитати офіційні подробиці?
На php.net і в бюлетенях проєкту PHP на GitHub GHSA-w8hw-w9fx-j79w і GHSA-6wmf-4rv5-p3rp. Дослідницька група (Wiz Research, OpenAI Codex Security і Calif) опублікувала свої результати на php2shell.com.
Хто виявив вразливості?
Дослідники з Wiz Research, OpenAI Codex Security і Calif у межах скоординованого розкриття спільно з командою безпеки PHP, яка підготувала виправлення. Див. публікацію The PHP Foundation про випуск.