Критична вразливість PHP: чи в безпеці ваш сайт і що запитати в хостера

Що сталося 20–21 жовтня 2026 року

20 жовтня 2026 року команда PHP заздалегідь попередила, що наступного дня вийде позачерговий випуск безпеки, який закриває дві критичні вразливості. 21 жовтня вийшли версії PHP 8.5.12, 8.4.27, 8.3.36 і 8.2.35. В офіційному анонсі на php.net сказано прямо: ці версії виправляють дві критичні вразливості, які можуть дозволити віддалене виконання коду без автентифікації, і всім користувачам PHP наполегливо рекомендують оновитися негайно.

В англомовних джерелах ця пара вразливостей отримала неофіційну назву PHP2Shell. Обидві мають оцінку 9.2 за шкалою CVSS v4.0, тобто належать до найнебезпечнішої категорії.

Дві вразливості простими словами

• CVE-2026-109618 — помилка в обробці нестачі пам’яті. Якщо PHP перериває обробку запиту в момент, коли внутрішні дані ще не до кінця підготовлені, під час очищення ці «напівготові» дані можуть вважатися коректними. Цим можна скористатися для виконання стороннього коду.
• CVE-2026-109619 — «застарілий» внутрішній стан. Частина даних одного запиту може пережити його завершення, і наступний запит, який обробляє той самий процес, може скористатися ними ще до того, як вони будуть скинуті.

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

Додаткова порада від 23 жовтня

23 жовтня на php.net з’явилося ще одне повідомлення: до наступного планового випуску рекомендовано вимкнути налаштування session.upload_progress. Воно стосується пов’язаної проблеми CVE-2026-115560, яка проявляється лише в особливих випадках. Це налаштування сервера, тому його теж варто згадати в листі до хостера.

Чому це не вразливість WordPress і чому оновлення плагінів не допоможуть

Більшість новин про безпеку сайтів стосується конкретної CMS або плагіна: «оновіть плагін X до версії Y». Звичка натиснути «Оновити все» в адмінці справді захищає від багатьох загроз. Але цього разу проблема на рівень нижче. PHP — це мова, якою написані WordPress, OpenCart, Drupal, Joomla, CodeIgniter, Laravel і тисячі самописних сайтів. Вона встановлена на сервері хостингу, а не всередині вашого сайту.

Тому будь-які дії в адмінці тут безсилі: оновлення ядра WordPress, плагіни безпеки, зміна паролів. За даними команди PHP, для найризикованішої конфігурації сервера існує робочий експлойт, який спрацьовує від анонімного запиту ще до того, як починає виконуватися код самого сайту. Тобто до вашого WordPress справа навіть не доходить.

Звідси практичний висновок: відповідальність за виправлення лежить на тому, хто керує сервером. На звичайному хостингу це хостер. На VPS чи власному сервері — ви або ваш адміністратор. Якщо ви не знаєте, хто саме, це вже сигнал, що за технічним станом сайту ніхто не стежить. Для таких випадків існує регулярне технічне обслуговування сайту, коли оновленнями сервера і CMS займається відповідальна людина.

Які сайти під загрозою

За даними php.net, під загрозою кожна інсталяція PHP, яка обслуговує веб-запити. Йдеться про всі поширені способи запуску PHP на сервері: PHP-FPM, Apache з mod_php, php-cgi, FrankenPHP, LiteSpeed. Найвищий ризик команда PHP бачить саме для mod_php. PHP-FPM, який часто використовують на сучасних хостингах, менш вразливий, але теж не безпечний.

Ситуація за версіями PHP

• PHP 8.2, 8.3, 8.4, 8.5 — є офіційні виправлення: 8.2.35, 8.3.36, 8.4.27, 8.5.12 або новіші в тій самій гілці. Потрібно лише, щоб хостер їх встановив.
• PHP 7.4, 8.0, 8.1 — офіційних випусків не буде, бо ці гілки вже не підтримуються. Команда PHP опублікувала лише мінімальні виправлення у вигляді вихідного коду для тих, хто сам збирає PHP. Частина дистрибутивів Linux і постачальників платної довгострокової підтримки випускають власні латки, тож усе залежить від хостера.
• PHP 7.3 і старіші, включно з 5.6 — виправлень немає взагалі. Такий сайт можна захистити лише переходом на новішу версію PHP.

Окремо варто пам’ятати про дату 31 грудня 2026 року: тоді завершується підтримка PHP 8.2. Якщо ваш сайт зараз на 8.2, після оновлення до 8.2.35 він у безпеці, але вже до кінця року варто планувати перехід на 8.3 або новішу.

Чи вже атакують сайти

Тут джерела розходяться, і про це чесно варто сказати. За даними хостинг-провайдера MassiveGrid, уже вдень 21 жовтня Cloudflare повідомив про перші спроби атак і ввімкнув екстрені правила свого фаєрвола для всіх тарифів. Дослідницькі компанії watchTowr і Huntress відтворили одну з вразливостей. У мережі ширяться коди експлойтів, частина з них — із неперевірених джерел.

Водночас інші джерела зазначають, що надійність публічних експлойтів поки не доведена, а на момент перших публікацій жодна з двох вразливостей не потрапила до каталогу активно експлуатованих вразливостей американського агентства CISA. Але для власника сайту ця суперечка мало що змінює. Після публікації деталей автоматичні сканери перебирають сайти масово, не розбираючи, великий це інтернет-магазин чи сторінка майстра з ремонту. Чекати, доки атаки стануть масовими, нема сенсу.

Як дізнатися версію PHP свого сайту

Перевірити версію PHP можна самостійно за кілька хвилин, навіть без технічних знань. Ось три способи — від найпростішого до найточнішого.

Спосіб 1. В адмінці WordPress

Відкрийте Інструменти → Здоров’я сайту → Інформація → Сервер. У рядку «Версія PHP» побачите номер, наприклад 8.3.36. Якщо WordPress показує попередження про застарілу версію PHP на вкладці «Стан», це вже привід діяти.

Спосіб 2. У панелі хостингу

У cPanel версію видно в розділах «Select PHP Version» або «MultiPHP Manager», в інших панелях — у налаштуваннях домену. Там же часто можна перемкнути сайт на новішу гілку PHP. Але робіть це лише після перевірки сумісності сайту, про це нижче.

Спосіб 3. Запитати хостера або адміністратора

Найнадійніший варіант, бо номер версії не завжди розповідає всю історію. На серверах із пакетами дистрибутивів Linux латки часто вносять без зміни номера: наприклад, виправлений PHP в Ubuntu 24.04 може показувати 8.3.6. Тому відповідь «у вас 8.3» ще не означає «ви захищені». Захищеність підтверджує лише той, хто встановлював оновлення.

Що запитати в хостера: готовий лист

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

Питання, які варто поставити

• Чи встановлені на сервері, де працює мій сайт, виправлення вразливостей PHP CVE-2026-109618 і CVE-2026-109619?
• Яка версія PHP використовується для мого сайту і чи це виправлена збірка (8.2.35, 8.3.36, 8.4.27, 8.5.12 або латка дистрибутива)?
• Чи оновлені всі версії PHP, доступні на сервері, а не лише основна? На одному сервері часто стоїть кілька збірок PHP.
• Чи перезапущені процеси PHP після оновлення?
• Чи вимкнено session.upload_progress, як рекомендує php.net від 23 жовтня?
• Якщо мій сайт на PHP 7.4, 8.0 чи 8.1 — чи є для цієї версії латка, і хто її підтримує?
• Чи використовується фаєрвол (WAF), який блокує відомі шаблони цієї атаки?

Якщо хостер відповідає розмито («у нас усе безпечно») або не розуміє, про що мова, — це вагомий привід подумати про переїзд на інший хостинг. Відповідь «ваш сайт на PHP 5.6, оновлень немає» означає, що проблема вже не в хостингу, а в самому сайті.

Якщо у вас VPS або власний сервер

На VPS ніхто не оновить PHP за вас. Порядок дій, який рекомендують php.net і хостинг-провайдери, виглядає так.

• Знайдіть усі інсталяції PHP. Пакет дистрибутива, збірки панелей керування, альтернативні версії PHP, тестові й забуті сайти — кожну потрібно оновити.
• Почніть із mod_php, потім PHP-FPM, FrankenPHP і LiteSpeed.
• Перезапустіть процеси. Для mod_php потрібен повний перезапуск Apache, а не м’яке перезавантаження конфігурації. Для PHP-FPM — перезапуск усіх пулів.
• Для пакетів дистрибутива перевіряйте не номер версії, а журнал змін пакета: у ньому мають бути номери CVE.
• Якщо оновитися прямо зараз неможливо, php.net радить тимчасові заходи: вимкнути session.upload_progress.enabled у php.ini чи конфігурації пулу (не через ini_set() і не через .user.ini) і зменшити post_max_size, якщо великі завантаження не потрібні. Але команда PHP окремо наголошує: ці заходи лише звужують шляхи атаки і не роблять сервер безпечним. Повне рішення одне — оновлення.

Старий сайт на PHP 5.6 або 7.x: що робити

Найскладніша ситуація у власників сайтів, які зробили 6–10 років тому і відтоді майже не чіпали. Такі сайти часто працюють на PHP 5.6 чи 7.x просто тому, що на новішій версії «все ламається». І цього разу виправлень для них немає зовсім.

Чому сайт не можна просто перемкнути на PHP 8.3 в панелі хостингу? Між гілками PHP змінювалися функції та правила мови. Старі теми, плагіни й самописний код можуть видати помилку, білий екран або тихо зламати кошик, форми чи оплату. Тому перехід на нову версію PHP — це технічна робота: оновити CMS і модулі, замінити покинуті плагіни, виправити несумісний код, протестувати на копії сайту і лише потім переключити основний.

Три сценарії для старого сайту

• Сайт загалом влаштовує, проблема лише в коді. Тоді оптимальне рішення — доопрацювання сайту під сучасну версію PHP: оновлення ядра, модулів і виправлення несумісних місць.
• Сайт застарів і зовні, і всередині. Якщо дизайн не адаптований під телефони, CMS давно не оновлюється, а виправлення коштуватимуть як половина нового сайту, розумніше зробити редизайн старого сайту на актуальній платформі.
• Сайт давно не приносить користі. Буває, що старий сайт ніхто не відвідує, а він висить на хостингу й лише створює ризики. Тоді його варто або вимкнути, або замінити простим новим сайтом.

У будь-якому разі залишати сайт на PHP 5.6 чи 7.3 після цієї новини — означає свідомо тримати відчинені двері. Зламаний сайт може розсилати спам, показувати відвідувачам шкідливий код, потрапити в чорні списки браузерів і втратити позиції в Google.

Як перевірити, чи сайт не зламали

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

• Нові або змінені PHP-файли. Файли, змінені після 20 жовтня, яких ви не чіпали, особливо в папках завантажень.
• Нові користувачі. Невідомі адміністратори чи редактори в CMS.
• Завдання за розкладом (cron). Незнайомі завдання на сервері або в планувальнику CMS.
• Дивна поведінка сайту. Перенаправлення відвідувачів на сторонні сайти, особливо лише з мобільних або лише з Google.
• Google Search Console. Розділ «Проблеми безпеки» і раптові нові сторінки в індексі, яких ви не створювали.
• Пошта хостингу. Скарги на спам або повідомлення хостера про підвищене навантаження.

Якщо знайшли хоча б одну ознаку, не обмежуйтеся видаленням підозрілого файлу. Найнадійніше — відновити сайт із чистої резервної копії, зробленої до 20 жовтня, оновити PHP і CMS, змінити всі паролі (адмінка, FTP, база даних, хостинг) і лише потім повертати свіжий контент.

Типові помилки після новин про вразливість PHP

Під час таких інцидентів власники сайтів часто роблять одні й ті самі помилки. Ось найпоширеніші з них.

• Вважати, що оновлення WordPress і плагінів закриває вразливість PHP.
• Встановити ще один плагін безпеки і на цьому заспокоїтися.
• Довіряти номеру версії і не перевіряти, чи встановлено саме виправлену збірку.
• Оновити основну версію PHP на VPS і забути про інші збірки та тестові сайти.
• Оновити PHP і не перезапустити процеси, через що старий код продовжує працювати в пам’яті.
• Вважати тимчасові налаштування повноцінним захистом.
• Перемкнути старий сайт на PHP 8.3 в панелі хостингу без тестування і отримати білий екран.
• Відкласти оновлення старого сайту, бо «нас ніхто не атакуватиме, ми маленькі».
• Не знати, хто відповідає за сервер, і чекати, що «хтось оновить».
• Не мати свіжої резервної копії сайту і бази даних.
• Видалити один підозрілий файл і вважати сайт очищеним.
• Не змінити паролі після підозри на злам.
• Забути про старі піддомени і копії сайту, які теж працюють на PHP.
• Завантажувати «перевірочні» скрипти з неперевірених джерел — під виглядом експлойтів теж поширюють шкідливий код.

Чек-лист: чи захищений ваш сайт від PHP2Shell

Пройдіться цим списком сьогодні. Якщо на якийсь пункт ви не можете відповісти «так», саме з нього варто почати.

• Я знаю, яка версія PHP працює на моєму сайті.
• Я знаю, хто відповідає за оновлення сервера: хостер, адміністратор чи підрядник.
• Хостер письмово підтвердив, що виправлення CVE-2026-109618 і CVE-2026-109619 встановлені.
• Мій сайт працює на PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 або новішій виправленій збірці.
• Якщо сайт на PHP 7.4–8.1, я маю підтвердження, що для нього встановлено латку постачальника.
• Сайт не працює на PHP 7.3 чи старішій версії.
• Налаштування session.upload_progress вимкнене або хостер підтвердив, що це зроблено.
• На VPS оновлені всі збірки PHP, а процеси перезапущені.
• Ядро CMS, тема і плагіни оновлені до актуальних версій.
• Покинуті плагіни, які давно не оновлюються, замінені або видалені.
• Є свіжа резервна копія файлів і бази даних, збережена окремо від хостингу.
• Є резервна копія, зроблена до 20 жовтня 2026 року.
• Список адміністраторів сайту перевірено, зайвих немає.
• У Google Search Console немає повідомлень про проблеми безпеки.
• Немає незрозумілих PHP-файлів, змінених після 20 жовтня.
• Старі копії та піддомени сайту вимкнені або теж оновлені.
• Паролі до адмінки, FTP, бази даних і хостингу надійні й різні.
• Заплановано перехід із PHP 8.2 до 31 грудня 2026 року, якщо сайт зараз на цій версії.

Часті питання

Чи стосується вразливість PHP мого сайту на WordPress?

Так, якщо сервер, на якому працює сайт, використовує невиправлену версію PHP. WordPress написаний на PHP, тому залежить від неї так само, як OpenCart, Drupal чи самописні сайти. Захищеність визначає версія PHP на сервері, а не версія WordPress.

Чи допоможе плагін безпеки, наприклад Wordfence?

Ні, як основний захист — не допоможе. За даними команди PHP, атака може спрацювати ще до того, як почне виконуватися код WordPress і його плагінів. Плагіни безпеки корисні для інших загроз, але тут потрібне оновлення PHP на сервері.

Як швидко потрібно оновитися?

Якнайшвидше. Команда PHP рекомендує оновитися негайно, а за повідомленнями провайдерів, перші спроби атак з’явилися вже в день виходу виправлень. Кожен день на невиправленій версії — додатковий ризик.

Мій сайт на PHP 7.4. Чи можна його захистити без переробки?

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

Чи можна самому перемкнути версію PHP у панелі хостингу?

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

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

Тривожні ознаки — невідомі адміністратори, нові PHP-файли, перенаправлення відвідувачів на сторонні сайти, повідомлення в Google Search Console про проблеми безпеки, скарги на спам. Якщо щось із цього є, відновіть сайт із чистої резервної копії, оновіть PHP і змініть усі паролі.

Хто має оновлювати PHP: я чи хостер?

На звичайному віртуальному хостингу — хостер. На VPS чи власному сервері — власник сервера або його адміністратор. Якщо сайт обслуговує підрядник, це має бути прописано в домовленостях.

Безпека сайту — це процес, а не разова дія

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

Якщо ваш сайт працює на актуальному PHP і хостер підтвердив оновлення, достатньо пройти чек-лист вище й перевірити резервні копії. Якщо ж сайт старий, на PHP 7.x чи 5.6, або ви взагалі не знаєте, хто за ним стежить, саме час це змінити. Можна передати сайт на постійне ведення сайту з контролем оновлень або оновити його так, щоб він працював на сучасній платформі.

Webatom розробляє і підтримує сайти на WordPress, Drupal, CodeIgniter та Yii з 2010 року. Якщо потрібна допомога з перевіркою, оновленням чи переходом на нову версію PHP, звертайтеся — а якщо старий сайт простіше замінити, ми пропонуємо створення сайтів під ключ на актуальних технологіях.