OpenVPN выпустил версию 2.7.6 спустя чуть больше месяца после предыдущего пакета исправлений безопасности. Релиз закрывает обход административных ограничений в Windows и ошибку проверки сертификатов в сборках с mbedTLS, а ветка 2.6 получила отдельное обновление 2.6.22. Параллельно разработчики изменили обработку TCP-соединений, DCO и размеров пакетов.

OpenVPN выпустил две исправленные ветки 5 августа
Парадокс нынешнего релиза в его масштабе: список изменений сравнительно короткий, но он затрагивает границы доступа, проверку личности по сертификату и поведение сетевого транспорта. Проект OpenVPN опубликовал версии 2.7.6 и 2.6.22 5 августа 2026 года. Исходные архивы и установщики Windows появились на официальной странице загрузок.
OpenVPN — открытое программное обеспечение для создания зашифрованных сетевых туннелей. Его используют как самостоятельный клиент и сервер, в маршрутизаторах, корпоративных шлюзах и приложениях VPN-провайдеров. Поэтому ошибка в службе Windows или механизме сопоставления сертификата с именем пользователя может проявиться далеко за пределами обычного настольного клиента.
Версия 2.7.6 относится к современной ветке с новыми сетевыми возможностями. Версия 2.6.22 сохраняет прежнюю архитектуру и получает более узкий набор исправлений. Такой параллельный выпуск позволяет увидеть, какие проблемы общие для обеих веток, а какие связаны с механизмами OpenVPN 2.7.
CVE-2026-63649 обходила ограничения каталогов в Windows
Самое заметное исправление касается openvpnserv — системной службы OpenVPN в Windows. Она принимает команды через управляющий сокет и запускает процесс OpenVPN с переданными параметрами. Администратор может ограничить каталоги, из которых разрешено загружать конфигурационные файлы.
До версий 2.7.6 и 2.6.22 проверка командной строки была недостаточно строгой. Специально сформированные параметры позволяли обойти правило разрешённых каталогов и запустить OpenVPN с конфигурацией из другого места. Ошибка получила идентификатор CVE-2026-63649.
Разработчики отдельно уточнили границу проблемы: обход каталога не давал процессу права читать файлы, к которым у пользователя уже не было доступа в Windows. Системная модель разрешений продолжала действовать. Уязвимость нарушала административную политику OpenVPN, поскольку служба могла принять конфигурацию из пути, который администратор исключил.
Для управляемых рабочих станций и терминальных серверов разница существенна. Ограничение каталога часто отделяет проверенные конфигурации от пользовательских файлов. После исправления служба тщательнее разбирает командную строку, переданную через управляющий сокет.
CVE-2026-63650 затрагивала mbedTLS и имя пользователя в сертификате
Вторая уязвимость относится только к ветке 2.7 и исправлена в OpenVPN 2.7.6. Опция --x509-username-field позволяет выбрать поле сертификата X.509, из которого OpenVPN извлекает имя пользователя. Такой механизм встречается в инфраструктуре с собственным центром сертификации, где доступ связывают с атрибутами выданного сертификата.
В сборках OpenVPN с криптографической библиотекой mbedTLS эта опция работала некорректно. При очень специфической конфигурации и наличии подходящего сертификата система могла принять сертификат, который по заданному правилу должен был быть отклонён. Ошибка зарегистрирована как CVE-2026-63650.
Сам проект называет проблему уязвимостью низкого приоритета. Для её проявления требуется особая схема проверки и сертификат, созданный центром сертификации с совпадающими полями. Массовые установки с OpenSSL или без --x509-username-field этот сценарий не описывает.
Здесь человеческий угол связан с доверием к сертификату. Администратор видит корректную криптографическую подпись, а OpenVPN дополнительно должен извлечь правильное поле и сопоставить его с учётной записью. Сбой на втором этапе меняет решение о допуске, хотя сам сертификат остаётся технически действительным.
DCO восстанавливается после рассинхронизации ключей
Обе новые версии дорабатывают DCO — Data Channel Offload. Этот механизм переносит обработку зашифрованного трафика из пользовательского процесса OpenVPN в ядро операционной системы или специализированный драйвер. За счёт этого снижается количество переключений между режимами работы процессора и растёт пропускная способность туннеля.
Исследователь сообщил о ситуации, когда обновление ключа могло рассинхронизировать состояние OpenVPN и DCO в ядре. При точном совпадении событий процесс доходил до внутренней проверки ASSERT() и завершался. Команда OpenVPN сначала рассматривала отчёт как проблему безопасности, затем признала сценарий непригодным для эксплуатации.
Исправление всё равно вошло в обе ветки. Машина состояний теперь умеет восстановиться после рассинхронизации ключей. Для серверов с DCO практический эффект выражается в меньшей вероятности аварийного завершения при редком конфликте между пользовательской частью и ядром.
TCP_NODELAY включён для всех TCP-сокетов OpenVPN 2.7.6
Самое заметное изменение повседневного поведения относится к соединениям OpenVPN поверх TCP. Версия 2.7.6 всегда включает флаг TCP_NODELAY, который отключает алгоритм Нейгла.
Алгоритм Нейгла временно накапливает небольшие фрагменты данных и объединяет их в более крупный TCP-пакет. Такой подход уменьшает количество пакетов, но способен добавлять задержку. В интерактивном туннеле пауза заметна при удалённой работе с терминалом, передаче коротких запросов или использовании приложений с частыми небольшими сообщениями.
OpenVPN 2.7.6 отправляет такие данные без дополнительного ожидания на всех TCP-сокетах. Опция --tcp-nodelay остаётся в конфигурации: сервер использует её для передачи настройки старым клиентам, у которых новое поведение ещё отсутствует.
Изменение касается только транспорта TCP. Туннели OpenVPN поверх UDP работают по другой модели и флаг TCP_NODELAY там неприменим. Разработчики описывают настройку как оптимизацию задержки, без обещания одинакового ускорения для любой сети.
Конфигурация tun стала короче, а таймеры получили предел
OpenVPN 2.7.6 меняет ещё несколько пользовательских настроек. Если директива --dev отсутствует, программа теперь выбирает --dev tun. Раньше тип виртуального сетевого устройства требовалось указывать явно.
tun передаёт IP-пакеты третьего сетевого уровня и используется в большинстве маршрутизируемых VPN-конфигураций. Альтернативный режим tap работает с Ethernet-кадрами второго уровня и нужен для более специализированных сценариев. Новый вариант по умолчанию делает короткие конфигурации однозначными для наиболее распространённого режима.
Параметры --ping и --keepalive теперь ограничены 24 часами. Причина связана с DCO: ядру пришлось бы поддерживать произвольно большие значения и отдельно защищать 32-битные счётчики от переполнения. Сутки значительно превышают обычные интервалы контроля соединения, которые чаще измеряются секундами или минутами.
В справке сборок с mbedTLS больше не показывается параметр --providers. Он относится к механизму провайдеров OpenSSL и не работает с mbedTLS. Изменение убирает из --help опцию, недоступную в конкретной сборке.
| Изменение в OpenVPN 2.7.6 | Где проявляется | Практический эффект |
TCP_NODELAY включён постоянно | Туннели поверх TCP | Небольшие сообщения отправляются без ожидания объединения |
--dev tun выбран по умолчанию | Конфигурации без директивы dev | Тип устройства становится определённым без отдельной строки |
--ping и --keepalive ограничены 24 часами | Клиенты и серверы с большими таймерами | DCO получает предсказуемый диапазон 32-битных значений |
--providers скрыт в mbedTLS-сборках | Вывод openvpn --help | Справка соответствует возможностям криптографической библиотеки |
Расчёт пакетов Epoch и TLS-рукопожатия получили точечные исправления
В соединениях между OpenVPN 2.7 и OpenVPN 2.7 неверно вычислялся размер идентификатора пакета формата Epoch. Ошибка составляла четыре байта. В результате пакет мог превышать запас, рассчитанный параметром mssfix mtu, на те же четыре байта.
mssfix ограничивает размер данных внутри туннеля, чтобы итоговый пакет с заголовками OpenVPN помещался в допустимый MTU сети. Ошибка на четыре байта выглядит небольшой, но на маршруте с жёстким ограничением она способна приводить к фрагментации или потере пограничных пакетов. В 2.7.6 размер заголовка Epoch учитывается корректно.
Сервер теперь отклоняет входящие пакеты HARD RESET с идентификатором последовательности, отличным от нуля. Такие пакеты противоречат ожидаемому началу сеанса и могли мешать установлению TLS-соединения в конфигурациях «точка — точка».
Ещё одна правка уточняет минимальную длину Ethernet-кадров с тегом 802.1Q при использовании --client-nat. Исследователи дважды сообщали об этом как о возможной проблеме безопасности. Разработчики объяснили, что внутренние буферы OpenVPN всегда выделяются под полный кадр, поэтому чтение нескольких байтов за логической границей пакета не приводило к выходу за фактическую память и не имело вредных последствий.
OpenVPN 2.7.6 и 2.6.22 различаются по составу изменений
Две ветки получили общий набор исправлений для службы Windows, DCO, пакетов HARD RESET и кадров 802.1Q. Дальше их содержание расходится.
| Компонент | OpenVPN 2.7.6 | OpenVPN 2.6.22 |
CVE-2026-63649 в openvpnserv | Исправлена | Исправлена |
CVE-2026-63650 в --x509-username-field с mbedTLS | Исправлена | В журнале 2.6.22 не указана |
| Восстановление DCO после рассинхронизации ключей | Добавлено | Добавлено |
Проверка HARD RESET | Добавлена | Добавлена |
| Исправление размера пакета Epoch | Добавлено | Не относится к списку 2.6.22 |
TCP_NODELAY по умолчанию | Добавлено | Не указано |
Автоматический --dev tun | Добавлен | Не указан |
Полный список для современной ветки опубликован в официальном журнале OpenVPN 2.7.6. Изменения поддерживаемой ветки перечислены отдельно в журнале OpenVPN 2.6.22.
Разделение показывает характер релизов. OpenVPN 2.6.22 сосредоточен на исправлении общей ошибки Windows и устойчивости сетевой логики. OpenVPN 2.7.6 включает те же изменения, дополнительную проверку сертификатов и несколько корректировок поведения, заметных в конфигурации и TCP-трафике.
Масштаб уязвимостей и скорость распространения обновлений пока неизвестны
На 6 августа 2026 года точно известны идентификаторы CVE-2026-63649 и CVE-2026-63650, условия их проявления и версии, в которых код исправлен. В журнале проекта отсутствуют оценки CVSS и сведения о подтверждённой эксплуатации этих ошибок.
Windows-уязвимость затрагивает границу между управляющей службой и разрешёнными каталогами конфигураций. Ошибка mbedTLS относится к узкому сценарию, где имя пользователя извлекается из поля сертификата. DCO-рассинхронизация после анализа признана непригодной для эксплуатации, хотя её обработка стала устойчивее.
Пока неизвестно, когда OpenVPN 2.7.6 и 2.6.22 появятся в пакетах Linux-дистрибутивов, на маршрутизаторах и в сторонних VPN-приложениях. Хотя проект уже обнародовал исходные коды и установщики для Windows, сроки интеграции зависят от сопровождающих каждого продукта. В новом релизе установлены конкретные границы доверия и изменены некоторые сетевые параметры, поэтому его реальное воздействие станет очевидным после того, как сборки начнут распространяться за пределами официального проекта.