У ядрі PHP виправили вразливості, що дають змогу віддалено виконувати код

21 жовтня 2026 року команда PHP випустила оновлення, яке виправляє кілька вразливостей, пов’язаних із безпекою пам’яті в ядрі мови. Як пише Wiz Research, дослідники продемонстрували віддалене виконання коду без авторизації та читання пам’яті PHP-процесу. Власникам сайтів варто перевірити, яка версія PHP обслуговує їхній сайт, і встановити оновлення безпеки: проблема криється в самому PHP, а не лише в застосунках, написаних на ньому.

Що виявили в PHP

Дослідники об’єднали помилки під номерами CVE-2026-109618 і CVE-2026-109619. Найвища оцінка критичності сягає 9,2 за шкалою CVSS. За даними Wiz, кожна версія PHP, випущена за останнє десятиліття, уразлива щонайменше до однієї із цих проблем; серед уражених є версії починаючи з PHP 5.4. Це не означає, що той самий сценарій спрацює на будь-якому сайті: ланцюжок атаки залежить від версії, конфігурації та поведінки застосунку.

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

Wiz перевірила свій сценарій php2shell на WordPress, Drupal і Joomla, використавши їхні контейнерні образи, актуальні на момент тестування. Продемонстровані атаки не потребували авторизації. CMS тут слугують прикладами: уразливий код міститься в PHP, тому, як зазначають дослідники, під загрозою може опинитися навіть простий застосунок на вразливій версії мови.

Окремо команда показала читання пам’яті процесу без виконання коду. Там можуть міститися паролі, токени й API-ключі, зокрема дані поза межами запиту зловмисника. Тому оцінювати ризик лише за можливістю виконати код на сервері не можна.

Чому ланцюжки атак стали практично здійсненними

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

Для пошуку помилок, розробки атак, їх виявлення та перевірки виправлення команда застосовувала моделі ШІ. Wiz повідомляє, що за їхньою допомогою змогла створювати й адаптувати робочі сценарії для різних застосунків за лічені години. Це опис результатів дослідження, а не обіцянка, що атака автоматично спрацює проти кожного сервера.

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

Що перевірити власникам сайтів і розробникам

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

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

Ризик охоплює виконання коду на сервері та читання чутливих даних із пам’яті процесу. Тому, навіть якщо код самого сайту не містить відомих помилок, важливо перевірити компонент, на якому він працює. Для команди, що відповідає за сайт, це окреме завдання від оновлення застосунку та його доповнень.

Моя думка: оновлювати потрібно основу, а не лише сайт

Мені як бэкенд-розробнику-початківцю ця історія чітко показує межі відповідальності застосунку. Можна ретельно написати API, але виправленням власного коду не усунути помилку, що виникає всередині PHP під час обробки запиту. Я б почав із простих запитань: де в проєкті запущено PHP, хто його оновлює і чи зрозуміло, коли виправлення потрапить на робочий сервер.

Ще мене зачепила роль ШІ в дослідженні. На мою думку, головний висновок не в самому застосуванні моделей, а в тому, що складність побудови ланцюжка атак уже не виглядає надійним бар’єром. Це вагомий привід уважніше ставитися до оновлень базових компонентів, навіть коли вся увага команди зосереджена на функціях сайту.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. PHP2Shell: AI uncovers critical RCE in PHP www.wiz.io

Про автора

Бекжан Халелов

бекенд-розробник-початківець

Створюю перші API й пробую зв’язати їх із фронтендом у навчальних проєктах. Зараз тестую кешування на каталозі товарів — на коректне оновлення даних несподівано пішло багато часу.

Усі публікації автора