Разработчики curl выпустили обновление 8.21.0 и закрыли сразу 18 уязвимостей. Для проекта с такой репутацией это заметный релиз: четыре проблемы получили среднюю оценку опасности, остальные — низкую.

Самый неприятный сюрприз — CVE-2026-8932. Ошибка жила в коде больше 25 лет, еще со времен curl 7.7, и затрагивала версии до 8.20.0 включительно.

Что именно сломалось

Проблема сидела в libcurl — библиотеке, которую разработчики встраивают в приложения для работы с сетевыми запросами. Баг был связан с повторным использованием mTLS-соединений, то есть соединений, где клиент подтверждает себя сертификатом и приватным ключом.

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

Иными словами, запрос выполнялся как будто от имени прежнего клиента. Это особенно неприятно для корпоративных систем, где разные учетные данные могут использоваться внутри одного и того же процесса.

Почему это важно не только для разработчиков

Сама консольная утилита curl под удар не попала. Риск касается приложений, которые встроили libcurl в свой код и используют mTLS или похожую схему доступа.

Такие ошибки редко заметны на глаз. Пользователь видит лишь то, что сервис работает, а внутри запросы могут пройти не с теми параметрами, на которые рассчитывала система. Поэтому обновления библиотек безопасности важны не меньше, чем патчи для самой ОС.

Если вам нужен разбор похожих ошибок в цепочке поставки и зависимостях, посмотрите как ловят уязвимости в зависимостях до релиза и почему мелкая логическая ошибка ломает корпоративную защиту.

Какие варианты защиты есть у команд

Первый путь — быстро обновиться до 8.21.0. Это самый простой и правильный шаг, если вы используете curl или libcurl в продуктиве. Плюс очевиден: закрываете накопившийся пакет проблем сразу. Минус тоже понятен — обновление надо проверить в своей сборке и прогнать тесты.

Второй путь — пересмотреть работу с mTLS и соединениями в пуле. Подходит тем, кто пишет собственные сервисы поверх libcurl. Такой подход помогает поймать не только эту ошибку, но и похожие логические сбои. Цена — больше времени на аудит и анализ кода.

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

Для обычного пользователя такой новости достаточно, чтобы понять простую вещь: уязвимость может годами сидеть не в «громкой» части продукта, а в старой логике переиспользования соединений.

Кому что делать прямо сейчас

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

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

Что сделать сейчас

  • Проверить, используется ли в проекте curl или libcurl.
  • Уточнить версию и наличие обновления до 8.21.0.
  • Посмотреть, есть ли в коде mTLS и повторное использование соединений.
  • Прогнать тесты после обновления зависимости.
  • Проверить журналы на странные совпадения сертификатов и ключей.
  • Для рабочих устройств заранее держать в порядке менеджер паролей, 2FA и средство для безопасной работы вне офиса.
  • Обновить внутреннюю памятку для команды, если curl встроен в продукт.
Поделиться: