Оновлення безпеки PHP 2026: як закрити вразливість PHP2Shell CVSS 9.2

Сам процес розкриття був незвичним. 20 жовтня команда безпеки PHP опублікувала попереднє повідомлення, призначила випуск на 21 жовтня о 14:00 UTC і залишила за собою право відвантажити його раніше. Ідентифікатори CVE витекли за день до розкриття — разом із завищеними заявами щодо критичності та переліку постраждалих версій. Постачальники дистрибутивів отримали патчі для своїх збірок завчасно, а національні CERT почали публікувати рекомендації ще до того, як код став загальнодоступним. Іншими словами: щойно реліз вийшов, ніхто не мав жодного виправдання зволікати.

Дві вразливості, один аварійний реліз

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

CVE-2026-109618 — RCE через пошкодження даних під час вичерпання пам’яті. Коли пам’ять PHP вичерпується, він перериває запит, а не продовжує роботу. У бюлетені описано сценарій, у якому таке переривання зупиняє PHP у момент, коли внутрішні дані запиту ще ініціалізовані лише частково, і наступний крок прибирання запиту згодом сприймає недійсні дані як дійсні. Зловмисник, здатний довести споживання пам’яті до межі, може впливати на те, що відбувається далі. Саме ця вразливість робить пораду щодо тимчасового захисту такою контрінтуїтивною: розробник радить адміністраторам не давати PHP досягати власної стелі пам’яті, а не підтягувати її.

CVE-2026-109619 — RCE через застарілий глобальний стан. Внутрішній стан, що належить одному запиту, може пережити звільнення пам’яті, у якій він містився. Наступний запит, оброблений тим самим робочим процесом, може використати цей застарілий стан до того, як звичайна ініціалізація його скине. Для довгоживучого робочого процесу — а саме такими є PHP-FPM, mod_php і LiteSpeed — повторне використання пам’яті є нормальним і постійним станом, тож це не рідкісний випадок, що трапляється хіба в екзотичних конфігураціях.

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

Хто насправді під загрозою

Бюлетень без обиняків: під загрозою перебувають усі інсталяції PHP, які обслуговують веб-запити. Це стосується PHP-FPM за nginx або Apache, Apache з mod_php, php-cgi, LiteSpeed і FrankenPHP. Різниця між ними лише в тому, скільки зусиль знадобиться зловмиснику.

Якщо для своєї торгової компанії ви хостите WordPress, WooCommerce, Laravel, Magento, ERP-системи в екосистемі Magento чи будь-який PHP-портал бронювання, ви потрапляєте в перші три рядки таблиці, навіть коли код застосунку бездоганний. Про те, хто взагалі має опікуватися середовищем виконання, докладніше розповідає наш матеріал про ІТ-аутсорсинг у Туреччині.

Перевірте свою версію за дві хвилини

Пастка тут — арифметика версій. Дистрибутиви роками постачають PHP 8.3.6 або 8.2.x і переносять виправлення безпеки в той самий видимий номер версії, тож сам по собі php -v не відповість, чи ви захищені. Порівняйте три речі.

1. Видима версія PHP і SAPI, що обслуговує трафік.

2. Версія пакунка з дистрибутива, а не від проєкту PHP. У Debian і Ubuntu чесну відповідь дає журнал змін; у RPM-системах запитайте журнал змін пакунка.

Якщо журнал змін у встановленій версії згадує обидві CVE, ви захищені, хоча php -v і далі показує 8.3.6. У цьому різниця між справжньою відповіддю на питання безпеки і забобоном про номери версій.

3. Чи запущений зараз процес уже працює з виправленим бінарним файлом. Оновлення пакунка, за яким так і не стався перезапуск, лишає старий код у пам’яті. Порівняйте час запуску служби з часом встановлення пакунка:

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

Виправлені версії та обрив підтримки

PHP підтримує кожну гілку два роки активної розробки й ще два роки виправлень безпеки. Саме ця політика дала чотири одночасні випуски 21 жовтня — і саме вона лишає старіші гілки сам-на-сам із проблемами.

Два практичні застереження з бюлетеня. По-перше, якщо ви ставите PHP зі стороннього репозиторію спільноти, а не з пакунків свого дистрибутива, такий репозиторій може не встигнути за вікном безпеки: супровідники широко вживаних пакунків Remi заявили, що оновлень у день виходу не буде, тож безпечний шлях — пакунки вашого дистрибутива або власне збирання з вихідних кодів. По-друге, якщо ви на PHP 8.1 або старішій версії, «почекаємо на нашого хостера» — це рішення в сфері безпеки, яке ви приймаєте за своїх клієнтів: або задокументуйте його, або змініть.

Як поставити патч на робочий сервер без інциденту

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

1. Спочатку знімок. Знімок гіпервізора чи тому, відновлення з якого ви справді перевіряли, повертає систему за хвилини — і робить рішення поставити патч дешевим.
2. Відтворіть версію в тестовому середовищі. Та сама гілка, ті самі розширення, ті самі конфігураційні файли PHP, копія робочих даних. Прогоніть шлях оформлення замовлення, запиту пропозиції й оплати, а не лише головну сторінку.
3. Оновлюйте набір пакунків як єдине ціле. Поєднання оновленого CLI зі старим бінарним файлом FPM — типовий спосіб отримати виправлений php -v і невиправлений веб-шлях: apt-get update && apt-get install --only-upgrade 'php8.3-*' або dnf update --security 'php*' на RPM-хостах.
4. Перезапустіть процес, який обслуговує запити, а тоді перевірте, що він перезапустився. systemctl restart php8.3-fpm (або перезавантажте Apache / перезапустіть LiteSpeed), потім знову перевірте час запуску служби та повторіть запити щодо версії й журналу змін.
5. Годину стежте за журналом помилок. Повідомлення OOM, нові сигнатури фатальних помилок і незвична частка 5xx — це сигнали, що налаштування тимчасового захисту, описані нижче, можливо, потребують доопрацювання, а не підстави відкладати оновлення.
6. Зафіксуйте докази. Версія пакунка, рядок журналу змін з обома CVE, час перезапуску. Клієнти, аудитори та перевірки засобів контролю в дусі ISO 27001 просять саме це — а на його збереження йде десять секунд.

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

Тимчасові заходи: звузьте вікно, але не закривайте його

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

Проти CVE-2026-109618 (шлях вичерпання пам’яті)

• Дозвольте PHP вичерпувати пам’ять машини замість власного ліміту: memory_limit = -1, в ідеалі як php_admin_value memory_limit = -1, щоб код застосунку не міг повернути стелю на місце.
• Тримайте тіла запитів невеликими на рівні інтерпретатора: бюлетень радить орієнтовно 8 МБ, якщо завантажень файлів немає, і орієнтовно 32 МБ, якщо вони є, причому upload_max_filesize — меншим за post_max_size.
• Дорогі з погляду ресурсів обмеження ставте на проксі, бо руйнівна дія ховається в декодованому запиті, а не в розмірі пакетів на лінії: сумарний розмір декодованого тіла, кількість полів введення, кількість частин multipart, кількість заголовків, глибина вкладеності — і прикрийте також запити, що надходять без придатного Content-Length.
• Обмежуйте масштаб ураження лімітом пам’яті контейнера чи cgroup, підібраним так, щоб убитий робочий процес був подією доступності, а не подією для всього хоста. Не підставляйте натомість RLIMIT_AS або RLIMIT_DATA: вони провокують ту саму помилку виділення пам’яті, що лежить у вразливому шляху.

Проти CVE-2026-109619 (шлях застарілого стану)

• Вимкніть відстеження прогресу завантаження сесій значенням session.upload_progress.enabled = 0, прописаним у php.ini, пулі FPM чи конфігурації сервера — там, де воно застосується до розбору запиту. Потім перезапустіть усі робочі процеси, адже FPM передає вже ініціалізований стан модулів між запитами. ini_set() і .user.ini встигнути допомогти вже не можуть.
• На PHP 8.5 встановіть fatal_error_backtraces = 0 і перезапустіть процеси.
• Приберіть налаштування рівня запиту, які є некоректними або застарілими і саме тому видають діагностику під час ранньої ініціалізації. Придушення повідомлення через error_reporting, display_errors або @ кодовий шлях не прибирає.
• Шукайте доступні зловмиснику фатальні помилки та довгі тайм-аути в обробниках завантаження й імпорту, коді зворотних викликів і процедурах прибирання — у тих самих місцях, де живуть обидві вразливості.

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

Що сьогодні запитати у свого хостинг-провайдера

Скрипти служби підтримки відповідають на це запитання фразою «у нас усе завжди виправлено». Просіть натомість докази, які можна підшити в справу:

• Вбудована версія PHP, призначена нашому акаунту, і чи це пакунок дистрибутива, чи збірка постачальника
• Дата, коли виправлення CVE-2026-109618 і CVE-2026-109619 дійшли до вашого парку серверів, разом із внутрішнім рядком версії пакунка
• Чи застосоване виправлення до SAPI, що обслуговує наш сайт (FPM, LiteSpeed, mod_php), і до будь-якого тестового чи резервного вузла, з якого нам може знадобитися відновлення
• Якщо платформу ще не виправлено: який компенсуючий захід діє і до якого строку
• Ваша постійна політика щодо гілок без підтримки — що станеться з моїм сайтом 1 січня 2027 року, коли припиниться підтримка безпеки PHP 8.2

Провайдер, який відповідає на ці п’ять запитань одним листом, заслуговує на те, щоб лишитися вашим провайдером. Той, хто у відповідь надсилає маркетинговий текст, — це вже привід для розмови про міграцію; тут потрібна та сама ретельність, що й у нашому gap-аналізі ISO 27001, де результатом є докази, а не запевнення.

Чи варто вважати, що вас уже зламали?

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

• Шукайте процеси, порти-слухачі й записи cron, які ви не створювали, а також вихідні з’єднання від користувача робочого процесу PHP.
• Порівняйте каталоги застосунку, доступні для запису, з еталонним джерелом розгортання: нові PHP-файли, змінені каталоги завантажень, несподівано виконувані тимчасові папки.
• Перегляньте веб-журнали: шукайте шторми запитів у години розкриття, незвично великі тіла multipart або запити, що повернули 500 із сигнатурами OOM у журналі помилок PHP.
• Перевірте, що запущений саме виправлений бінарний файл — на це відповідає наведене вище порівняння часу перезапуску.
• Якщо щось виглядає не так, дійте, як у випадку інциденту: збережіть диск і журнали, замініть усі облікові дані, які може прочитати застосунок, і перезберіть систему з перевіреного справного образу. Перевстановлення пакунка PHP поверх зламаного хоста не є усуненням наслідків.

Практичний приклад із нашої власної інфраструктури

Ми обслуговуємо worldwidetradex.com на Ubuntu 24.04 LTS із nginx і PHP-FPM, тож 22 жовтня пропустили ці перевірки через самих себе. Результати добре ілюструють, чому арифметика версій має значення:

Цей урок переноситься на будь-який стек: ваш рівень безпеки — це версія пакунка плюс журнал змін плюс перезапуск, а не маркетинговий рядок версії в панелі хостингу.

Зробіть патчування буденністю, а не подвигом

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

• Автоматичні оновлення безпеки інтерпретатора без участі людини, з автоматичним записом версії та факту перезапуску
• Інвентаризація, яка знає, який SAPI і яку гілку PHP використовує кожен сайт, включно з тестовими середовищами, резервними копіями та тим одним WordPress із 2019 року
• Відпрацьований шлях відновлення, щоб «патчити зараз» ніколи не доводилося зважувати проти «ми не можемо відкотитися»
• План щодо гілок: жодного сайту на релізі PHP, підтримку безпеки якого завершать протягом наступних дванадцяти місяців
• Один конкретний відповідальний на кожен сервер і письмовий маршрут ескалації на дні, коли патч виходить о 14:00 UTC у середу

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

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

Джерела

• PHP — бюлетень безпеки «Critical remote code execution vulnerabilities, update now» й анонси релізів від 21 жовтня 2026 року, включно з настановами щодо тимчасового захисту та терміном підтримки на сторінці supported versions.
• Рекомендації GitHub Security Advisories для репозиторія PHP: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) і GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — бюлетень безпеки 2026-018 «Critical Vulnerabilities in PHP», у якому названо обидві CVE.
• Infosecurity Magazine — «Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches» (21 жовтня 2026) і «PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure» (22 жовтня 2026).

Потрібно, щоб оновлення хтось узяв на себе? Щоб обговорити патчування, аудит версій, міграцію на керовану та виправлену PHP-платформу або інфраструктуру довкола неї, зв’яжіться з нами або зателефонуйте за номером +90 505 679 78 03.