curl 8.23.0: уязвимость HTTP/2 высокой важности, кого касается

14 октября 2026 года вышел curl 8.23.0 с исправлением уязвимости CVE-2026-92392 высокой важности. Ошибка связана с загрузкой данных по HTTP/2. curl — это не только утилита командной строки, но и библиотека libcurl, встроенная во множество программ, поэтому проверить стоит не только сам curl.

Что произошло

CVE-2026-92392 — use-after-free при загрузке данных на сервер по HTTP/2. Это первая уязвимость высокой важности в curl с октября 2023 года. По словам разработчиков, для выполнения кода нужно совпадение множества условий, и наиболее вероятный исход атаки — падение программы, а не захват. Атак в реальной среде источники не сообщали.

Нашёл уязвимость исследователь через программу поиска ошибок, сообщив о ней 15 сентября. 7 октября curl заранее объявил о выпуске.

Кого касается

libcurl встроен в огромное число программ: скрипты развёртывания, системы мониторинга, интеграции, которые ходят на внешние серверы. Уязвимость срабатывает при загрузке данных по HTTP/2 на сервер, который контролирует атакующий, — то есть при обращении к недоверенному адресу.

Прямой угрозы для обычного сайта тут меньше, чем для сервисов, которые по расписанию ходят на внешние API и загружают туда данные. Но обновить стоит везде: и утилиту, и библиотеку.

Что делать

1. Узнайте версию: `curl --version`. Для libcurl внутри программ — через их зависимости.
2. Обновите curl и libcurl через менеджер пакетов системы.
3. Если используете curl в Docker-образах, обновите базовый образ и пересоберите.
4. Если обновиться сразу нельзя, разработчики советуют не использовать HTTP/2: флаг `--http1.1` или соответствующая настройка в коде. Сборка libcurl без поддержки HTTP/2 к уязвимости не обращается.
5. Проверьте, нет ли в проекте старых закреплённых версий curl в зависимостях.

Наше мнение

curl — пример «невидимой» зависимости: он есть почти везде, но про него не думают. Мы советуем включить его в общий регламент обновлений системы и проверять версии в Docker-образах, где curl часто остаётся старым годами. Для разработчиков полезное правило: фиксировать версии зависимостей и обновлять их осознанно, а не только когда что-то сломалось.

Отдельно про условие атаки: уязвимость опасна при обращении к серверу, который контролирует злоумышленник. Это ещё один аргумент не ходить из боевых скриптов на непроверенные адреса и ограничивать, куда ваши сервисы могут подключаться.

Ограничение исходящих соединений полезно не только против этой уязвимости. Если сервис может подключаться только к известному списку адресов, то даже при заражённой зависимости или скомпрометированном коде вывести данные наружу или скачать вредоносную нагрузку будет гораздо труднее.

Как это связано с другими обновлениями

14 октября выдалось насыщенным на обновления: в тот же день вышли исправления NGINX и Next.js. Это совпадение, но оно показывает ритм: критические и высокие уязвимости в базовых компонентах выходят постоянно. Разумная реакция — не ловить каждую новость, а построить процесс, в котором обновления приходят регулярно и ставятся без аврала.

Почему «невидимые» зависимости опасны

curl, OpenSSL, zlib и подобные библиотеки объединяет одно: их почти никогда не устанавливают сознательно. Они приезжают вместе с системой, образом контейнера или другим пакетом. Поэтому про них забывают, и именно они чаще всего остаются устаревшими.

Хорошая практика — периодически составлять список того, что реально установлено на серверах и в образах, а не только того, что вы ставили руками. Инструменты анализа состава (SBOM) делают это автоматически и показывают, где прячется старая версия curl или OpenSSL. Для небольшого проекта достаточно простого правила: обновлять базовые образы контейнеров не реже раза в месяц и не держать образы, собранные год назад.

Что проверить разработчику

Если вы пишете код, который использует libcurl или аналог, стоит пройтись по нескольким вопросам. Куда ваш код может подключаться — только к доверенным адресам или к любым, которые придут извне? Зафиксированы ли версии зависимостей? Обновляются ли они по расписанию? Ответы на эти вопросы закрывают не только эту уязвимость, но и целый класс проблем с внешними соединениями.

Как это касается заказчика

Если вы не администрируете сервер сами, достаточно задать подрядчику один вопрос: как у вас обновляются системные библиотеки и образы контейнеров. Внятный ответ про регулярные обновления и фиксацию версий — хороший знак. Если же ответ сводится к «обновляем, когда что-то ломается», стоит обсудить регламент: именно забытые базовые компоненты чаще всего оказываются слабым звеном.