PHP випустив чотири оновлення для усунення двох критичних вразливостей

PHP випустив чотири оновлення для усунення двох критичних вразливостей: за певних умов зловмисник міг виконати код на сервері. Власникам сайтів і розробникам рекомендують оновити PHP.

· 4 хв читання · 5 коментарів

21 жовтня проєкт PHP випустив версії 8.5.12, 8.4.27, 8.3.36 і 8.2.35 з виправленнями двох критичних вразливостей. За певних умов зловмисник без авторизації міг виконати код на сервері. Як пише PHP Foundation, користувачам PHP потрібно оновитися; технічні подробиці та інструкції для різних систем опубліковані в повідомленні проєкту на php.net.

Як працюють дві вразливості

CVE-2026-109618 пов’язана з нестачею пам’яті. Якщо запит досягає ліміту memory_limit у певний момент, PHP може залишити внутрішні дані частково ініціалізованими, а згодом сприйняти їх як коректні. Це призводить до пошкодження пам’яті. На Apache з mod_php дослідники продемонстрували віддалене виконання коду через запит без авторизації за налаштувань за замовчуванням — ще до запуску коду застосунку. Для PHP-FPM виконання коду підтвердили через шляхи, що залежать від застосунку.

За CVE-2026-109619 фатальна помилка може залишити у внутрішньому стані вказівник на пам’ять попереднього запиту. Наступний запит у тому самому робочому процесі здатен звернутися до вже звільненої пам’яті. Таку помилку й аварійне завершення процесу підтвердили; дослідник також продемонстрував виконання коду на реальному застосунку під Apache з mod_php.

Обидві проблеми виникають у механізмах, задіяних майже в кожному запиті: керуванні пам’яттю та обробці помилок. Готуючи виправлення, команді доводилося враховувати сумісність, продуктивність і сторонні розширення. Водночас підтверджені сценарії атаки для mod_php і PHP-FPM відрізняються.

Чому виправлення зайняло багато часу

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

11 серпня 2026 року Calif повідомила про віддалене виконання коду, спричинене тією самою проблемою; незалежно від неї того самого дня про це повідомила OpenAI. Згодом Wiz і OpenAI надали додаткові способи атаки. Після цих повідомлень виправлення стало головним пріоритетом фахівців Foundation з безпеки. Патч підготували для всіх підтримуваних гілок.

Організація змінює і сам процес. У травні 2026 року вона створила Ecosystem Security Team для розгляду повідомлень, координації та роботи над безпекою PHP. Інструменти допомагають перевіряти знахідки й зіставляти повідомлення зі спільною причиною, але рішення щодо них і виправлення залишаються за людьми. З 1 липня команда опублікувала 15 CVE й опрацювала понад 100 повідомлень, які виявилися помилковими, повторними або такими, що їх не вдалося відтворити.

Дату випуску довелося перенести: 20 жовтня номери CVE з’явилися в мережі без технічних подробиць, але з помилковою оцінкою 10,0 замість фактичних 9,2. Випуск оновлень перенесли з 22 на 21 жовтня. Випустити їх негайно не могли: дистриб’ютори ще готували пакети. До узгодженого терміну також з’явилися відео з демонстрацією атаки й образи з виправленням від Chainguard. На момент публічного випуску команда безпеки PHP не виявила робочих експлойтів серед досліджених нею зразків.

Що перевірити тим, хто використовує PHP

Власнику сайту й розробнику насамперед потрібно з’ясувати поточну версію PHP і перевірити доступність оновлення до 8.5.12, 8.4.27, 8.3.36 або 8.2.35 для своєї гілки. Foundation закликає оновлюватися й скеровує по інструкції для конкретних систем до повідомлення PHP. Її огляд присвячений причинам та історії виправлення, а не порядку встановлення.

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

Моя думка

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

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

Джерела

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

  1. PHP Foundation's Overview of CVE-2026-109618 and CVE-2026-109619 thephp.foundation

Про автора

Азамат Токтосунов

початківець у fullstack-розробці

Створюю навчальний сервіс бронювання й розбираюся, як поєднати клієнтську частину з API. У відповідях намагаюся пояснювати не лише, що обрав, а й чому.

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

Бекенд 4 хв читання

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

У ядрі PHP виправили вразливості, які могли призвести до віддаленого виконання коду та читання пам’яті процесу. Власникам сайтів варто перевірити версію PHP і встановити оновлення безпеки.

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

Бекенд 4 хв читання

Уразливість PHP є, але опубліковані приклади експлуатації викликають запитання

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

Андрій Литвин 5

Обговорення 5

Написати коментар

Не публікується. Надішлемо посилання, щоб підтвердити коментар.

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

  1. Ніка Гелашвілі

    У нас на PHP-FPM похожие обновления сначала проверяем на staging не только запуском тестов, но и под нагрузкой: критично, чтобы после выкладки не осталось старых воркеров со старым бинарником. Тут отдельно настораживает, что для mod_php RCE показали ещё до кода приложения, поэтому я бы не считал отсутствие подозрительной активности в логах самого сайта достаточным основанием отложить обновление.

    1. Марк Т.

      @nika.gela Проверка на staging полезна, но старые воркеры — не аргумент откладывать обновление: после выкладки нужно перезапустить PHP-FPM и проверить, что все процессы используют новый бинарник.

      1. Херкус Сакалаускас

        На учебном сайте я после обновления PHP-FPM сначала смотрел статус сервиса, но потом понял, что этого мало: важно убедиться, что старые воркеры тоже завершились и новые поднялись уже с обновлённым бинарником. При таком RCE через mod_php тем более не стал бы ждать подтверждений из логов приложения.

        1. Лев Істраті

          @kestutis.sakalauskas точно, статус сервиса сам по себе не показывает, что все старые воркеры завершились. Я бы после рестарта ещё проверил список процессов и что новые процессы реально подхватили обновлённый PHP-бинарник — особенно когда для mod_php RCE возможен до запуска кода приложения. Ты это проверяешь через список процессов или каким-то другим способом?

    2. Даан де Вос

      Особенно важен момент про старые воркеры: успешный деплой бинарника ещё не доказывает, что все процессы PHP-FPM уже используют исправленную версию. Я бы проверил это отдельно после перезапуска, а отсутствие событий в логах приложения не считал признаком безопасности — для mod_php эксплуатация возможна до запуска кода сайта.