Спор о CVE: как curl отбивался от навязчивого репортера через MITRE

Несколько лет назад проект curl зарегистрировался и стал CNA (CVE Numbering Authority). Это означает, что команда сама распоряжается выдачей идентификаторов CVE в своей зоне ответственности. По любой проблеме безопасности внутри проекта именно curl решает, присваивать ей CVE или нет — без обходных путей и без сомнительных CVE, выданных третьими сторонами.

57 CVE

За это время curl опубликовал пятьдесят семь отдельных уязвимостей с соответствующими идентификаторами CVE. Получить CVE, будучи CNA, — быстрый и несложный процесс: небольшая, но эффективная команда безопасности справляется без лишнего трения. По сути, один вызов API — и номер готов.

Статус CNA почти не требует дополнительных усилий: у проекта и раньше был отлаженный процесс приёма, обработки и оценки отчётов об уязвимостях — как у ответственного и хорошо организованного open source проекта. CNA лишь убрал необходимость привлекать внешних участников.

Оценка

По каждому отчёту команда сначала тщательно разбирается, действительно ли речь идёт об уязвимости или проблеме безопасности вообще.

Если проблема безопасности подтверждается, ей присваивают уровень — LOW, MEDIUM, HIGH или CRITICAL. Поскольку неизвестно, как именно пользователи применяют curl или libcurl, учесть это невозможно — оценка ставится исходя из точки зрения самого curl.

Это лишь приблизительный ориентир: конкретный пострадавший пользователь вполне может оценить серьёзность проблемы иначе.

Ниже LOW

Для небольшого числа проблем можно представить теоретический, минимальный риск, но из-за экстремального набора условий и запутанных шагов, необходимых для его реализации, риск оценивается настолько малым, что на практике почти никто до него не доберётся. Внутри команды такие случаи называют «уровнем ниже LOW» — проблемами, для которых, по мнению разработчиков, лучше не выпускать CVE вовсе, чтобы не устраивать лишний «танец безопасности» там, где он не нужен.

Цена CVE

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

У каждого CVE есть эта скрытая цена. Она не ложится на сам проект curl напрямую и почти не ощущается изнутри, но экосистема платит реальную цену, игнорировать которую, по мнению команды, нельзя. Настоящие проблемы игнорировать нельзя никогда — но и бить тревогу по теоретическим сценариям, которые никогда не приведут к реальной уязвимости, тоже не стоит.

Спор

Первый со времён получения статуса CNA спор о CVE дошёл до команды 10 февраля 2026 года — по отчёту, поданному двумя месяцами ранее. Автор отчёта считал, что описанной им проблеме следовало присвоить CVE, команда curl с этим не согласилась. После отказа репортёр решил добиться выдачи CVE в принудительном порядке, эскалировав ситуацию в MITRE.

Возникает вопрос, почему получение именно этого CVE оказалось настолько принципиальным — но строить догадки пока не будем.

Я ответил MITRE, объяснив, что мы рассмотрели и обсудили проблему и по-прежнему уверены в своём решении. Приложил ссылку на оригинальный отчёт и обсуждение, чтобы они могли всё увидеть сами.

Имя хоста с точкой в начале

Сама проблема технически довольно узкая (как обычно) и связана с багом в функции curl, которая проверяет, совпадает ли используемое имя хоста с wildcard-шаблоном в сертификате.

Во-первых, пользователь должен использовать в URL имя хоста с точкой в начале, например https://.example.com/.

Такое имя невозможно использовать через DNS — там оно недопустимо, — но его можно прописать вручную с IP-адресом в файле /etc/hosts или аналогичном. Уже одно это условие делает сценарий крайне нишевым.

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

Далее: если curl всё же находит адрес для этого недопустимого с точки зрения DNS имени, сайт, к которому подключается curl, должен ещё иметь wildcard-сертификат для имени вида *.example.com, где «хвост» шаблона должен совпадать с именем в URL.

Если curl был собран с использованием одного из вариантов OpenSSL или Schannel для TLS (напомним, curl поддерживает множество разных TLS-бэкендов), он вызывает функцию Curl_cert_hostcheck(), чтобы проверить, покрывает ли wildcard используемое имя хоста.

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

Проблему исправили 8 декабря 2025 года, добавив юнит-тесты именно для этого сценария, чтобы он не повторился. Для всех проблем безопасности ниже уровня HIGH команда исправляет их как можно быстрее — это стандартная процедура. После фикса продолжилось обсуждение, заслуживает ли проблема выпуска CVE.

Ниже LOW

Использование имени хоста с точкой в начале должно быть крайне редким явлением — разве что в изолированной, контролируемой среде, где для разрешения имён применяется что-то отличное от DNS.

Заставить приложение использовать произвольное имя с точкой в начале обманным путём невозможно — такое имя просто не разрешится.

Явно заданное, необычное имя с точкой должно ещё и подключиться к хосту с wildcard-сертификатом на то же самое имя, и атакующий должен суметь развернуть этот поддельный хост, чтобы отдавать приложению вредоносные данные — именно из-за того, что curl некорректно не отклонял соединение при несовпадении wildcard.

Целая цепочка крайне маловероятных условий, которые все должны выполниться одновременно, чтобы проблема стала уязвимостью. Ситуация «ниже LOW». Слишком маловероятно — CVE не нужен.

Снова в мае

28 мая MITRE снова связалась с командой по тому же самому кейсу, повторно запросив обоснование отказа в выдаче CVE. Ответ был практически идентичен предыдущему — со ссылкой всё на тот же исходный отчёт на HackerOne и ветку обсуждения. Вся информация публична.

Снова в июне

15 июня MITRE снова обратилась с запросом обоснования решения не выдавать CVE по этой проблеме.

Ответ повторили в схожих формулировках, вновь сославшись на тот же самый отчёт.

Похоже на прекрасно отлаженную систему.

Вердикт

24 июня наконец пришло окончательное решение: проблема не признана уязвимостью безопасности.

Hello Yuhao,

Thank you for your participation in the CVE dispute process regarding the reported issue affecting curl through 8.17.0.

The MITRE TL-Root has completed its review of the information provided by all parties involved,
including the materials submitted by you and the response from the responsible CNA. Based on this
review, the MITRE TL-Root has determined that a CVE ID will not be assigned for the reported issue.

CNA Determination (Summary):

"This is a bug, now fixed in the master branch. It is not considered a security vulnerability because of how it requires a local attacker with privileges present to make it so."

After evaluating the available evidence and the CNA's assessment, the MITRE TL-Root agrees with this determination and considers the matter resolved. As the adjudicating authority in this dispute process, the decision of the MITRE TL-Root represents the final determination for this case.

We appreciate your engagement with the CVE Program and your efforts to responsibly report and coordinate security issues.

Respectfully,

MITRE TL-Root