Миллионы доменов в зоне риска. Почему ваша защита на Cloudflare может не работать

Исследователь безопасности заявил о проблеме в архитектуре Cloudflare, которая, по его оценке, затрагивает миллионы доменов на тарифах Free и Pro и может ослаблять защиту от несанкционированного выпуска TLS-сертификатов. Речь о механике Universal SSL, которая при наличии CAA-записей у зоны автоматически добавляет в DNS дополнительные «разрешающие» записи для центров сертификации, но делает это без ограничений, предусмотренных расширениями RFC 8657.

CAA-записи нужны, чтобы владелец домена мог явно указать, каким удостоверяющим центрам разрешено выпускать сертификаты для его имени. RFC 8657 расширяет эту идею двумя ключевыми параметрами: привязкой к конкретному ACME-аккаунту (accounturi) и ограничением методов проверки владения доменом (validationmethods). В идеале это позволяет не просто выбрать «какой CA», а также зафиксировать «каким аккаунтом» и «каким методом» можно получать сертификаты.

Суть претензии в том, что Cloudflare, по описанию в карточке NotCVE, способна вернуть в ответах DNS дополнительные записи вида CAA 0 issue "letsencrypt.org" или issuewild без параметров RFC 8657, причем эти автоматически добавленные записи могут не отображаться в панели управления, но будут видны при проверке через dig. А по правилам обработки CAA достаточно, чтобы хотя бы одна подходящая запись разрешала выпуск, и тогда более строгие ограничения владельца домена фактически перестают быть гарантией.

Опасность сценария становится понятнее на примере MitM-атак, где злоумышленник получает «позицию на пути» к трафику валидации домена. В таком случае атакующий может попытаться пройти DV-проверку у разрешенного CA от своего имени, запросить сертификат на домен жертвы и затем использовать его для перехвата HTTPS-трафика. В разборе проблемы прямо проводится параллель с инцидентом вокруг jabber.ru в 2023 году, где критическую роль играл перехват на сетевом уровне и возможность пройти валидацию без взлома самого сервера.

Cloudflare, по словам автора обращения, признала описанное поведение, но не сочла его уязвимостью уровня CVE и отнесла к ожидаемой функциональности, при этом поддержку RFC 8657 для массовых тарифов не назвала приоритетом. Параллельно кейс получил идентификатор NotCVE-2026-0001, а также попал в координацию CERT/CC через платформу VINCE под номером VU#840183.

Отдельно важно не путать эту историю с другой ACME-уязвимостью Cloudflare, про которую компания недавно публиковала постмортем: там речь шла о логике выдачи ответов на ACME-пути и взаимодействии с механизмами WAF, и этот баг уже исправлен. В обсуждаемом кейсе NotCVE-2026-0001 претензия относится не к «ошибке валидации», а к базовой политике автодобавления CAA, которая расширяет разрешения по умолчанию.

Фоном к дискуссии служит и январский BGP-инцидент в Венесуэле, который Cloudflare разбирала как пример того, что заметные аномалии маршрутизации продолжают регулярно происходить. В контексте этой темы это усиливает аргумент о том, что сетевой уровень не всегда можно считать надежной основой для проверок владения доменом, особенно когда речь идет о DV-сертификатах и HTTP-валидации.

Практический вывод для владельцев доменов простой: если вы полагаетесь на строгие политики CAA с параметрами RFC 8657, стоит проверить фактические DNS-ответы на предмет неожиданных issue/issuewild записей, а не ограничиваться тем, что показано в интерфейсе провайдера. В документации Cloudflare прямо указано, что при включенном Universal SSL и добавлении CAA-записей сервис может автоматически добавлять свои CAA-записи для обеспечения работы Universal SSL.