Опубликованы детали предполагаемой уязвимости в обработке загрузок PHP

21 октября 2026 года автор публикации «Major PHP Vulnerability Leaked» на своём сайте сообщил о предполагаемой серьёзной уязвимости в PHP. По его разбору, обработчик прогресса загрузки файлов может обратиться к уже освобождённой памяти, а описанная цепочка — дойти до вызова system(). Автор выложил материалы для проверки и предложил временные меры до официального уведомления. Подтверждения от команды PHP в предоставленном тексте нет.

Где автор видит ошибку

Речь о session.upload_progress — механизме отслеживания загрузки файла через сессию. Его обработчик сохраняет два указателя на значения в таблицах PHP: один относится к обработанным данным запроса, другой — к текущему файлу. При дальнейшей обработке прежняя структура данных может быть уничтожена, а указатели останутся. Так возникает описанный сценарий use-after-free: код обращается к памяти, которая уже освобождена.

По утверждению автора, для этого пути достаточно стандартных настроек session.upload_progress. Он описывает быстрый multipart POST-запрос, при обработке которого очередное обновление перечитывает данные сессии и удаляет прежнюю структуру. Затем освободившаяся область памяти, согласно разбору, может быть занята данными, позволяющими довести выполнение до zend_call_function и вызова system(). Это изложение заявленной технической цепочки, а не подтверждение того, что она сработает на любом сайте.

Автор пишет, что сверил детали с исходным кодом PHP 8.4.4 и 8.2.34. В опубликованном наборе есть материалы для проверки и воспроизведения, а также данные о различиях между отдельными сборками. Для команд, которые поддерживают сайты, ключевое различие сейчас другое: публикация содержит технический разбор, но не сообщение о готовом официальном исправлении.

Что известно о границах риска

Помимо пути через session.upload_progress, автор упоминает второй возможный путь — через обработчик multipart-запросов. По его оценке, изменение настройки прогресса загрузки может закрыть один путь, но не обязательно другой: обработка multipart/form-data не зависит от включения этого механизма. Поэтому считать одну настройку полным решением по этому материалу нельзя.

Дата выхода официального исправления в публикации не указана. Автор обещает вернуться к своей версии причины ошибки после официального уведомления. Версии 8.5.11, 8.4.26, 8.3.35 и 8.2.34 он перечисляет как текущие стабильные, а не как выпуски с исправлением описанной проблемы. Для PHP 7.x и более старых версий, по его словам, исправления не будет: их пользователям он советует планировать обновление.

Неопределённость здесь существенна. Автор заявляет о проверке деталей на конкретных версиях и приводит данные по отдельным сборкам, но вопрос официальной оценки оставляет открытым. Из публикации нельзя заключить, что каждый сайт на PHP уязвим или что какая-то из перечисленных стабильных версий уже защищена. Пока это повод подготовиться к официальным рекомендациям, а не объявлять проблему закрытой.

Что делать владельцам сайтов и командам

Первый шаг из публикации — составить список серверов с PHP и проверить установленные версии. Для управляемого хостинга автор советует уточнить у провайдера сроки установки исправления после его выхода. Такой список поможет не выяснять в последний момент, какие проекты требуют внимания и кто отвечает за обновление.

В качестве временной меры автор предлагает изменить настройку, связанную с прогрессом загрузки. Но в предоставленном фрагменте после упоминания php.ini, .user.ini и .htaccess сама команда или нужное значение отсутствуют. По этому фрагменту воспроизвести предложенное изменение нельзя. К тому же автор считает его защитой лишь от одного из двух возможных путей. Выдавать эту меру за готовую инструкцию было бы неточно.

Другое предложение — ограничить multipart POST-запросы через WAF или обратный прокси на адресах, которым не нужна загрузка файлов. Команде придётся различать такие адреса и страницы, где загрузка действительно требуется. После выхода официального исправления автор рекомендует установить его без задержки. Пока его нет, полезно определить, кто проверяет версии PHP, кто управляет ограничениями запросов и кто согласует изменения на страницах с формами.

Моё мнение

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

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

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. Major PHP Vulnerability Leaked jackalsyn.com

Об авторе

Отто Ильвес

начинающий frontend-разработчик

Собираю учебные интерфейсы и недавно подключил первый простой API. Хочу понять, как команды выбирают инструменты не по хайпу, а по тому, что им предстоит поддерживать.

Все публикации автора