Обновите OpenVPN: подключившийся клиент может выдать себя за другого (CVSS 7.6)

22 октября 2026 Ubuntu выпустила USN-8953-1 по OpenVPN. Демон криво разбирает поле subject в сертификате. Клиент, который уже подключился, может выдать себя за другого пользователя. Карточка одна, CVE-2026-84790.

В шапке бюллетеня формулировка короче. OpenVPN может открыть доступ к сетевым службам не тому клиенту. Приоритет Ubuntu стоит Medium. На карточке рядом оценка CVSS 4.0: 7.6, это High. Вектор целиком такой: CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Атака по сети, сложность высокая, нужны дополнительные условия. Привилегии низкие: это уже свой принятый доступ, не гость без сертификата. Пользователь ничего не нажимает. Конфиденциальность и целостность на затронутой системе высокие, доступность не страдает. Соседние системы в векторе не задеты. Цифра 7.6 при такой сложности не значит, что любой запрос из интернета роняет VPS с WordPress.

Subject в сертификате клиента

Описание на карточке называет диапазон: OpenVPN с 2.7_alpha1 по 2.7.7. Через специально собранное поле subject удалённый пользователь, который уже прошёл проверку, может выдавать себя за других. Карточку опубликовали 13 октября 2026. Последнее обновление на ней стоит 22 октября, в день бюллетеня.

На обычном VPS, где живут nginx, PHP-FPM, MariaDB и WordPress, пакета openvpn часто нет. Тогда этот USN сервер не меняет. Веб-сервер, пул FPM и база в списке пакетов не значатся. Дыра в демоне, который принимает клиентов VPN: туннель между офисами, вход админа в свою сеть, отдельный канал для бэкапов. Пока этот процесс перезапускается, сайт на 443 продолжает отвечать. PHP не читает subject чужого сертификата OpenVPN.

Дальше решает конфигурация демона, не номер CVE. Если сервер отличает клиентов по полю subject и от этого раздаёт адреса, маршруты и доступ к внутренним службам, подмена этого поля как раз про чужой вход в сеть. Бюллетень говорит про unintended access to network services. Это не запись в wp-config.php и не дыра в ядре WordPress. Клиент, который выдал себя за другого, видит сеть так, как её видит тот пользователь.

2.7.7, 2.7.0, 2.6.19 и 2.5.11

Исправление уже в репозитории четырёх релизов. Пакет один, openvpn.

  • Ubuntu 26.10 (stonking): 2.7.7-1ubuntu1.1
  • Ubuntu 26.04 LTS (resolute): 2.7.0-1ubuntu1.4
  • Ubuntu 24.04 LTS (noble): 2.6.19-0ubuntu0.24.04.5
  • Ubuntu 22.04 LTS (jammy): 2.5.11-0ubuntu0.22.04.6

Текст CVE говорит про ветку 2.7, с alpha1 по 2.7.7. В таблице статусов строки Fixed стоят ещё на noble и jammy, где пакет старше: 2.6.19 и 2.5.11. Эти два LTS в бюллетень включены, пакет для них вышел. Берите версию со своей строки. Deb с 26.04 на 22.04 не ставьте: зависимости разъедутся.

Ubuntu пишет, что хватает обычного обновления системы, после него OpenVPN нужно перезапустить. Коммит на карточке дан для справки, накладывать его руками не советуют. Upstream там cf4384eef4676a01bd3ee98fa602f7b2af8079ea.

Рестарт демона, не nginx

Сначала посмотрите, стоит ли пакет и какая у него ревизия. Потом обновите индекс и поставьте только openvpn, если кандидат новее установленного. Юниты, которые реально держат туннель, видны отдельной командой.

dpkg-query -W -f='${Version}\n' openvpn
sudo apt update
sudo apt install --only-upgrade openvpn
systemctl list-units 'openvpn*' --type=service --all

openvpn --version печатает номер ветки, а не ревизию пакета Ubuntu. На 26.10 в CVE как раз назван верх диапазона, 2.7.7, а исправление сидит в суффиксе 1ubuntu1.1. С бюллетенем сравнивают вывод dpkg-query, не короткую строку из --version. Если пакета нет, dpkg-query так и скажет. Ставить OpenVPN «заодно» незачем.

Смотрите, какой юнит в состоянии active. На Ubuntu это обычно openvpn.service, openvpn@имя или openvpn-server@имя. Имя после @ совпадает с файлом в /etc/openvpn/server/ без .conf. Рестартите этот юнит: sudo systemctl restart openvpn-server@имя или sudo systemctl restart openvpn.service, смотря что в списке. nginx -t и reload здесь ни при чём. Конфиг веб-сервера бюллетень не меняет, php-fpm и MariaDB тоже. Рестарт OpenVPN обрывает текущие сессии туннеля. Если админская SSH сидит внутри этого VPN, команда оборвёт и её. На этот момент нужна вторая дорога: консоль в панели хостера или SSH мимо туннеля.

После установки версия должна совпасть со строкой релиза. На 26.10 это 2.7.7-1ubuntu1.1, на 26.04 это 2.7.0-1ubuntu1.4, на 24.04 это 2.6.19-0ubuntu0.24.04.5, на 22.04 это 2.5.11-0ubuntu0.22.04.6. Если apt-cache policy openvpn показывает кандидата старше этих строк, индекс security ещё не подтянулся или машина смотрит не в тот карман репозитория. Сначала ещё раз apt update, потом смотрите candidate, и только потом --only-upgrade.

Если туннель между офисами собран на 2.6 или 2.7, это как раз ветки из таблицы. Схема site-to-site на этих версиях разобрана отдельно. Пакет после USN остаётся той же веткой, меняется ревизия Ubuntu. Конфиг, сертификаты и ключи переписывать не нужно. Нужен новый бинарник и рестарт процесса, который его держит.

Focal всё ещё без версии

20.04 (focal), 18.04, 16.04 и 14.04 на карточке CVE стоят со статусом Needs evaluation. Фиксированной версии пакета для них нет, в сам USN-8953-1 эти релизы не входят. Deb с noble или jammy туда не кладите. Пока строки Fixed нет, из репозитория Ubuntu обновлять нечем. Если OpenVPN на 20.04 нужен только для редкого входа и туннель можно погасить, демон лучше остановить, чем держать старый процесс на внешнем адресе. Сайт на nginx от остановки openvpn не зависит, если посетители ходят на 80 и 443 напрямую.

Проверьте dpkg. Если openvpn установлен и релиз один из четырёх в бюллетене, поставьте версию из таблицы и перезапустите демон. Если пакета нет, USN-8953-1 этот сервер не меняет.

Источники и ссылки


Комментарии загружаются…