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

Редакционная иллюстрация по кибербезопасности: HTTP/2-загрузка достигает сервера, а инженеры отслеживают исправление уязвимости curl и инвентаризацию зависимостей.

Исправление вошло в curl и libcurl 8.23.0, выпущенные 14 октября 2026 года. Уязвимый диапазон — версии с 8.12.0 по 8.22.0. Это важно потому, что libcurl часто встроен в приложения, компоненты операционных систем, средства автоматизации, менеджеры пакетов, продукты безопасности и сервисы, которые никак не сообщают о наличии curl. Обновление консольного бинарного файла на рабочем месте одного администратора может оставить без исправления куда более важные копии библиотеки.

Это история о патчинге, но не о простом совете «запустите обновление везде». Сначала нужно выяснить, где curl используется для загрузок по HTTP/2, в том числе через библиотеку или статически слинкованное приложение. Затем следует решить, возможно ли временно ограничить возможности протокола, пока постоянное исправление проходит через пакеты поставщиков и производственные окна изменений. Наконец, нужно проверить, могут ли системы, отправляющие файлы, обращаться только к предполагаемым назначениям.

Что именно затрагивает CVE-2026-92392

В бюллетене curl описана ошибка use-after-free в пути загрузки через HTTP/2. Во время загрузки сервер может отправить HTTP/2 RST_STREAM с причиной HTTP_1_1_REQUIRED или REFUSED_STREAM. Само соединение при этом может остаться активным, хотя отдельная передача будет остановлена. В уязвимом состоянии автомата curl позднее освобождает объекты передачи и соединения в таком порядке, что остаётся висячая ссылка на объект передачи.

Use-after-free не означает автоматически, что каждый запуск превращается в выполнение кода. Это означает, что программа продолжает обращаться к памяти после того, как владелец её освободил. В зависимости от того, что займёт этот участок памяти дальше, непосредственным результатом могут стать сбой, повреждение состояния, раскрытие информации или более управляемое нарушение безопасности памяти. В данном случае проект curl оценивает проблему как имеющую высокую степень опасности и описывает путь от ошибки памяти к удалённому выполнению кода.

Затронуты curl и libcurl версий 8.12.0–8.22.0 включительно. Версии до 8.12.0 этой конкретной ошибкой не затронуты, а в 8.23.0 исправление уже присутствует. Различие между curl и libcurl имеет практическое значение: командная утилита — лишь один потребитель, тогда как гораздо больше приложений могут напрямую вызывать библиотеку. Сервер, на котором никогда не запускается исполняемый файл curl, всё равно может быть уязвим через приложение, слинкованное с libcurl.

Уязвимость требует HTTP/2. Это не означает, что каждая HTTPS-передача автоматически уязвима, но и считать систему безопасной только потому, что пользователь явно не передавал опцию HTTP/2, нельзя. curl может согласовать HTTP/2 при подключении к HTTPS-сервису, который его предлагает, если локальная сборка содержит соответствующую поддержку. Приложения также могут явно выбирать HTTP/2 через параметры libcurl или более высокоуровневые сетевые фреймворки.

Уязвимая операция — загрузка данных с клиента на сервер. Обычные скачивания не относятся к сценарию, описанному в бюллетене. Это сужает область воздействия, но не делает проблему экзотической. Агенты резервного копирования, издатели артефактов, клиенты телеметрии, сервисы приёма документов, системы CI, облачные коннекторы, инструменты поддержки и программы синхронизации регулярно отправляют данные наружу. Некоторые используют curl только в одном небольшом участке более крупного процесса, поэтому инвентаризация пакетов может не показать реальную область риска.

Атакующая сторона находится на стороне получателя

Многие защитные сценарии начинаются с предположения, что опасным является сервер, с которого скачивают данные. CVE-2026-92392 переворачивает эту модель. Клиент начинает загрузку на сервер, которому доверяет, а сервер может оказаться компонентом, поставляющим вредоносное поведение протокола.

Это не означает, что злоумышленник может эксплуатировать любой процесс curl, просто разместив вредоносную страницу в интернете. Уязвимый процесс должен подключиться к серверу, контролируемому или находящемуся под влиянием атакующего, выполнить загрузку, согласовать HTTP/2 и удовлетворить условиям реализации, необходимым для достижения уязвимой последовательности очистки. В реальной среде это может произойти через специально созданную конечную точку, взломанный сервис, перенаправленный процесс, выбранное пользователем назначение загрузки или приложение, принимающее удалённую конфигурацию. Конкретный путь зависит от окружающего продукта.

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

В открытых данных сейчас различаются потенциальная эксплуатируемость и известная эксплуатация. В бюллетене описаны доказательство концепции и путь к выполнению кода при точном совпадении условий. Запись NVD не содержит собственной оценки CVSS и не утверждает, что уязвимость используется в атаках «в дикой природе». Сам факт публичного proof of concept остаётся значимым сигналом для защитников, особенно там, где curl встроен в долго работающие сервисы или обновляется медленно. Это не доказательство того, что каждая уязвимая установка уже скомпрометирована.

Почему с выпуском 8.23.0 нужно обращаться внимательно

Исправление вышло в составе согласованного релиза curl, который также устранил ещё 23 опубликованные проблемы безопасности, в основном оценённые проектом как имеющие низкую степень опасности. CVE-2026-92392 — единственная проблема с высокой оценкой в этом выпуске. Такое объединение создаёт два противоположных операционных риска. Одни команды могут увидеть большое число бюллетеней и отложить обновление, потому что оно кажется сложным. Другие обновят заметный пакет командной строки и решат, что вся цепочка зависимостей уже покрыта.

Правильный ответ — отделить срочность от единообразия. В первую очередь нужно выявить уязвимые сборки, выполняющие загрузки, и перевести их на исправленный пакет поставщика либо на curl и libcurl 8.23.0. Путь внедрения может различаться для операционной системы, базового образа контейнера, среды выполнения языка, сетевого устройства или коммерческого приложения. Пакет libcurl, сопровождаемый дистрибутивом, может содержать исправление, перенесённое назад, без изменения номера версии так, как этого ожидает примитивная проверка. Поэтому службе безопасности следует сверять бюллетень поставщика и журнал изменений пакета, а не полагаться на одно строковое сравнение.

Релиз изменил не только код безопасности. Проект удалил поддержку SMB и SMBS и внёс другие изменения поведения и исправления ошибок. Это не делает обновление небезопасным, но подчёркивает необходимость тестирования приложений, зависящих от редких протоколов, необычных схем аутентификации, нестандартных TLS-бэкендов или строгой обработки файлов. Исправление не следует откладывать ради идеального универсального набора тестов, однако поэтапное развёртывание может не дать самой процедуре устранения уязвимости прервать критически важный сервис загрузки.

Curl публикует отдельные сведения о стандартных версиях и ветках Rock-solid. Организациям, использующим поддерживаемую долгосрочную ветку, следует проверить, является ли подходящим выпуск 8.14.3, 8.16.2 или 8.20.2, вместо того чтобы бездумно заменять его последней стандартной веткой. Главный вопрос не в том, «какой номер показала страница загрузки командной утилиты upstream», а в том, «какой поддерживаемый пакет содержит исправление CVE-2026-92392 и как доказать, что именно этот пакет развёрнут».

Практическая инвентаризация для этой уязвимости

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

Затем добавьте в инвентаризацию поведение. Наивысший приоритет имеют процессы, которые одновременно:

  • работают на уязвимой сборке curl или libcurl;
  • загружают файлы или тела запросов в удалённый сервис;
  • разрешают согласование HTTP/2 или явно включают HTTP/2;
  • обрабатывают данные или учётные сведения, потеря которых будет существенной.

Уязвимая библиотека, используемая только для локального разбора метаданных, не должна получать такой же срочный статус, как публичный сервис автоматизации, отправляющий учётные данные, артефакты сборки, документы клиентов или резервные копии. При ранжировании риска нужно учитывать и контроль над назначением. Фиксированный список разрешённых адресов поставщиков — это не то же самое, что инструмент, принимающий произвольный URL от пользователя, задания, webhook или удалённого конфигурационного файла.

Для статически слинкованных или непрозрачных продуктов запросите у поставщика три конкретных ответа: содержит ли продукт curl или libcurl из уязвимого диапазона, возможны ли загрузки по HTTP/2 и какая сборка содержит исправление. Сохраните ответ в записи об активе. Формулировка «продукт использует HTTPS» недостаточна, как и фраза «в интерфейсе продукта нет curl»: она ничего не говорит о встроенных зависимостях.

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

Временные меры, пока исправления проходят путь до систем

В бюллетене curl указано, что при невозможности немедленно обновить или пропатчить систему можно отказаться от HTTP/2. Это мера снижения риска, а не замена исправлению. В командном сценарии оператор иногда может принудительно использовать HTTP/1.1 для узко определённой передачи. В приложении эквивалентом может быть параметр библиотеки, политика прокси, правило service mesh или конфигурация поставщика. Контроль нужно тестировать: отключение HTTP/2 в одной оболочке не поможет, если базовое приложение открывает отдельное соединение через другой путь.

Временное ограничение протокола также может иметь побочные эффекты. Некоторые сервисы требуют HTTP/2, используют мультиплексирование соединений для производительности или применяют разные правила аутентификации и тайм-аутов в зависимости от протокола. Задокументируйте исключение, назначьте владельца и установите дату окончания. Мера, сохраняющаяся бессрочно лишь потому, что никто не знает, действует ли она ещё, сама превращается в новую проблему инвентаризации.

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

Не пытайтесь решить проблему отключением проверки сертификатов или ослаблением TLS. Условия эксплуатации уязвимости включают сервер, который проходит проверки сертификата клиента. Это напоминает, что обычная аутентификация транспорта не является полной защитой от скомпрометированной или злонамеренно управляемой конечной точки. Отмена проверки сертификатов только расширит поверхность атаки и не устранит ошибку безопасности памяти.

Что проверять, если уязвимый клиент был доступен извне

Наличие уязвимой версии не доказывает компрометацию, а сбой не доказывает эксплуатацию. Тем не менее открытый для загрузок клиент заслуживает соразмерной проверки. Определите назначения, к которым он обращался в соответствующий период, какие файлы или тела запросов отправлялись, точную сборку curl или libcurl и согласовался ли HTTP/2. На эти вопросы могут ответить журналы приложения, прокси, телеметрия TLS и записи о процессах конечной точки, даже если сам curl фиксирует лишь общую ошибку передачи.

Ищите аномальное завершение, повторные попытки обращения к необычной конечной точке, изменение дочерних процессов, запускаемых загрузчиком, неожиданные файлы и исходящие соединения, начавшиеся сразу после неудачной передачи. Это сигналы для первичного анализа, а не уникальные признаки CVE-2026-92392. Обычный сбой загрузки может вызвать повторные попытки, а падение — перезапуск, поэтому интерпретацию нужно связывать с ожидаемым поведением хоста.

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

Для систем с высокой ценностью сравните уязвимую сборку с исправленной и сохраните доказательства обновления. Зафиксируйте контрольную сумму пакета или digest образа, версию работающего процесса и время развёртывания. Если поставщик предоставил hotfix вместо upstream-релиза, запишите бюллетень поставщика и идентификатор сборки пакета. Такие сведения полезнее комментария в заявке «curl пропатчен», особенно когда на одном хосте присутствует несколько копий библиотеки.

Что следует изменить разработчикам

Разработчикам следует считать libcurl частью границы безопасности приложения, а не взаимозаменяемой утилитой, скрытой под бизнес-логикой. Фиксации версии в файле сборки недостаточно, если среда выполнения поставляет другую общую библиотеку, базовый образ устарел или менеджер пакетов при пересборке выбирает уязвимую версию. Сделайте зависимость видимой в SBOM и обеспечьте воспроизводимый путь обновления.

Проверьте код загрузки с точки зрения контроля назначения, поведения перенаправлений, логики повторных попыток и выбора протокола. У сервиса, который загружает данные только на фиксированную конечную точку, и у сервиса, принимающего произвольные URL, разные модели угроз. Библиотека повторных попыток может открыть второе соединение с настройками, отличающимися от первого. Прокси может согласовать HTTP/2, даже если приложение явно это не указывало. Проверка безопасности должна следовать реальному пути соединения, а не самому удобному конфигурационному файлу.

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

Добавьте негативные тесты для прерванных передач HTTP/2, сбросов сервером, повторных попыток и очистки. Цель не в том, чтобы воспроизводить эксплойт в production или создавать наступательный инструмент. Нужно убедиться, что приложение безопасно обрабатывает неудачную передачу, действительно загружает исправленную зависимость и что поведение перезапуска и повторной попытки не создаёт обходной путь вокруг обновления.

Что операционным командам следует сообщить

Самое полезное внутреннее уведомление должно быть точным: CVE-2026-92392 затрагивает curl и libcurl 8.12.0–8.22.0; уязвимый сценарий связан с загрузкой по HTTP/2; исправленный upstream-релиз — 8.23.0; встроенные копии библиотеки также считаются. Не нужно призывать всех сотрудников обновлять браузер или прекращать пользоваться интернетом. Большинство людей не управляет такими процессами загрузки, а бессистемные предупреждения мешают услышать следующее действительно серьёзное уведомление.

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

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

Итог

CVE-2026-92392 стоит поставить в приоритет, потому что она сочетает широкое присутствие зависимости с серверным триггером во время загрузок клиента. Это не универсальный удалённый захват каждого экземпляра curl, а опубликованные условия эксплуатации требуют многого. Но отсутствие текущего признака эксплуатации не превращает уязвимый сервис загрузки в приемлемое долгосрочное исключение.

Найдите все копии curl и libcurl, определите, какие из них выполняют загрузки по HTTP/2, обновите уязвимые сборки до поддерживаемой версии с исправлением, а HTTP/1.1 или ограничения назначений используйте только как временные меры. Затем сохраните доказательство того, что исправление есть именно в работающем процессе, а не только в файле сборки или базовом образе. Именно такой ответ требуется этой уязвимости: конкретный, учитывающий зависимости и достаточно спокойный, чтобы обнаружить забытые копии.

Источники

Фактическая основа материала — бюллетень проекта curl о CVE-2026-92392, запись NVD, пояснение Даниэля Стенберга о превращении UAF в RCE, обсуждение The Hacker News, журнал изменений curl 8.23.0 и таблица релизов curl. Эти источники использованы для сведений о затронутых версиях, условиях эксплуатации, исправлении, изменениях выпуска и поддерживаемых ветках.