Сайт на PHP чи WordPress: що перевірити після PHP2Shell?

Насамперед перевірте, яка версія PHP насправді обслуговує ваш робочий сайт, і оновіть її до виправленої: 8.5.12, 8.4.27, 8.3.36, 8.2.35 або новішої, чи до пакета з латкою від вашого дистрибутива чи хостингу. Потім пройдіть базові речі, які PHP2Shell знову підсвітив: оновлення WordPress і плагінів, адмінські акаунти, резервні копії і хто відповідає за кожен сайт.

Нижче лише перевірені факти з датами, практичний чекліст і таблиця відповідальних, яку варто заповнити цього тижня.

Коротко

• 21 жовтня 2026 року проєкт PHP випустив виправлення двох критичних вразливостей, які разом називають PHP2Shell. ^[1]
• Вразливі інсталяції PHP, що обробляють вебзапити: PHP-FPM, Apache з mod_php, php-cgi, FrankenPHP, LiteSpeed. ^[1]
• Спроби атак фіксували ще до виходу виправлень. ^{[5] [6]}
• Повноцінного обхідного рішення немає. Фільтр вебзапитів (WAF) купує час, але не замінює оновлення. ^{[1] [4]}
• Версія в документації нічого не гарантує. Дивіться, що працює на сервері, і хто відповідає за кожен сайт.

Що сталося: факти з датами

20 жовтня 2026 року проєкт PHP попередив про критичний випуск безпеки, а 21 жовтня опублікував виправлені версії і бюлетень. Обидві вразливості дозволяють виконати чужий код на сервері (RCE, віддалене виконання коду), команда PHP оцінила кожну на 9,2 з 10 за CVSS v4. ^[1]

Що ще відомо станом на 23 жовтня 2026 року:

• Хто знайшов. Wiz Research і Calif за участі OpenAI. Wiz пише, що вразливі версії сягають PHP 5.4, і що у своїх тестах вони виконали код без входу в систему на WordPress, Drupal і Joomla. ^[4]
• Старі гілки. Для PHP 8.1 і старіших офіційних випусків немає, команда PHP опублікувала лише латки у вихідному коді для 7.4, 8.0 і 8.1. ^[1] Дистрибутиви на кшталт Ubuntu і Debian випускають латки під старими номерами версій. ^[5]
• Атаки. За даними Sansec, Cloudflare повідомив про перші атаки 21 жовтня о 07:43 UTC, до виходу виправлень. 22 жовтня Sansec уточнив, що масова експлуатація менш імовірна, ніж здавалося, а публічні експлойти не працюють на стандартній інсталяції. ^[5] Tenable пише, що Amazon бачив спроби атак ще 17 жовтня, а в каталозі CISA KEV (переліку вразливостей, які точно експлуатують) станом на 22 жовтня цих вразливостей не було. ^[6]
• Тимчасові заходи. Команда PHP рекомендує вимкнути session.upload_progress.enabled і обмежити post_max_size, але прямо пише, що повного захисту без оновлення немає. 23 жовтня вийшов додатковий бюлетень із тією ж порадою щодо session.upload_progress.enabled. ^[1]

Яка версія PHP насправді працює на сайті

Документація, договір із підрядником і памʼять адміністратора тут не допоможуть. Перевіряйте сервер:

• WordPress. У панелі: Інструменти, Здоровʼя сайту, Інформація, розділ Сервер. Там видно версію PHP, яка обслуговує саме цей сайт.
• Хостинг. Панель керування показує версію для кожного сайту окремо. На одному акаунті різні сайти часто працюють на різних версіях.
• Власний сервер. Команда php -v у консолі показує версію для командного рядка, а сайт може працювати через PHP-FPM іншої версії. Дивіться пакет, який реально обслуговує вебсервер.
• Номер версії і латка. Якщо сервер на Ubuntu, Debian чи схожій системі, номер може залишитися старим, хоча латку встановлено. Перевірте журнал змін пакета або попросіть хостинг письмово підтвердити, що виправлення встановлено.

Окремо зверніть увагу на PHP 8.2: підтримка безпеки цієї гілки закінчується 31 грудня 2026 року. ^[7] WordPress рекомендує PHP 8.3 або новіший. ^[8]

Чому WAF не замінює оновлення

WAF (фільтр, що відсікає підозрілі вебзапити) може заблокувати відомі варіанти атаки. Sansec описує тимчасове правило, яке блокує запити певного типу, і попереджає, що воно ламає завантаження файлів. ^[5] Wiz прямо пише, що оновлення PHP залишається єдиним повним виправленням. ^[4] Отже, фільтр дає вам кілька днів на оновлення, але не звільняє від нього.

WordPress: що перевірити, крім PHP

PHP2Shell стосується самого PHP, але зламують зазвичай через найслабше місце, і саме його шукає пентест. Пройдіться по базових речах:

• Ядро, плагіни, теми. Оновіть усе, що має оновлення. Перед цим зробіть резервну копію. ^[9]
• Невикористані плагіни і теми. Вимкнений плагін залишається файлами на сервері. Якщо він не потрібен, видаліть його.
• Адміністратори. Перегляньте список користувачів із правами адміністратора. Колишні працівники, підрядники з минулого проєкту, загальні акаунти на кшталт «admin»: усе зайве приберіть.
• Двофакторний вхід. У WordPress його додають плагіном, документація WordPress перелічує варіанти. ^[10] Увімкніть його хоча б для всіх адміністраторів.
• Резервні копії. Перевірте не те, що копія є, а те, що з неї можна відновити сайт. Спробуйте на окремому сервері.

Хто відповідає за кожен сайт

Найчастіше старий PHP живе не на головному сайті, а на лендингу акції трирічної давності, тестовій копії чи блозі, який зробив колишній підрядник. Складіть таблицю всіх сайтів компанії і заповніть її фактами, а не припущеннями:

Рядки з «ніхто» і «невідомо» це і є ваш ризик. Такий сайт або отримує відповідального, або вимикається.

Чекліст для власника і IT

• Складено перелік усіх сайтів і піддоменів компанії.
• Для кожного сайту записано відповідального.
• Версію PHP перевірено на сервері, а не в документації.
• PHP оновлено до 8.5.12, 8.4.27, 8.3.36, 8.2.35 або новішої, або хостинг письмово підтвердив латку.
• Сайти на PHP 8.1 і старіших мають план переходу.
• Ядро WordPress, плагіни і теми оновлено.
• Невикористані плагіни й теми видалено.
• Список адміністраторів переглянуто, зайвих прибрано.
• Двофакторний вхід увімкнено для всіх адміністраторів.
• Відновлення з резервної копії перевірено.
• Тимчасові заходи (WAF, налаштування PHP) записано як тимчасові, з датою оновлення.

Завантажити чекліст підготовки (PDF)PDF · A4

Коли потрібна зовнішня перевірка

Якщо сайтів багато і ніхто не впевнений, що саме відкрито в інтернеті, почніть із зовнішнього огляду: він показує, які ваші сайти і сервіси видно ззовні. Щоб систематично знайти застарілі версії і відомі вразливості на погодженому периметрі, підходить Vulnerability Assessment. Якщо на сайті є кабінет клієнта, платежі чи персональні дані, глибше покаже пентест. Будь-які активні перевірки ми робимо лише після погодження меж і письмового дозволу.

FAQ

Мій сайт на WordPress. Чи достатньо оновити WordPress?

Ні. PHP2Shell сидить у самому PHP, а не у WordPress. Оновлення WordPress потрібне, але PHP оновлює хостинг або ваш адміністратор окремо.

Хостинг каже, що все оновлено, але версія в панелі стара. Чи це проблема?

Не обовʼязково. Дистрибутиви часто ставлять латку, не змінюючи номер версії. Попросіть хостинг письмово підтвердити, що виправлення обох вразливостей PHP2Shell з бюлетеня від 21 жовтня встановлено.

У нас PHP 7.4. Що робити?

Офіційних випусків для такої гілки немає. Тимчасово допоможе пакет із латкою від дистрибутива, але реальне рішення це перехід на підтримувану версію. Плануйте його зараз.

Чи захистить нас Cloudflare або інший WAF?

Він може відсікти відомі варіанти атаки і дати час. Але повного захисту без оновлення PHP немає, про це пишуть і команда PHP, і дослідники.

Як зрозуміти, що сайт уже атакували?

Wiz радить звернути увагу на незвичні запити із завантаженням файлів, після яких зʼявляються помилки ліміту памʼяті, повторні помилки 500 і незрозумілі перезапуски процесів PHP. Якщо таке бачите, залучіть фахівця до розслідування, а не лише оновлюйте.

Посилання

1. PHP News Archive 2026: Security advisory, critical remote code execution vulnerabilities php.net
2. PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) github.com
3. PHP security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) github.com
4. Wiz Research: PHP2Shell wiz.io
5. Sansec: PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619) sansec.io
6. Tenable: php2shell FAQ tenable.com
7. PHP: Supported Versions php.net
8. WordPress: Requirements wordpress.org
9. WordPress: Updating WordPress wordpress.org
10. WordPress: Two Step Authentication developer.wordpress.org