OpenSSH CVE-2026-35414: как запятая в сертификате обошла вход под root

Что на самом деле делает CVE-2026-35414

OpenSSH поддерживает два разных способа авторизации входа: перечисление отдельных публичных ключей в файле authorized_keys, что использует практически каждый небольшой VPS, и сертификатную аутентификацию, где доверенный удостоверяющий центр подписывает короткоживущие сертификаты, подтверждающие личность пользователя, вместо перечисления каждого ключа отдельно. Сертификатная аутентификация распространена в крупных организациях, которые часто меняют доступ и не хотят редактировать authorized_keys на каждом сервере при каждом приходе или уходе сотрудника.

При использовании сертификатной аутентификации администратор может ограничить, какие имена учётных записей, называемые принципалами, данный удостоверяющий центр может авторизовать, с помощью опции principals в записи authorized_keys, которая доверяет этому CA. CVE-2026-35414 это ошибка в том, как OpenSSH сравнивал имя принципала сертификата с этим ограничением, когда само имя принципала содержало запятую. Поскольку логика сравнения использовала запятые как разделитель списка разрешённых принципалов, специально или случайно сформированный сертификат с запятой в собственном поле принципала мог быть разобран так, что удовлетворял ограничению, которое должен был не пройти, позволяя владельцу сертификата аутентифицироваться под учётной записью, потенциально включая root, для которой это ограничение специально было написано, чтобы блокировать доступ.

Почему запятая ломает проверку principals

Этот класс ошибок, когда специальный символ, который должен быть разделителем в одном контексте, просачивается в значение, где его быть не должно, имеет долгую историю в безопасности программного обеспечения; SQL-инъекции и инъекции HTTP-заголовков относятся к той же категории ошибок. Конкретная опасность с принципалами сертификатов в том, что сам сертификат, а не только конфигурация сервера, поставляет значение, которое разбирается, и удостоверяющий центр, который недостаточно тщательно проверяет подписываемые им имена принципалов, может выпустить сертификат, технически валидный и технически доверенный, но структурно неожиданный для кода, который его проверяет.

Публичные бюллетени, описывающие уязвимость, включая бюллетень Агентства кибербезопасности Сингапура и Center for Internet Security, описывают практический эффект прямо: пользователь, владеющий сертификатом, подписанным доверенным CA, мог аутентифицироваться под другой, более привилегированной учётной записью, чем предполагал сертификат, вплоть до root, без необходимости похищать или подбирать отдельные учётные данные для этой учётной записи.

Кого это реально касается

Уязвимость важна только для серверов, использующих сертификатную аутентификацию OpenSSH с директивой TrustedUserCAKeys и ограничением principals в sshd_config или строкой cert-authority в authorized_keys, на версии OpenSSH старше 10.3. Такая настройка распространена в крупных инжиниринговых организациях, управляемых парках серверов и средах, построенных вокруг инструментов вроде SSH secrets engine HashiCorp Vault или внутреннего CA для доступа к инфраструктуре. Это редкость для типичного VPS малого бизнеса, где доступ по SSH обычно управляется через несколько отдельно перечисленных публичных ключей, а не через удостоверяющий центр.

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

Сервер с обычной аутентификацией по публичному ключу, то есть с отдельными ключами, вставленными в authorized_keys без настроенной директивы TrustedUserCAKeys, вообще не подвержен CVE-2026-35414. Это описывает большинство настроек VPS малого бизнеса и самостоятельно управляемых серверов, и это стоит проверить, а не предполагать: быстрая проверка выше, поиск директив сертификатов в sshd_config и authorized_keys через grep, занимает меньше минуты и даёт однозначный ответ.

Как проверить свой сервер

ssh -V
grep TrustedUserCAKeys /etc/ssh/sshd_config
grep cert-authority ~/.ssh/authorized_keys
grep PermitRootLogin /etc/ssh/sshd_config

Если вторая и третья команды не вернули результата, сертификатная аутентификация не настроена, и эта конкретная уязвимость к серверу не относится. Если версия OpenSSH из первой команды 10.3 или новее, исправление уже присутствует независимо от метода аутентификации. Если PermitRootLogin явно не установлен в no, это стоит исправить отдельно от этой CVE: наш раздел глоссария про вход под root и полное руководство по усилению защиты SSH объясняют, почему его отключение напрямую ограничивает ущерб от любого обхода аутентификации, независимо от его типа.

Как это исправить

Исправление: обновить OpenSSH до версии 10.3 или новее, что напрямую устраняет ошибку сравнения principals; настройки, полностью закрывающей обход на старой версии, не существует, потому что дефект в самой логике разбора, а не в настройке, которую контролирует администратор. На Debian и Ubuntu команда sudo apt update && sudo apt install openssh-server подтягивает исправление, если дистрибутив уже перенёс его в поддерживаемый релиз; на дистрибутивах семейства RHEL эквивалент такой: sudo dnf upgrade openssh-server. Всегда проверяйте установленную версию после обновления командой ssh -V, а не считайте обновление успешным по умолчанию.

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

Более общий урок для операторов VPS

Даже для большинства операторов небольших VPS, которые не используют собственный удостоверяющий центр SSH и не подвержены напрямую CVE-2026-35414, этот случай : это полезный конкретный повод придерживаться трёх привычек, независимо от того, о какой именно CVE пишут в новостях в этом месяце. Во-первых, точно знайте, какие механизмы аутентификации реально активны на сервере, а не предполагайте; две команды grep выше заняли пару секунд и дали однозначный ответ вместо догадки. Во-вторых, держите сам SSH актуальным, потому что даже редко эксплуатируемые компоненты могут превратиться именно в такой обход, как только в них найдут уязвимость. В-третьих, отключайте вход под root независимо от используемого метода аутентификации, потому что обход, дающий доступ только под ограниченной учётной записью, это существенно меньший инцидент, чем обход, отдающий root за один шаг.

Именно этот паттерн: рабочее исправление уже опубликовано, а какая-то часть серверов в интернете остаётся непропатченной, ровно то, что отслеживает каталог Known Exploited Vulnerabilities CISA, и то, вокруг чего наше руководство по управлению обновлениями предлагает строить процесс, а не реагировать на каждый отдельный бюллетень как на неожиданность.