PHP2Shell: чому критичні вразливості PHP вимагають регулярного оновлення серверів
Сайт може працювати без видимих помилок і водночас використовувати серверне програмне забезпечення з критичною вразливістю. Саме тому оновлення інфраструктури не варто відкладати до появи збоїв.
21 жовтня 2026 року команда PHP випустила термінові виправлення двох критичних вразливостей, відомих під назвою PHP2Shell. PHP — це програмне середовище, у якому виконується код багатьох сайтів і вебзастосунків, зокрема WordPress.
Цей випадок показує, чому поряд з оновленням CMS потрібне регулярне обслуговування сервера: облік версій, резервні копії, перевірка сумісності та контроль результату.
Що сталося 21 жовтня 2026 року
Вразливості CVE-2026-109618 і CVE-2026-109619 отримали критичну оцінку CVSS v4.0 9.2 із 10. Вони можуть дозволити віддалене виконання коду без авторизації.
Для підтримуваних стабільних гілок PHP виправлення вийшли в таких релізах:
Гілка PHP
Реліз із виправленнями від 21 жовтня
PHP 8.2
8.2.35
PHP 8.3
8.3.36
PHP 8.4
8.4.27
PHP 8.5
8.5.12
Це релізи, які містять виправлення двох зазначених CVE, а не універсальна рекомендація залишатися саме на цих версіях надалі. Під час оновлення потрібно перевіряти актуальні пакети та рекомендації для своєї платформи.
Окремо 23 жовтня команда PHP повідомила про рідкісний додатковий сценарій CVE-2026-115560, пов’язаний із певним поєднанням налаштувань і роботи застосунку. Для відповідних конфігурацій опубліковано рекомендації. Це ще одна причина перевіряти актуальні повідомлення постачальника, а не лише номер встановленої версії.
Віддалене виконання коду означає, що за успішної атаки зловмисник може змусити сервер виконувати сторонній код. Подальші наслідки залежать від прав процесу PHP, налаштувань сервера та доступних йому даних.
Перша проблема пов’язана з некоректною обробкою внутрішніх даних PHP під час вичерпання пам’яті. Друга — зі збереженням внутрішнього стану після звільнення пам’яті та його подальшим використанням. Обидві помилки розташовані на рівні самого PHP.
Можливість успішної атаки залежить від версії PHP, способу його роботи та особливостей застосунку. Це не означає, що кожний сервер можна зламати одним універсальним запитом. Водночас команда PHP підтвердила продемонстровану атаку на Apache з модулем PHP, тому складність експлуатації не є підставою відкладати оновлення.
Практичне завдання для власника інфраструктури — з’ясувати, чи встановлено виправлення на його серверах, і організувати необхідні роботи.
Чому оновлення сайту не замінює оновлення PHP
CMS, її модулі та PHP — різні компоненти системи. Оновлення WordPress або іншої платформи змінює код сайту, але саме по собі не встановлює новий пакет PHP на сервері.
Тому позначка «усі плагіни оновлено» не підтверджує усунення вразливості в середовищі виконання. Потрібно окремо перевірити PHP, який фактично обробляє запити до сайту.
Офіційне повідомлення PHP охоплює різні способи обробки вебзапитів, зокрема PHP-FPM і модуль Apache. Команда PHP назвала ризик найвищим для mod_php, де продемонстровано атаку до виконання коду застосунку.
Як організувати контрольоване оновлення
Критичне виправлення потребує швидкої реакції, а робоча система — уважного виконання змін. Доцільний порядок дій поєднує обидві потреби.
З’ясувати, що працює на сервері
Спочатку потрібно визначити:
які версії PHP встановлено;
яку версію використовує кожний сайт;
звідки надходять пакети й оновлення;
які служби обробляють вебзапити;
хто відповідає за встановлення виправлень.
На одному сервері можуть одночасно працювати кілька версій PHP. Версія для командного рядка може відрізнятися від тієї, що обслуговує сайт. Тому перевірка має охоплювати всі робочі сайти й відповідні служби.
Підготувати відновлення й перевірити сумісність
Перед змінами варто перевірити резервні копії даних і конфігурацій, можливість відновлення та залежності застосунку.
Оновлення в межах поточної гілки PHP й перехід на іншу гілку мають різний обсяг змін. Для старих систем особливо важливо врахувати модулі, налаштування та сумісність коду.
Перевірку потрібно організувати так, щоб вона допомагала встановити критичне виправлення, а не ставала причиною відкладати його на невизначений час.
Оновити служби та перевірити результат
Після встановлення пакетів потрібно забезпечити використання оновленого PHP робочими процесами. Залежно від конфігурації це потребує контрольованого перезапуску або перезавантаження відповідних служб.
Далі перевіряють доступність сайтів, авторизацію, форми, завантаження файлів, фонові завдання та журнали помилок. Перелік перевірок визначають за функціями конкретної системи.
Завершення встановлення пакетів — лише частина роботи. Важливо переконатися, що служби використовують виправлену збірку, а основні функції застосунків працюють після змін.
Що робити зі старими PHP і CentOS 7
Для застарілих систем потрібно одночасно розв’язувати поточну проблему безпеки та планувати перехід на підтримувану платформу.
PHP 8.1 і старіші гілки вже не отримують звичайних релізів безпеки від PHP Project. Водночас через серйозність PHP2Shell команда безпеки надала мінімальні виправлення вихідного коду для PHP 7.4, 8.0 і 8.1. Дистрибутиви та постачальники довгострокової підтримки також можуть випускати пакети з перенесеними виправленнями — backport.
Основного номера версії може бути недостатньо для перевірки: постачальник здатен перенести виправлення у свою збірку без його зміни. Потрібно перевіряти повну версію пакета та підтвердження включення потрібних CVE у документації постачальника.
Для CentOS Linux 7 є додаткова проблема: підтримка цієї операційної системи проєктом CentOS завершилася 30 червня 2024 року. Виправлення PHP закриває конкретні проблеми цього компонента, але не усуває ризики інших застарілих складових системи. Дату завершення підтримки зазначено на офіційному сайті CentOS.
Тому встановлення захисних виправлень на старій платформі потрібно розглядати разом із планом її модернізації.
Як Robot.NET виконував оновлення
Після виходу виправлень Robot.NET оперативно оновлював сервери клієнтів. Протягом перших 24 годин від моменту офіційного випуску виправлень було оновлено 95% серверів під обслуговуванням, які потребували цього оновлення.
Для робочих систем на CentOS 7 і PHP 7.4, які неможливо негайно перенести на сучасну платформу, Robot.NET підготував і перевірив робочий сценарій установлення захисних виправлень.
Цей сценарій перевірено для конкретних конфігурацій. Його наявність не повертає CentOS 7 або PHP 7.4 повноцінну підтримку та не означає універсальної сумісності з будь-яким сервером.
Регулярне обслуговування допомагає підготуватися до таких ситуацій заздалегідь: знати склад інфраструктури, її залежності та порядок перевірки після змін.
Що перевірити власнику сервера зараз
Поставте відповідальному адміністратору або постачальнику хостингу п’ять запитань:
Які версії та збірки PHP фактично використовують наші сайти?
Чи встановлено виправлення для CVE-2026-109618 і CVE-2026-109619?
Чи почали робочі служби використовувати оновлений PHP?
Чи перевірено основні функції сайтів після змін?
Чи є план переходу для систем на застарілих платформах?
Тимчасові обмеження можуть зменшити окремі ризики, але не замінюють оновлення. Саме таку межу прямо визначає команда PHP.
Якщо стан серверного програмного забезпечення невідомий або оновлення виконуються лише після збоїв, варто почати з уточнення інфраструктури та відповідальності за її підтримку.
Robot.NET працює віддалено із серверною та мережевою інфраструктурою. Опишіть вашу систему й завдання через сторінку «Обслуговування серверів і мереж», щоб обговорити потрібні роботи.
Цей сайт використовує cookie та подібні технології для зручної роботи й аналізу відвідуваності. Ви можете прийняти необов’язкові cookie або змінити свій вибір у налаштуваннях. Докладніше — у Політиці конфіденційності.
Робота, безпека сайту та збереження вашого вибору.
Google Analytics 4: статистика переглядів і взаємодії із сайтом. До вашої згоди не завантажується.
Рекламні теги й remarketing зараз не підключені.
Вибір зберігається в цьому браузері до 180 днів. Відкликання активної аналітичної згоди перезавантажить сторінку; спочатку завершіть заповнення форми.
PHP2Shell: чому критичні вразливості PHP вимагають регулярного оновлення серверів
Сайт може працювати без видимих помилок і водночас використовувати серверне програмне забезпечення з критичною вразливістю. Саме тому оновлення інфраструктури не варто відкладати до появи збоїв.
21 жовтня 2026 року команда PHP випустила термінові виправлення двох критичних вразливостей, відомих під назвою PHP2Shell. PHP — це програмне середовище, у якому виконується код багатьох сайтів і вебзастосунків, зокрема WordPress.
Цей випадок показує, чому поряд з оновленням CMS потрібне регулярне обслуговування сервера: облік версій, резервні копії, перевірка сумісності та контроль результату.
Що сталося 21 жовтня 2026 року
Вразливості CVE-2026-109618 і CVE-2026-109619 отримали критичну оцінку CVSS v4.0 9.2 із 10. Вони можуть дозволити віддалене виконання коду без авторизації.
Для підтримуваних стабільних гілок PHP виправлення вийшли в таких релізах:
Це релізи, які містять виправлення двох зазначених CVE, а не універсальна рекомендація залишатися саме на цих версіях надалі. Під час оновлення потрібно перевіряти актуальні пакети та рекомендації для своєї платформи.
Окремо 23 жовтня команда PHP повідомила про рідкісний додатковий сценарій CVE-2026-115560, пов’язаний із певним поєднанням налаштувань і роботи застосунку. Для відповідних конфігурацій опубліковано рекомендації. Це ще одна причина перевіряти актуальні повідомлення постачальника, а не лише номер встановленої версії.
Інформацію про виправлення та подальші уточнення оприлюднено в офіційних повідомленнях PHP за жовтень 2026 року.
Чим небезпечні ці вразливості
Віддалене виконання коду означає, що за успішної атаки зловмисник може змусити сервер виконувати сторонній код. Подальші наслідки залежать від прав процесу PHP, налаштувань сервера та доступних йому даних.
Перша проблема пов’язана з некоректною обробкою внутрішніх даних PHP під час вичерпання пам’яті. Друга — зі збереженням внутрішнього стану після звільнення пам’яті та його подальшим використанням. Обидві помилки розташовані на рівні самого PHP.
Можливість успішної атаки залежить від версії PHP, способу його роботи та особливостей застосунку. Це не означає, що кожний сервер можна зламати одним універсальним запитом. Водночас команда PHP підтвердила продемонстровану атаку на Apache з модулем PHP, тому складність експлуатації не є підставою відкладати оновлення.
Практичне завдання для власника інфраструктури — з’ясувати, чи встановлено виправлення на його серверах, і організувати необхідні роботи.
Чому оновлення сайту не замінює оновлення PHP
CMS, її модулі та PHP — різні компоненти системи. Оновлення WordPress або іншої платформи змінює код сайту, але саме по собі не встановлює новий пакет PHP на сервері.
Тому позначка «усі плагіни оновлено» не підтверджує усунення вразливості в середовищі виконання. Потрібно окремо перевірити PHP, який фактично обробляє запити до сайту.
Офіційне повідомлення PHP охоплює різні способи обробки вебзапитів, зокрема PHP-FPM і модуль Apache. Команда PHP назвала ризик найвищим для mod_php, де продемонстровано атаку до виконання коду застосунку.
Як організувати контрольоване оновлення
Критичне виправлення потребує швидкої реакції, а робоча система — уважного виконання змін. Доцільний порядок дій поєднує обидві потреби.
З’ясувати, що працює на сервері
Спочатку потрібно визначити:
На одному сервері можуть одночасно працювати кілька версій PHP. Версія для командного рядка може відрізнятися від тієї, що обслуговує сайт. Тому перевірка має охоплювати всі робочі сайти й відповідні служби.
Підготувати відновлення й перевірити сумісність
Перед змінами варто перевірити резервні копії даних і конфігурацій, можливість відновлення та залежності застосунку.
Оновлення в межах поточної гілки PHP й перехід на іншу гілку мають різний обсяг змін. Для старих систем особливо важливо врахувати модулі, налаштування та сумісність коду.
Перевірку потрібно організувати так, щоб вона допомагала встановити критичне виправлення, а не ставала причиною відкладати його на невизначений час.
Оновити служби та перевірити результат
Після встановлення пакетів потрібно забезпечити використання оновленого PHP робочими процесами. Залежно від конфігурації це потребує контрольованого перезапуску або перезавантаження відповідних служб.
Далі перевіряють доступність сайтів, авторизацію, форми, завантаження файлів, фонові завдання та журнали помилок. Перелік перевірок визначають за функціями конкретної системи.
Завершення встановлення пакетів — лише частина роботи. Важливо переконатися, що служби використовують виправлену збірку, а основні функції застосунків працюють після змін.
Що робити зі старими PHP і CentOS 7
Для застарілих систем потрібно одночасно розв’язувати поточну проблему безпеки та планувати перехід на підтримувану платформу.
PHP 8.1 і старіші гілки вже не отримують звичайних релізів безпеки від PHP Project. Водночас через серйозність PHP2Shell команда безпеки надала мінімальні виправлення вихідного коду для PHP 7.4, 8.0 і 8.1. Дистрибутиви та постачальники довгострокової підтримки також можуть випускати пакети з перенесеними виправленнями — backport.
Основного номера версії може бути недостатньо для перевірки: постачальник здатен перенести виправлення у свою збірку без його зміни. Потрібно перевіряти повну версію пакета та підтвердження включення потрібних CVE у документації постачальника.
Для CentOS Linux 7 є додаткова проблема: підтримка цієї операційної системи проєктом CentOS завершилася 30 червня 2024 року. Виправлення PHP закриває конкретні проблеми цього компонента, але не усуває ризики інших застарілих складових системи. Дату завершення підтримки зазначено на офіційному сайті CentOS.
Тому встановлення захисних виправлень на старій платформі потрібно розглядати разом із планом її модернізації.
Як Robot.NET виконував оновлення
Після виходу виправлень Robot.NET оперативно оновлював сервери клієнтів. Протягом перших 24 годин від моменту офіційного випуску виправлень було оновлено 95% серверів під обслуговуванням, які потребували цього оновлення.
Для робочих систем на CentOS 7 і PHP 7.4, які неможливо негайно перенести на сучасну платформу, Robot.NET підготував і перевірив робочий сценарій установлення захисних виправлень.
Цей сценарій перевірено для конкретних конфігурацій. Його наявність не повертає CentOS 7 або PHP 7.4 повноцінну підтримку та не означає універсальної сумісності з будь-яким сервером.
Регулярне обслуговування допомагає підготуватися до таких ситуацій заздалегідь: знати склад інфраструктури, її залежності та порядок перевірки після змін.
Що перевірити власнику сервера зараз
Поставте відповідальному адміністратору або постачальнику хостингу п’ять запитань:
Тимчасові обмеження можуть зменшити окремі ризики, але не замінюють оновлення. Саме таку межу прямо визначає команда PHP.
Якщо стан серверного програмного забезпечення невідомий або оновлення виконуються лише після збоїв, варто почати з уточнення інфраструктури та відповідальності за її підтримку.
Robot.NET працює віддалено із серверною та мережевою інфраструктурою. Опишіть вашу систему й завдання через сторінку «Обслуговування серверів і мереж», щоб обговорити потрібні роботи.
Інші практичні матеріали — у блозі Robot.NET.
Останні публікації
Теми