24 уязвимости в curl открывают путь к выполнению кода через HTTP/2

В библиотеке curl, через которую программы и серверы обмениваются сетевыми данными, нашлись 24 уязвимости. Исправления собрали в версии 8.23.0, она вышла 14 октября 2026 года. Высокую степень опасности получила только одна, CVE-2026-92392. При загрузке файлов по HTTP/2 (второй версии протокола HTTP) сервер подталкивает curl к работе с освобождённой памятью, а это открывает путь к выполнению чужого кода. Остальные 23 уязвимости curl относит к низкой степени опасности. Последствия у них скромнее, но перечень внушительный: пароли уходят на сторону прокси, билет Kerberos (временный пропуск системы единого входа) попадает на чужой сервер, файлы cookie исчезают вместе с записями других доменов.

Обзор уязвимостей curl и исправление в версии 8.23.0

Выполнение кода при загрузке по HTTP/2

CVE-2026-92392 затрагивает загрузку данных по HTTP/2. Когда curl отправляет файл, сервер волен прервать поток служебным сообщением. Такой отказ библиотека обрабатывает неаккуратно и возвращается к уже освобождённому объекту передачи. Ошибки этого класса называют использованием памяти после освобождения: программа читает и меняет данные, которых в этом месте уже нет. В худшем сценарии злоумышленник получает выполнение своего кода на устройстве. Уязвимы версии с 8.12.0 по 8.22.0.

Сработать это может лишь при совпадении многих условий. Нужны точная версия curl, разрядность системы, раскладка памяти, поведение библиотек шифрования и согласованный тайминг двух параллельных передач. Готовая команда укладывается примерно в 23 байта. Порог входа высокий, и без точного совпадения всех параметров код не выполнится.

Учётные данные уходят на чужой сервер

Старейшая из проблем носит номер CVE-2026-86414 и живёт в curl с версии 7.10.8. Прокси, через который идёт соединение, может ответить на запрос туннеля не тем кодом, который ждёт библиотека. В итоге он получает пароль от целевого сайта. Обычно прокси видит лишь адрес запроса, так что доверие к нему здесь оказывается лишним.

Похожим образом утекает билет Kerberos при аутентификации Negotiate. Отвечая перенаправлением с логином и паролем в адресе, сервер заставляет curl отправить свежий пропуск третьей стороне. Три отдельные уязвимости описывают разные варианты этой схемы, в том числе переиспользование уже открытого соединения с чужими правами.

Другая ошибка касается подписи запросов AWS SigV4 (схема подтверждения прав в облаке Amazon). Приложение сбрасывает настройку подписи и ждёт, что следующий запрос уйдёт без заголовка авторизации. Заголовок сохраняется и раскрывает идентификатор ключа доступа, правда, без секретного ключа. В сходном случае пароль из файла .netrc попадает в адрес страницы, который библиотека возвращает приложению.

Есть и ошибки, зависящие от сборки. Вариант с библиотекой libssh2 теряет проверку ключа узла, и уже проверенный сервер выглядит как новый: curl отправляет ему пароль SSH. Сборка с GnuTLS позволяет серверу WebSocket вытянуть лишние байты за границей буфера и отдать их наружу, чаще это заканчивается аварийным завершением. TFTP-сервер (TFTP - упрощённый протокол передачи файлов) переключает клиент в режим отправки, и тот высылает остатки данных предыдущего запроса, например тело POST-запроса.

Соединения и проверка сертификатов

Часть уязвимостей растёт из переиспользования соединений. Привязка к сетевому интерфейсу не входит в ключ поиска соединения, поэтому запрос, которому нужен другой источник, уйдёт со старого адреса. Клиентский сертификат ведёт себя похоже: FTP-передача без шифрования занимает канал, который ранее прошёл проверку и авторизовался сертификатом. На Windows сборки с Schannel (системный механизм TLS) отдают перенаправленному запросу уже аутентифицированное соединение, хотя код явно это запрещал.

Две уязвимости касаются проверки узла. Если разрешить перенаправления на SFTP или SCP, curl пропустит проверку ключа SSH-хоста. Сборка с wolfSSL принимает неверно собранный сертификат и подтверждает закреплённый открытый ключ, который серверу не принадлежит.

Потеря данных и зависания

Cookie-файлы страдают дважды. Сервер выставляет cookie, который curl записывает, но затем не может прочитать из-за ограничения на длину строки. В одном случае чтение прерывается и часть записей игнорируется, в другом очистка заменяет файл пустым и стирает cookie чужих доменов. Сбои есть и у механизма HSTS (принудительный переход на HTTPS): дочерняя запись теряется при импорте, а слишком долгий срок жизни ломает сохранение и оставляет пустой кэш. Тогда curl идёт по незашифрованному HTTP.

Ключ -J, который мешает серверу перезаписать существующий файл, теряет защиту, если перед основным ответом приходит промежуточный. FTP, IMAP, POP3 и SMTP-серверы могут не прислать финальную строку ответа и подвесить передачу вопреки таймауту, а вместе с ней встанут и другие задачи в том же процессе.

Две уязвимости приводят к аварийному завершению. Повторное использование дескриптора запроса (объекта, через который приложение управляет передачей) после неудачного FTP-листинга по шаблону портит состояние и роняет программу. Слишком глубоко вложенная структура MIME-сообщения переполняет стек при очистке. Преобразование переводов строк в письме IMAP путает счётчик длины, и лишние байты сервер принимает за команды в уже авторизованной сессии.

Исправление и что делать

Все 24 уязвимости закрыты в curl 8.23.0. Для тех, кто остался на старых ветках, выпустили точечные исправления: 8.20.2, 8.16.2 и 8.14.3. Обновление до 8.23.0 снимает весь список проблем сразу.

Если обновиться в один момент нельзя, помогает отказ от отдельных возможностей: не задействовать HTTP/2 при отправке данных; не ходить через HTTP-прокси; не разрешать перенаправления на SFTP и SCP; не переиспользовать дескрипторы для TFTP и для FTP-листингов по шаблону; не полагаться на HSTS и cookie-файлы. Обновляться придётся и там, где curl не установлен отдельно: библиотека libcurl входит в состав многих приложений, а в списках компонентов указывается не всегда.

Проблема с прокси живёт в коде с версии 7.10.8, то есть захватывает много лет выпусков. Оценивать такой список по числу пунктов смысла нет. Большинство уязвимостей срабатывает лишь в редких конфигурациях, а основная угроза сосредоточена в единичных случаях вроде ошибки HTTP/2, где дело доходит до выполнения кода.