Коротко: 11 августа 2026 вышел OpenSSH 10.5 — на пять недель раньше запланированного. Причина — волна ИИ-ассистированных отчётов о багах. Три уязвимости устранены: самая серьёзная позволяла обойти блокировку ssh-agent через переадресованный сокет. Обновитесь немедленно — особенно если используете ssh-agent forwarding или SFTP.
Содержание
Что такое OpenSSH и зачем его обновлять
OpenSSH — это открытая реализация протокола SSH, которая де-факто стала стандартом для защищённого удалённого доступа и передачи файлов на Linux, macOS и Windows. Два наиболее популярных способа работы с файлами через OpenSSH:
- SFTP (SSH File Transfer Protocol) — защищённый протокол передачи файлов, работающий поверх SSH. Используется в файловых менеджерах (FileZilla, WinSCP, Cyberduck) и скриптах для синхронизации файлов с серверами.
- SCP (Secure Copy Protocol) — команда для копирования файлов между локальной машиной и удалённым сервером или между двумя удалёнными серверами.
Всё это работает поверх SSH-соединения. Уязвимость в OpenSSH напрямую затрагивает безопасность файловой передачи: если злоумышленник эксплуатирует баг, он получает доступ к вашим файлам и ключам на сервере. Предыдущая версия 10.4 также устраняла уязвимости в SFTP и SCP.
Уязвимость 1: обход блокировки ssh-agent
Это наиболее серьёзная из трёх уязвимостей. ssh-agent — это фоновый процесс, который хранит расшифрованные приватные ключи в памяти. Когда вы блокируете агент командой ssh-add -x, он перестаёт выполнять операции с ключами — никаких подключений, никаких подписей. Так должно работать.
Проблема была введена расширением протокола session-bind@openssh.com, появившимся в OpenSSH 10.4. Расширение предназначено для привязки соединения к конкретной сессии, но содержало логическую ошибку: запросы через переадресованный (forwarded) агент-сокет проходили проверку блокировки по-другому пути и могли выполниться даже при заблокированном агенте.
Если вы подключались к промежуточному серверу с включённой переадресацией агента (ForwardAgent yes), атакующий с доступом к этому серверу мог добавить PKCS#11-токены в ваш агент и использовать ключи с ограничениями назначения — даже если вы заблокировали агент до начала сессии.
Уязвимость актуальна для сценариев многоступенчатого SSH: когда вы прыгаете через промежуточный хост (jump host) или используете ProxyJump. Если у вас ForwardAgent отключён (а так и должно быть по умолчанию на большинстве систем), непосредственной угрозы не было.
Уязвимость 2: use-after-free в удалённом перенаправлении
Вторая уязвимость — use-after-free в клиентской части ssh при обработке удалённого перенаправления портов. Use-after-free — класс ошибок памяти, при котором программа обращается к области памяти после того, как та была освобождена.
В данном случае ошибка возникала при определённой гонке состояний: если локальный мультиплексированный сокет добавлял запись о перенаправлении в момент, когда уже ожидался ответ на запрос remote open, код обращался к указателю, которым больше не владел. Это могло привести к аварийному завершению SSH-клиента или, в теории, к выполнению произвольного кода.
Условие для эксплуатации достаточно специфическое (требует мультиплексирования соединений через ControlMaster), поэтому большинство обычных пользователей под прямой угрозой не находились. Тем не менее для систем с ControlMaster auto и активным переадресованием портов риск был реальным.
Уязвимость 3: брешь в ключевом слове restrict
Третья уязвимость находится на стороне сервера и связана с обработкой файла authorized_keys. Ключевое слово restrict в этом файле должно запрещать все привилегированные операции для конкретного ключа, включая перенаправление портов и тоннелирование.
Оказалось, что в OpenSSH 10.4 и ниже restrict не распространялся на туннельное перенаправление (tun/tap tunnel forwarding). Это означало, что пользователь с ключом, помеченным как restrict, теоретически мог запросить туннельное соединение — несмотря на то что это явно противоречит намерению администратора. В 10.5 ограничение распространено на все виды туннелирования.
Уязвимость актуальна для серверов, где PermitTunnel yes (по умолчанию отключено) и где используется restrict в authorized_keys для ограничения возможностей конкретных ключей. Большинство типовых конфигураций не активировали туннелирование явно, так что фактическая эксплуатация была маловероятна.
Почему ИИ меняет цикл обновлений в open-source
Самое интересное в этом релизе — не сами уязвимости, а контекст их обнаружения. В официальных заметках к выпуску команда OpenSSH прямо указала: выход версии 10.5 через пять недель после 10.4 вместо обычных трёх-четырёх месяцев обусловлен «значительным ростом числа отчётов о безопасности, многие из которых получены от ИИ-моделей или при их содействии».
Это первый случай, когда крупный open-source-проект публично назвал ИИ-ассистированные отчёты причиной внепланового досрочного релиза. Раньше команды безопасности регулярно получали такие отчёты, но без явного упоминания в официальных документах.
По словам разработчиков, многие из ИИ-отчётов при детальном анализе не подтверждают реального риска в контексте реалистичной модели угроз. Однако те, что приходят вместе с подробным тест-кейсом и предложенным патчем, воспринимаются как полноценные и приветствуются. Команда призывает сочетать ИИ-обнаружение с ручным анализом и человеческим суждением: «ИИ находит — человек разбирается».
Этот прецедент важен для понимания безопасности в экосистеме файлов и инструментов: цикл обнаружения уязвимостей ускоряется, и обновления стоит ставить быстрее, чем раньше. Задержка обновления OpenSSH сегодня несёт больший риск, чем год назад.
Как обновиться до OpenSSH 10.5
OpenSSH 10.5 доступен с 11 августа 2026 года. Способ обновления зависит от вашей платформы:
- Ubuntu / Debian:
sudo apt update && sudo apt upgrade openssh-client openssh-server— пакет появится в репозиториях по мере обновления дистрибутива. - Fedora / RHEL / Rocky:
sudo dnf update openssh - Arch Linux:
sudo pacman -Syu openssh— в экстренных случаях команда Arch обычно обновляет пакет в течение 24–48 часов после выхода. - macOS: Homebrew:
brew upgrade openssh. Системный ssh от Apple обновляется через обновления macOS и может запаздывать. - Windows: OpenSSH как компонент Windows обновляется через Windows Update. Standalone-версию (например, через winget:
winget upgrade Microsoft.OpenSSH.Beta) можно обновить сразу.
После обновления проверьте версию командой: ssh -V — она должна показать OpenSSH_10.5. Если используете ssh-agent forwarding (ForwardAgent yes), убедитесь, что обновили клиентскую машину и все промежуточные серверы.
Подробнее о принципах безопасной работы с файловыми подключениями читайте в разделе Безопасность на Loadfile.