Передача по HTTP/2 может завершиться, пока соединение, по которому шли данные, ещё открыто. Именно между завершением передачи и закрытием соединения возникла ошибка, о которой проект curl сообщил 14 октября 2026 года. Уязвимости присвоили номер CVE-2026-92392 и уровень серьёзности High.

Это разбор материалов проекта curl, а не независимое рецензируемое исследование и не эксперимент на выборке программ. Технический сценарий описал сопровождающий curl Даниэль Стенберг. В уведомлении проекта перечислены затронутые версии и условия, при которых ошибка может привести к выполнению кода. Полный отчёт на HackerOne и упомянутый Стенбергом образ Docker для воспроизведения в доступных материалах отсутствуют. Поэтому независимо проверить методику здесь нельзя.

Когда передача закончилась, а ссылка осталась

libcurl, библиотека, на которой работает в том числе командная утилита curl, использует для отдельной передачи объект Curl_easy. Для параллельных передач есть управляющий объект multi. HTTP/2 позволяет вести несколько логических передач по одному соединению, поэтому время жизни передачи и самого соединения не всегда совпадает.

По описанию Стенберга, ошибка возникает, когда программа отправляет данные серверу по HTTP/2. Сервер приостанавливает отправку, возвращает часть ответа и сбрасывает поток сообщением RST_STREAM с одной из определённых причин. Передача завершается с ошибкой, но соединение остаётся открытым. В этот момент libcurl ошибочно сохраняет ссылку на объект передачи. Приложение освобождает объект, а позднее, при очистке управляющего объекта, библиотека всё ещё обращается к этой ссылке.

Так возникает ошибка use-after-free, или «использование после освобождения»: программа обращается к памяти через указатель, хотя эта память уже освобождена. Если сервер может повлиять на данные, попадающие в освободившуюся область, программа может повести себя непредсказуемо. Стенберг описывает и более опасный сценарий: данные сервера могут оказаться на месте прежнего объекта и затронуть указатель на функцию, что потенциально позволяет удалённо выполнить код. Это описание возможного механизма, а не утверждение, что любой запрос к уязвимой версии автоматически запускает код.

Почему условий так много

Чтобы попытаться провести атаку, приложение должно само отправлять данные по HTTP/2 на сервер, контролируемый злоумышленником. Сертификат TLS у этого сервера должен быть действительным. По оценке Стенберга, важен и объём отправляемых данных: примерно 135 КБ. Кроме того, злоумышленнику нужно знать архитектуру curl и подготовить подходящую полезную нагрузку.

Уведомление curl перечисляет и другие условия: атакующему нужно знать версию curl и структуру объекта, учитывать архитектуру, совместимый распределитель памяти libc и раскладку кучи, а также особенности работы nghttp2 и OpenSSL с TLS 1.3. На результат могут повлиять корневые сертификаты, параллельные передачи и их расписание. По словам Стенберга, область для полезной нагрузки составляет около 23 байт.

Ошибка создаёт опасную возможность, но для её эксплуатации нужно заранее подстроиться под множество особенностей конкретной сборки и приложения. Эти особенности различаются в разных дистрибутивах Linux, версиях libc и программах, использующих libcurl. По словам Стенберга, если попытка не попадёт в нужные условия, наиболее вероятным исходом станет аварийное завершение программы.

Разработчики присвоили уязвимости уровень High, но оценили вероятность успешного выполнения кода как небольшую. Противоречия здесь нет: уровень серьёзности отражает возможный ущерб при успешной атаке, а оценка вероятности учитывает, насколько трудно её провести. «Небольшой шанс» является оценкой команды curl, а не статистикой реальных атак. В опубликованных материалах нет данных о частоте попыток или измеренной вероятности успеха.

Что исправили и чего это не доказывает

Уязвимы версии curl с 8.12.0 по 8.22.0 включительно. Исправление вошло в выпуск 8.23.0; проект также перечисляет исправленные версии отдельных веток 8.20.x, 8.16.x и 8.14.x. curl рекомендует обновить программу или библиотеку, применить патч либо отказаться от HTTP/2.

В исправлении изменили порядок очистки. Фильтры соединения теперь получают уведомление о завершении передачи и необходимости отпустить ссылки на объект до того, как соединение будет отсоединено. В другом связанном изменении удалили события присоединения и отсоединения объекта передачи. Для HTTP/2 завершение обрабатывается событием DATA_DONE. Коммиты показывают, что именно изменили в коде, но сами по себе не подтверждают оценку вероятности успешной атаки.

Уведомление проекта указывает, что проблему обнаружила и сообщила Luna Tong из Anthropic с помощью нового сканера открытого исходного кода; Стенберг предполагает, что в нём задействованы модели искусственного интеллекта. Подробнее о возможностях и ограничениях подобных инструментов можно прочитать в материале о применении ИИ для поиска и анализа источников. Сам факт автоматического обнаружения не заменяет проверки конкретной ошибки и исправления разработчиками.

Пользователям достаточно начать с проверки версии curl или libcurl и обновить её до исправленного выпуска, если установлена уязвимая версия. Технический разбор объясняет, чем опасна ошибка, но доступные источники не позволяют считать слова «успешная атака маловероятна» гарантией безопасности конкретного приложения.

Источники

Концептуальная схема описанного curl сценария: сброс HTTP/2-потока оставляет ссылку на освобождённый объект; дальнейшее развитие до выполнения кода требует дополнительных условий.

Фото: Mikhail Nilov / Pexels