В curl исправили ошибку CVE-2026-92392: при определённом сценарии HTTP/2 сервер мог повредить память программы, которая загружает ему файл. Исследовательница Luna Tong из Anthropic показала, как превратить эту ошибку в выполнение кода на компьютере клиента. Исправление вошло в curl 8.23.0, выпущенный 14 октября.
Уязвимость типа use-after-free затрагивала curl и библиотеку libcurl версий с 8.12.0 по 8.22.0. Ошибка присутствовала во всех выпусках начиная с 8.12.0, вышедшего в феврале 2025 года. Она распространялась как на командную утилиту curl, так и на libcurl, которую используют другие программы.
curl присвоил проблеме высокий уровень серьёзности по собственной четырёхступенчатой шкале. Это первая уязвимость curl с такой оценкой после переполнения кучи в SOCKS5, обнаруженного в октябре 2023 года. Проект не публикует оценку CVSS; по состоянию на 14 октября Национальная база уязвимостей США ещё не проанализировала запись. В сообщениях об уязвимости не приводилось сведений о реальных атаках. Выпуск 8.23.0 закрывает всего 24 CVE, но остальные 23 получили низкую оценку.
Для атаки сервер должен был контролироваться злоумышленником, а клиенту требовалось загружать ему файл размером примерно 135 КБ по HTTP/2. Клиент также должен был считать сертификат сервера действительным и использовать сборку libcurl с поддержкой HTTP/2. Для URL с
Механизм сбоя описал ведущий разработчик curl Даниэль Стенберг (Daniel Stenberg). HTTP/2 позволяет вести несколько передач по одному соединению, а libcurl отслеживает каждую с помощью объекта easy handle. Сервер злоумышленника мог приостановить загрузку, установив нулевое окно передачи, отправить часть ответа, а затем сбросить поток, не закрывая соединение. curl воспринимал сброс как повод повторить передачу.
Ошибка возникала при очистке: curl сообщал HTTP/2-слою, что передача завершена, прежде чем тот успевал сбросить в соединение остаток данных загрузки. Оставшиеся байты обрабатывались уже без привязки к передаче и выглядели как новая команда запроса. Tong подготовила файл с последовательностью строк, похожих на строки запроса. Они открывали новый поток, который сохранял указатель на easy handle.
Затем повторная попытка завершалась через новое соединение HTTP/1.1, а приложение освобождало handle. Старое HTTP/2-соединение всё ещё хранило указатель на него. Когда сервер отправлял кадр по старому потоку, в том числе при завершении программы, использовался уже недействительный указатель. Данные сервера попадали в память освобождённого объекта; исходящий запрос помогал раскрыть локальные адреса и обойти рандомизацию адресного пространства ASLR. После этого злоумышленник мог перезаписать указатель на функцию, которую вызывал curl.
Практическое выполнение кода требовало точного знания версии curl, архитектуры, аллокатора libc и расположения объектов в куче. Нужно было синхронизировать две параллельные передачи и уместить полезную нагрузку примерно в 23 байта. Стенберг оценил вероятность успеха как небольшую: наиболее вероятным результатом попытки, по его словам, был бы «скорее просто сбой». Этим объясняется оценка High, а не Critical.
Сообщение поступило в curl через HackerOne 15 сентября; команда безопасности подтвердила его в течение нескольких часов. 7 октября проект заранее объявил о серьёзном исправлении и сократил цикл выпуска с восьми до шести недель. 14 октября вышли curl 8.23.0 и публичный отчёт Tong с кодом вредоносного сервера и Docker-контейнером, который, согласно описанию, воспроизводил выполнение кода.
Исправление подготовил Стефан Айссинг (Stefan Eissing): в
Если обновление пока невозможно, curl советует избегать HTTP/2. В командной строке можно указать
Anthropic открыла OSS Scanner 8 октября как сервис для проектов с открытым исходным кодом, подключившихся по желанию. Сканер анализирует их с помощью моделей и отправляет результаты без проверки человеком; к отчёту прилагаются воспроизводящий пример и, если возможно, кандидат на исправление. Сообщение о curl поступило за три недели до публичного запуска сервиса. В анонсе Anthropic процитировала Стенберга: сканер нашёл «одну из худших уязвимостей curl за последние несколько лет», не называя её. В июле 2025 года тот же разработчик писал, что около одной пятой сообщений о проблемах безопасности curl за год были, по его выражению, «ИИ-мусором», а подлинным оказалось примерно каждое двадцатое.
Стенберг также рассказывал, что curl уже несколько лет старается сокращать число внутренних указателей на handle и вместо них использовать идентификаторы, по которым объект можно найти при необходимости. Это не гарантирует защиты от новых ошибок use-after-free. В проекте считают, что язык с безопасным управлением памятью, вероятно, помог бы избежать подобной ошибки, но переписывать curl на такой язык не планируют.
Изображение носит иллюстративный характер
Уязвимость типа use-after-free затрагивала curl и библиотеку libcurl версий с 8.12.0 по 8.22.0. Ошибка присутствовала во всех выпусках начиная с 8.12.0, вышедшего в феврале 2025 года. Она распространялась как на командную утилиту curl, так и на libcurl, которую используют другие программы.
curl присвоил проблеме высокий уровень серьёзности по собственной четырёхступенчатой шкале. Это первая уязвимость curl с такой оценкой после переполнения кучи в SOCKS5, обнаруженного в октябре 2023 года. Проект не публикует оценку CVSS; по состоянию на 14 октября Национальная база уязвимостей США ещё не проанализировала запись. В сообщениях об уязвимости не приводилось сведений о реальных атаках. Выпуск 8.23.0 закрывает всего 24 CVE, но остальные 23 получили низкую оценку.
Для атаки сервер должен был контролироваться злоумышленником, а клиенту требовалось загружать ему файл размером примерно 135 КБ по HTTP/2. Клиент также должен был считать сертификат сервера действительным и использовать сборку libcurl с поддержкой HTTP/2. Для URL с
https:// libcurl по умолчанию согласует HTTP/2, если сервер предлагает этот протокол. Сборки без поддержки HTTP/2 уязвимому пути недоступны. Механизм сбоя описал ведущий разработчик curl Даниэль Стенберг (Daniel Stenberg). HTTP/2 позволяет вести несколько передач по одному соединению, а libcurl отслеживает каждую с помощью объекта easy handle. Сервер злоумышленника мог приостановить загрузку, установив нулевое окно передачи, отправить часть ответа, а затем сбросить поток, не закрывая соединение. curl воспринимал сброс как повод повторить передачу.
Ошибка возникала при очистке: curl сообщал HTTP/2-слою, что передача завершена, прежде чем тот успевал сбросить в соединение остаток данных загрузки. Оставшиеся байты обрабатывались уже без привязки к передаче и выглядели как новая команда запроса. Tong подготовила файл с последовательностью строк, похожих на строки запроса. Они открывали новый поток, который сохранял указатель на easy handle.
Затем повторная попытка завершалась через новое соединение HTTP/1.1, а приложение освобождало handle. Старое HTTP/2-соединение всё ещё хранило указатель на него. Когда сервер отправлял кадр по старому потоку, в том числе при завершении программы, использовался уже недействительный указатель. Данные сервера попадали в память освобождённого объекта; исходящий запрос помогал раскрыть локальные адреса и обойти рандомизацию адресного пространства ASLR. После этого злоумышленник мог перезаписать указатель на функцию, которую вызывал curl.
Практическое выполнение кода требовало точного знания версии curl, архитектуры, аллокатора libc и расположения объектов в куче. Нужно было синхронизировать две параллельные передачи и уместить полезную нагрузку примерно в 23 байта. Стенберг оценил вероятность успеха как небольшую: наиболее вероятным результатом попытки, по его словам, был бы «скорее просто сбой». Этим объясняется оценка High, а не Critical.
Сообщение поступило в curl через HackerOne 15 сентября; команда безопасности подтвердила его в течение нескольких часов. 7 октября проект заранее объявил о серьёзном исправлении и сократил цикл выпуска с восьми до шести недель. 14 октября вышли curl 8.23.0 и публичный отчёт Tong с кодом вредоносного сервера и Docker-контейнером, который, согласно описанию, воспроизводил выполнение кода.
Исправление подготовил Стефан Айссинг (Stefan Eissing): в
lib/multi.c переставили местами шесть строк. Теперь HTTP/2-слой отказывается от ссылок на handle после того, как остаток данных загрузки сброшен в соединение. Помимо 8.23.0, проект указывает исправленные ветки: 8.14.3 для серии 8.14.x, 8.16.2 для 8.16.x и 8.20.2 для 8.20.x. В Debian 13 (trixie) проблему закрывает пакет 8.14.1-2+deb13u7 по бюллетеню DSA-6558-1; Debian 12 (bookworm) уязвимый код не содержит. Обновления Rock-solid curl, линии долгосрочной поддержки для клиентов с контрактами, должны были выйти одновременно с 8.23.0. Если обновление пока невозможно, curl советует избегать HTTP/2. В командной строке можно указать
--http1.1, а в приложении установить CURLOPT_HTTP_VERSION в CURL_HTTP_VERSION_1_1. Документация называет это запросом: уже открытое соединение, использующее другой протокол, может быть переиспользовано. Находку curl приписал «Luna с Claude, Anthropic». Стенберг назвал исследовательницу Luna Tong и связал сообщение с новым сервисом Anthropic OSS Scanner, предположив участие моделей компании. Anthropic открыла OSS Scanner 8 октября как сервис для проектов с открытым исходным кодом, подключившихся по желанию. Сканер анализирует их с помощью моделей и отправляет результаты без проверки человеком; к отчёту прилагаются воспроизводящий пример и, если возможно, кандидат на исправление. Сообщение о curl поступило за три недели до публичного запуска сервиса. В анонсе Anthropic процитировала Стенберга: сканер нашёл «одну из худших уязвимостей curl за последние несколько лет», не называя её. В июле 2025 года тот же разработчик писал, что около одной пятой сообщений о проблемах безопасности curl за год были, по его выражению, «ИИ-мусором», а подлинным оказалось примерно каждое двадцатое.
Стенберг также рассказывал, что curl уже несколько лет старается сокращать число внутренних указателей на handle и вместо них использовать идентификаторы, по которым объект можно найти при необходимости. Это не гарантирует защиты от новых ошибок use-after-free. В проекте считают, что язык с безопасным управлением памятью, вероятно, помог бы избежать подобной ошибки, но переписывать curl на такой язык не планируют.
