Дякуємо!
Ми зв'яжемося з вами найближчим часом
PHP2Shell:Дві критичні вразливості PHP та заходи реагування на них
Оприлюднені дослідження: 21–22 жовтня 2026 року
PHP2Shell:Дві критичні вразливості PHP та заходи реагування на них
Оприлюднені дослідження: 21–22 жовтня 2026 року
Що таке PHP2Shell?
Термін PHP2Shell стосується двох нещодавно виявлених вразливостей безпеки пам'яті в ядрі виконання PHP.
Ці слабкі місця були розкриті в результаті скоординованого дослідження за участю Wiz Research та команди безпеки PHP. Зокрема, Google відзначив роль штучного інтелекту у виявленні вразливостей та перевірці патчів під час дослідницького процесу.
Обидві проблеми пов'язані з небезпечною обробкою внутрішньої пам'яті та станів PHP під час обробки вебзапитів. За певних умов зловмисник може маніпулювати тим, як PHP обробляє запит, що потенційно призводить до пошкодження пам'яті, витоку інформації або виконання несанкціонованого коду.
Важливою відмінністю є те, що для цих вразливостей не потрібна наявність вразливої функції в самому PHP-додатку. Поверхня атаки охоплює середовище виконання запитів, що робить усунення вразливостей на рівні інфраструктури особливо важливим.
Команда безпеки PHP вважає конфігурації Apache з використанням mod_php такими, що несуть найбільший продемонстрований ризик, хоча інші середовища PHP також вимагають термінової уваги.
CVE-2026-109618: Віддалене виконання коду через пошкодження пам'яті при її нестачі
CVE-2026-109618 — це критична вразливість пошкодження пам'яті, пов'язана з обробкою ситуацій нестачі пам'яті в PHP.
Коли PHP стикається з помилкою виділення пам'яті, виконання може зупинитися в момент, тоді як певні внутрішні структури запиту ініціалізовані лише частково. Під час подальшого очищення середовище виконання може помилково інтерпретувати невалідні внутрішні дані як легітимні, створюючи умову для пошкодження пам'яті, якою можна скористатися.
Чому це важливо?
Вичерпання пам'яті не обов'язково обмежується незвичними робочими навантаженнями. Вебдодатки регулярно обробляють запити, дані форм, завантаження та інші вхідні дані, які можуть впливати на споживання ресурсів.
Зловмисник, здатний спрямувати виконання у вразливий шлях, що призводить до збою, може спровокувати небезпечну поведінку під час очищення пам’яті. Успішна експлуатація може призвести до віддаленого виконання коду з правами вразливого процесу PHP.
Як мінімізувати ризики CVE-2026-109618
Рекомендованим рішенням є встановлення виправленої версії PHP.
Якщо негайне оновлення неможливе, офіційні рекомендації PHP описують тимчасові заходи, які можуть зменшити ризики для конкретних векторів атак:
● Налаштування memory_limit = -1 на відповідному адміністративному рівні для усунення шляху збою, пов’язаного з налаштовуваним обмеженням пам’яті PHP, усвідомлюючи при цьому, що базові помилки виділення пам'яті залишаються можливими. ● Обмеження розмірів запитів і завантажень на рівнях PHP, вебсервера або проксі. ● Використання обмежень контейнерів або cgroups як меж ресурсів та доступності. ● Перевірка того, що специфічні для додатків перевизначення не підривають призначені запобіжні заходи.
Ці заходи мають бути протестовані перед розгортанням, оскільки вони можуть вплинути на поведінку додатків та споживання ресурсів.
Ресурс спільноти Vicarius: скрипт для усунення вразливості CVE-2026-109618 PHP2Shell
Перегляньте скрипт, переконайтеся, що його припущення відповідають вашому середовищу, та перевірте його дію перед запуском у робочому середовищі. Тимчасове зниження ризиків не означає повного усунення вразливості.
CVE-2026-109619: Віддалене виконання коду через застарілий глобальний стан
CVE-2026-109619 пов'язана з окремою слабкістю управління пам'яттю в середовищі виконання PHP.
Ця вразливість виникає тоді, коли внутрішній стан, що належить попередньому запиту, залишається доступним після того, як пам'ять, яка його підтримувала, була звільнена. Наступний запит, оброблений тим самим робочим процесом PHP, може зіштовхнутись із цим застарілим станом до того, як нормальна послідовність ініціалізації відновить його.
Це створює умову Use-After-Free («використання звільненої пам'яті»), що потенційно може призвести до пошкодження пам'яті та віддаленого виконання коду.
Чому постійні робочі процеси PHP підвищують важливість виявлення вразливостей?
Розгортання PHP часто використовують робочі процеси для обслуговування кількох запитів. Повторне використання процесу покращує продуктивність, але водночас робить критично важливою правильну ізоляцію між запитами.
Якщо внутрішній стан зберігається довше за призначений життєвий цикл, наступний запит може зіткнутися з даними, яких уже не повинно існувати. Це одна з причин, чому виявлення вразливостей не може обмежуватися лише перевіркою вихідного коду додатків — командам також потрібна видимість реальних версій середовища виконання PHP та конфігурацій розгортання.
Як реагувати на CVE-2026-109619
PHP рекомендує оновлення до виправленої версії.
Для середовищ, які не можуть оновитися негайно, офіційні рекомендації визначають конфігураційні заходи, що блокують певні підтверджені шляхи:
● Встановіть session.upload_progress.enabled = 0 на рівні конфігурації, що застосовується до синтаксичного аналізу запитів. ● Перезапустіть вразливі воркери PHP після зміни цього параметра. ● На PHP 8.5 встановіть fatal_error_backtraces = 0 та перезапустіть робочі процеси, щоб заблокувати підтверджений шлях фатального трасування.
Сприймайте ці заходи лише як тимчасове зниження ризиків, а не як комплексний захист. Оскільки інші варіанти експлуатації можуть залишатися можливими, успішні зміни конфігурації не можуть вважатися доказом безпеки вразливого середовища виконання PHP.
Ресурс спільноти Vicarius: скрипт виявлення CVE-2026-109619 PHP2Shell
Використовуйте результати виявлення для ідентифікації потенційно вразливих систем, пріоритизації розслідувань та планування виправлень. Негативний результат скрипта не слід розцінювати як остаточний доказ неможливості експлуатації або відсутності компрометації.
Які версії PHP вразливі?
Ці повідомлення стосуються версій PHP, починаючи з PHP 5.4, включаючи старі версії, що більше не підтримуються, та гілки, які раніше були актуальними.
21 жовтня 2026 року PHP випустив такі виправлені версії:
Гілка PHP
Перша виправлена версія
Гілка PHP
Гілка PHP
Перша виправлена версія
Перша виправлена версія
PHP 8.5
8.5.12
Гілка PHP
PHP 8.5
Перша виправлена версія
8.5.12
PHP 8.4
8.4.27
Гілка PHP
PHP 8.4
Перша виправлена версія
8.4.27
PHP 8.3
8.3.36
Гілка PHP
PHP 8.3
Перша виправлена версія
8.3.36
PHP 8.2
8.2.35
Гілка PHP
PHP 8.2
Перша виправлена версія
8.2.35
PHP 8.1 і старші
Відсутні стандартні виправлення безпеки вищого рівня; оновіться або отримайте перевірені виправлення від вендора
Гілка PHP
PHP 8.1 і старші
Перша виправлена версія
Відсутні стандартні виправлення безпеки вищого рівня; оновіться або отримайте перевірені виправлення від вендора
Які системи піддаються ризику PHP2Shell?
Офіційне попередження з безпеки PHP визначає кілька середовищ виконання, які потребують уваги:
● Розгортання Apache HTTP Server з використанням mod_php ● Середовища PHP-FPM за Nginx або Apache ● Розгортання на базі php-cgi ● Додатки на основі FrankenPHP ● Розгортання LiteSpeed PHP ● Контейнеризовані та хмарні сервіси PHP
Наявність PHP не означає автоматично, що кожне розгортання можна експлуатувати однаково. Фактичний ризик залежить від версій середовища виконання, моделі виконання, конфігурації, обробки запитів та інших технічних умов.
Проте сама вразливість існує нижче рівня додатків. Добре підтримуваний додаток усе одно може бути вразливим, якщо його базове середовище виконання PHP не захищене. Тому організаціям слід переглянути інвентаризацію інфраструктури та середовищ виконання, а не покладатися лише на сканування уразливостей додатків.
Практичний алгоритм усунення вразливостей PHP2Shell
Реагування на критичні вразливості вимагає більшого, ніж просто ідентифікації CVE у сканері. Команди з безпеки та інфраструктури повинні перетворити інформацію про вразливості на безпечні зміни у своїх середовищах, а потім підтвердити їх успішне застосування.
Крок 1: Ідентифікувати кожне середовище виконання PHP
Складіть перелік інсталяцій PHP на фізичних серверах, віртуальних машинах, контейнерах, образах додатків та керованих сервісах. Перевірте виробничі, тестові та розробницькі середовища, доступні з невідомих мереж, а також системи, які можуть використовувати окремий бінарний файл або середовище виконання PHP, відмінне від того, що відображається в інтерфейсі командного рядка.
Наприклад, корисним початковим кроком є команда:
php -v
Це визначає версію бінарного файлу PHP CLI, що викликається, але не обов'язково ідентифікує версію, яка використовується вебсервером або робочими процесами PHP-FPM. Повне виявлення має охоплювати середовища виконання, які реально обробляють запити.
Крок 2: Пріоритизувати вебдодатки, що взаємодіють з інтернетом
Почніть із систем, які обробляють ненадійні вебзапити, особливо конфігурацій, визначених рекомендаціями PHP як такі, що несуть найбільший ризик. Пріоритизація має враховувати:
● Доступність сервісу з інтернету; ● Встановлену версію PHP та статус виправлень від постачальника; ● Модель розгортання та підтверджені вектори атак; ● Доступ додатка до чутливих даних або підключених систем; ● Наявні засоби контролю безпеки та варіанти зниження ризиків.
Уникайте використання лише оцінки CVSS для визначення черговості виправлень. Дві системи, зачеплені однією вразливістю, можуть мати різний операційний та бізнес-ризик.
Крок 3: Запустити відповідні перевірки
Команди безпеки можуть використовувати інвентаризацію, перевірки конфігурацій, мапу бюлетенів вендорів та спеціальні скрипти виявлення. Ознайомтеся зі скриптом виявлення застарілого глобального стану PHP від Vicarius для CVE-2026-109619 перед його використанням.
Крок 4: Застосувати оновлення безпеки або тимчасові заходи
Пріоритетною дією є встановлення відповідного виправленого релізу PHP або перевіреного інтегрованого оновлення безпеки від вендора. Де виправлення вимагає додаткового тестування, можна оцінити вузькоспеціалізовані тимчасові засоби контролю.
Щодо CVE-2026-109618, ознайомтеся зі скриптом Vicarius PHP2Shell для мінімізації ризиків разом з офіційним повідомленням PHP.
Крок 5: Перевірити результати усунення вразливості
Завершене оновлення програмного забезпечення автоматично не доводить, що працюючий додаток захищений. Після розгортання оновлення переконайтеся, що:
● Встановлене середовище виконання має відповідний виправлений білд або бекпорт. ● PHP-процеси, що взаємодіють із вебсервісами, використовують оновлене середовище виконання. ● Контейнери або сервіси додатків були перезапущені там, де це необхідно. ● Функціональність та доступність додатків залишаються незмінними.
Перевірки більше не виявляють відповідне середовище виконання без виправлення.
Висновок
Вразливості CVE-2026-109618 та CVE-2026-109619 є важливим нагадуванням про те, що критична незахищеність додатка може виникати безпосередньо в самому середовищі виконання мови програмування, а не лише в коді додатка.
Для команд безпеки пріоритет є чітким: ідентифікувати вразливі розгортання PHP, встановити офіційні оновлення безпеки, використовувати тимчасові засоби захисту лише за необхідності та переконатися, що у виробничому середовищі працюють оновлені версії.
Досліджуйте скрипти Vicarius для PHP2Shell на платформі vSociety для підтримки розслідування та планування усунення вразливостей або запросіть демоверсію Vicarius, щоб дізнатися більше про автоматизацію та операційне управління усуненням вразливостей у вашому середовищі.
FAQ
1. Що таке PHP2Shell?
Це загальна назва для CVE-2026-109618 та CVE-2026-109619 — двох критичних вразливостей безпеки пам'яті в PHP, виявлених 21 жовтня 2026 року, які можуть призвести до неавтентифікованого віддаленого виконання коду.
2. Яка серйозність вразливостей PHP2Shell?
Обидві CVE мають критичну оцінку CVSS v4.0 на рівні 9.2. Ризик їх експлуатації залежить від версії середовища виконання, конфігурації та оточення.
3. Чи можна експлуатувати PHP2Shell без автентифікації?
Так, команда безпеки PHP підтвердила ризик неавтентифікованого RCE із продемонстрованим вектором атаки до виконання коду додатку в конфігураціях mod_php.
4. Які версії PHP усувають ці вразливості?
Виправлені висхідні версії: PHP 8.5.12, 8.4.27, 8.3.36 та 8.2.35. Користувачі дистрибутивів мають перевіряти наявність бекпортів від своїх вендорів.
5. Чи можна повністю усунути PHP2Shell без оновлення коду/версії?
Ні. PHP прямо попереджає, що тимчасові мітигації вирішують лише окремі вектори атак. Встановлення виправленої версії є єдиним безпечним вирішенням.
6. Чи зачеплені сайти на WordPress або інших CMS?
Будь-який додаток на базі PHP може вимагати перевірки, якщо він використовує вразливе середовище виконання PHP. Оновлення самої CMS або додатка не обов'язково оновлює системний PHP.
Готові скоротити розрив між виявленням ризику та його усуненням? Запитуйте демоверсію та оцініть vRx у дії.
Вам може бути цікаво: