Проект PHP выпустил исправления для двух критических уязвимостей, которые позволяют удалённо выполнить код без аутентификации. Они получили идентификаторы CVE-2026-109618 и CVE-2026-109619, обе оценены в 9,2 балла по шкале CVSS v4.0. Патчи вышли 21 октября.
Какие версии затронуты и где риск выше
Исправления включены в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Под угрозой все установки, обрабатывающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Самым уязвимым вариантом названа связка с mod_php. Для неё показан эксплойт, который срабатывает по одному неаутентифицированному запросу ещё до запуска кода приложения.
Для версий PHP 8.1 и более ранних официальных бинарных обновлений нет: эти ветки достигли конца жизненного цикла (EOL). Для 7.4, 8.0 и 8.1 доступны только минимальные бэкпорты исходного кода. Поддержка PHP 8.2 закончится 31 декабря 2026 года.
Как устроены уязвимости
Первая брешь, CVE-2026-109618, связана с обработкой нехватки памяти (OOM). Если процесс прерывается из-за этого, внутренние данные запроса могут остаться в частично инициализированном состоянии. Затем процедура очистки воспринимает их как корректные и работает с ними. Полное удалённое выполнение кода по HTTP подтверждено на mod_php с настройками по умолчанию.
Вторая, CVE-2026-109619, касается «застрявшего» глобального состояния. Данные одного запроса могут пережить освобождение памяти, и следующий запрос на том же воркере (рабочем процессе сервера) их использует. Подтверждены сценарии через session.upload_progress и fatal_error_backtraces на PHP 8.5.
Что можно сделать до обновления
Полностью проблему закрывает только переход на исправленные версии с последующим перезапуском воркеров PHP-FPM. Временные меры защиту не гарантируют, но снижают риск:
отключить session.upload_progress.enabled = 0 в php.ini или в настройках пула FPM (через ini_set() и .user.ini параметр не сработает) и перезапустить воркеры;
на PHP 8.5 дополнительно задать fatal_error_backtraces = 0;
выставить memory_limit = -1 на административном уровне, а не через пользовательские настройки;
ограничить post_max_size (например, 8M без загрузок файлов или 32M с ними) и задать upload_max_filesize ниже этого значения, а также установить лимиты на прокси.
Реакция криптоиндустрии
Уязвимости затрагивают крипторынок: на PHP работает немало бэкендов бирж и кошельков. Компания SlowMist в соцсети X опубликовала предупреждение: её система MistEye выполнила глобальное сканирование PHP-активов в криптоиндустрии. Биржам, DeFi-платформам и провайдерам кошельков рекомендовано оценить риски и установить патчи.
Две уязвимости с оценкой 9,2 в CVSS v4.0 затрагивают все основные способы запуска PHP, а наибольшую опасность представляет mod_php. Патчи доступны для веток 8.2–8.5, для более старых версий есть только исходные бэкпорты.
Раннее появление идентификаторов CVE в открытом доступе сократило окно для подготовки, хотя функциональных эксплойтов на момент релиза не фиксировали. Для платформ, работающих с пользовательскими средствами, скорость установки обновлений определяет, насколько быстро будет закрыта брешь.
Мнение ИИ
С точки зрения машинного анализа данных, главный интерес здесь представляет не сам PHP, а слой «между пользователем и ключом». Свежий пример — взлом Bitget в сентябре: GoPlus заключила, что приватные ключи не утекали. Злоумышленники скомпрометировали критическую бэкенд-систему и заставили штатный процесс подписания выдать валидные подписи. Система подписания, по этой версии, подтверждает то, что передаёт бэкенд, и содержание транзакции не проверяет. Сейф с ключами надёжен ровно настолько, насколько честен тот, кто вручает ему поручения. Для биржи брешь в веб-слое — потенциальная дверь в кабинет, где такие поручения рождаются. Способ первоначального проникновения в Bitget при этом до сих пор не раскрыт, а связь этого случая с PHP никто не заявлял. Какая часть биржевых систем проверяет не только подпись, но и смысл операции?
▼
Самые интересные и важные новости на нашем канале в Telegram