13 августа 2026 года проект Rsync опубликовал версию 3.5.0 после многомесячного аудита обработки путей и протокола rsync-daemon. Релиз закрывает 33 проблемы безопасности: одну Critical, 17 High и 15 Medium; CVE-2026-53791 с оценкой CVSS 9.1 позволяет при определённой конфигурации PROXY protocol подменить адрес клиента и обойти правила hosts allow/hosts deny. Вместе с патчами команда расширила тестовое покрытие и добавила regression-тест для каждого исправления безопасности.
После регрессий Rsync 3.4.3 релиз 3.5.0 готовили с расширенным тестированием
У Rsync 3.5.0 получилась необычно длинная предыстория. 20 мая версия 3.4.3 закрыла шесть CVE, после чего пользователи обнаружили серию регрессий. Уже 8 июня разработчики выпустили 3.4.4 именно для исправления этих сбоев. В официальном сообщении команда связала проблему с недостаточным покрытием тестами ветки 3.4 и ограниченными возможностями широкого бета-тестирования security-релизов.
Подготовка 3.5.0 пошла по более жёсткой схеме. Проект расширил тестовый набор, увеличил группу разработчиков с опытом в безопасности и организовал закрытый список rsync-security для дополнительного тестирования исправлений. В официальном NEWS команда пишет, что 33 проблемы нашли во время целевого аудита обработки путей и daemon-протокола, отдельного fuzzing-прохода по протоколу и анализа отчётов внешних исследователей.
У этого изменения процесса есть вполне измеримый результат: каждое из 33 security-исправлений сопровождается regression-тестом, который воспроизводит ошибку на уязвимом дереве исходного кода. Для проекта, который всего двумя месяцами ранее столкнулся с регрессиями после крупного security-релиза, такая деталь объясняет, почему версия 3.5.0 готовилась несколько месяцев.
В списке Rsync 3.5.0 одна Critical, 17 High и 15 Medium
Страница безопасности Rsync перечисляет 33 CVE, закрытых в 3.5.0. По опубликованным уровням серьёзности они распределяются так:
| Уровень | Количество | Примеры затронутых механизмов |
| Critical | 1 | Подмена адреса клиента в PROXY protocol |
| High | 17 | Выход за границы каталогов, command injection, записи за границы памяти, DoS, ошибки ACL доступа |
| Medium | 15 | Гонки с симлинками, ACL/xattr, TLS-проверка, тайм-ауты и ошибки разбора протокола |
Совокупный набор уязвимостей затрагивает выпуски до 3.4.4 включительно, хотя диапазон версий для конкретного CVE может быть заметно уже. Часть проблем проявляется только в специальных конфигурациях: например, при use chroot = no, доступном на запись daemon-модуле, использовании ограниченного аккаунта rrsync, включённом proxy protocol = true, настроенном name converter или exec hook.
Такое распределение меняет восприятие релиза. Rsync часто работает незаметно — внутри резервного копирования, зеркалирования каталогов, автоматических задач и серверных модулей. В 3.5.0 аудит прошёл именно по тем границам, где данные переходят между доверенными и недоверенными путями, пользователями и сетевыми узлами.
CVE-2026-53791 позволяет подменить адрес клиента при включённом PROXY protocol
Самая серьёзная проблема получила идентификатор CVE-2026-53791 и оценку CVSS 9.1. Она относится к конфигурации proxy protocol = true, когда rsync-daemon ожидает информацию об исходном адресе клиента от промежуточного доверенного прокси.
До 3.5.0 клиент мог подключиться к daemon напрямую и самостоятельно отправить PROXY-заголовок. Сервер принимал переданный адрес как источник соединения, поэтому атакующий получал возможность обойти ограничения, основанные на hosts allow и hosts deny.
В 3.5.0 переданный адрес учитывается только тогда, когда непосредственный узел соединения входит в настроенный список доверенных прокси. Конфигурация proxy protocol = true без proxy protocol hosts теперь работает в режиме fail-closed: соединения отклоняются, а daemon выводит предупреждение при запуске.
Уязвимость требует конкретной настройки PROXY protocol, поэтому она не описывает поведение каждой установки Rsync. Сам advisory на GitHub содержит пометку, что точная граница версии, в которой ошибка появилась, ещё уточняется; исправленной версией указана 3.5.0.
Обработка путей и симлинков стала крупнейшей зоной усиления защиты
Большая группа CVE связана с тем, как Rsync открывает файлы и проходит компоненты пути. Сценарий повторяется в разных формах: процесс с повышенными правами проверяет путь, затем другой пользователь успевает заменить один из каталогов симлинком, и последующая операция попадает за ожидаемую границу. Такой класс гонок обычно называют TOCTOU — time-of-check to time-of-use.
CVE-2026-53802 затрагивала входные файлы, которые оператор передаёт через --filter, --files-from, --include-from, --exclude-from, --password-file и несколько связанных механизмов. Подложенный симлинк мог заставить Rsync прочитать другой файл. В случае daemon-аутентификации содержимое чужого файла могло попасть в ответ, сформированный из файла пароля.
CVE-2026-53803 работала в обратном направлении и касалась выходных путей: --log-file, batch-файлов и нескольких daemon-параметров. В changelog приведён показательный сценарий, где симлинк перенаправляет запись журнала в authorized_keys, что создаёт путь к повышению привилегий при подходящих правах процесса.
Ещё несколько исправлений закрывают выход из дерева назначения или источника:
- CVE-2026-53785 — создание подразумеваемых родительских каталогов при
--relativeмогло уйти за пределы дерева назначения; - CVE-2026-53793 — симлинк внутри chroot-конфигурации с
/./позволял достичь соседнего каталога за внутренней границей модуля; - CVE-2026-53797 — гонка с родительским компонентом исходного пути могла привести к чтению файла вне исходного дерева;
- CVE-2026-53800 — при
--remove-source-filesпохожая гонка могла перенаправить удаление на файл за пределами исходного дерева; - CVE-2026-53801 — сканирование каталогов могло перечислить содержимое за пределами transfer root или daemon-модуля.
В основе исправлений лежит общий механизм: чувствительные пути теперь разрешаются покомпонентно через удерживаемые файловые дескрипторы с O_NOFOLLOW и проверкой владельца. Такой подход сокращает окно между проверкой и фактической операцией, потому что Rsync продолжает работать с уже открытым объектом каталога.
Для ACL и extended attributes картина зависит от платформы. На Linux 6.13+ используются новые *xattrat-вызовы, возможны варианты с обновлённой libacl или /proc/self/fd. На BSD, Solaris, macOS и в Linux-контейнере без /proc NEWS описывает остаточный путь через традиционные path-based операции. Эта разница в возможностях ОС остаётся частью модели безопасности 3.5.0.
rrsync жёстче удерживает ограниченный SSH-доступ внутри разрешённого каталога
rrsync — вспомогательный restricted-shell wrapper, который часто применяют для SSH-ключа с доступом только к заданному каталогу. CVE-2026-53783 получила уровень High из-за гонки между проверкой пути через realpath() и последующим запуском Rsync с тем же именем.
В 3.5.0 wrapper на Linux фиксирует проверенный объект через inode и передаёт Rsync путь, привязанный к открытому дескриптору в /proc/self/fd. Одновременно rrsync запрещает --copy-unsafe-links, принудительно включает --no-D в restricted-подкаталоге и отклоняет симлинк в --log-file.
Для дополнительного ограничения появился механизм --confine-root=DIR. Он блокирует операторский или переданный другой стороной путь, если тот разрешается за пределами указанного корня. rrsync использует этот параметр для своего ограниченного каталога, включая merge-файлы фильтров.
У inode-pinning есть платформенная граница. NEWS прямо связывает эту защиту с поведением /proc/self/fd в Linux. На BSD, macOS, Solaris и Cygwin wrapper продолжает передавать имя, прошедшее realpath()-проверку, поэтому полный набор Linux-механизмов там недоступен.
Daemon получил защиту от зависающих соединений и чрезмерного расхода CPU
Сразу несколько High-проблем связаны с доступностью rsync-daemon. Здесь особенно показателен CVE-2026-70464 с CVSS 7.5: он затрагивает версии с 2.0.0 по 3.4.4 и позволяет неаутентифицированному клиенту удерживать соединение ещё до начала передачи файлов.
Клиент мог завершить приветствие @RSYNCD, а затем бесконечно тянуть отправку строки или NUL-терминированных аргументов по одному байту. Параметр timeout не закрывал этот участок, поскольку таймер включался позднее нужных вызовов read_args(). После выбора модуля такое соединение занимало слот max connections; серия параллельных подключений могла сделать модуль недоступным для легитимных клиентов.
В 3.5.0 отдельный deadline охватывает handshake и оба ранних вызова чтения аргументов. Одновременно ограничено количество аргументов на ранней стадии протокола.
CVE-2026-70455 касается Zstandard. Клиент daemon-а мог запросить произвольное число потоков через --compress-threads; в тесте значение 256 породило 257 потоков в одном соединении. Для daemon-режима 3.5.0 ограничивает число workers восемью, сохраняя операторское значение для локального запуска и соединения через remote shell.
Ещё один High, CVE-2026-70453, связан с квадратичным расходом CPU в hash_search() при специально сформированной цепочке одинаковых слабых контрольных сумм. В новой версии длина такого прохода ограничена.
Fuzzing daemon-протокола нашёл несколько записей за границы памяти
Отдельный fuzzing-проход по daemon-протоколу выявил серию memory-safety ошибок. Разработчики специально отделили случаи с записью в память от ошибок, которые приводили только к падению процесса.
Один из самых наглядных примеров — CVE-2026-70456, High с CVSS 8.2. Если удалённый daemon-клиент формировал количество аргументов ровно на границе maxargs, операция argv[argc] = NULL записывала указатель за предел выделенного массива. На 64-битной системе речь идёт о восьми байтах. Advisory указывает диапазон затронутых версий от 3.0.1 до 3.4.4.
Рядом находятся ещё три ошибки:
- CVE-2026-70458 — запись за пределы массива при принятом флаге
FLAG_HLINKED, хотя режим-Hне был включён; - CVE-2026-70461 — однобайтовая heap out-of-bounds write в
add_implied_include()из-за неверного расчёта длины правила с завершающим обратным слешем; - CVE-2026-70457 — запись по смещению, контролируемому атакующим, в обработке ошибки для слишком больших значений
--max-size,--min-sizeили--max-alloc.
Публичные advisory описывают эти проблемы как memory corruption и указывают сетевой путь до уязвимого daemon-кода. Заявлений о подтверждённом удалённом выполнении кода в опубликованном changelog нет, поэтому уровень риска здесь задают конкретные CVE и их CVSS, без расширения последствий сверх описанного исследователями.
rsync-ssl теперь проверяет сертификат и имя удалённого узла
CVE-2026-70454 с уровнем Medium затрагивает rsync-ssl. В stunnel-режиме прежняя логика устанавливала TLS-соединение без обязательной проверки центра сертификации и без привязки сертификата к запрошенному имени хоста. При активной атаке в сети это позволяло подменить сервер.
В 3.5.0 stunnel-режим требует верификацию сертификата и проверку hostname. Отключение этой проверки вынесено в явный insecure-режим. Для GnuTLS разработчики выбрали консервативное поведение и отказываются использовать backend без подтверждённой проверки.
В changelog отдельно упоминается похожий пробел hostname verification в OpenSSL backend версий 3.2.0–3.2.3, который нашли и исправили ещё в 2020 году. Новый CVE сводит требования для актуального rsync-ssl к более строгой модели проверки удалённой стороны.
Несколько привычных сценариев Rsync 3.5.0 теперь ведут себя строже
Security-hardening затронул наблюдаемое поведение программы, поэтому 3.5.0 меняет несколько сценариев даже при отсутствии атаки.
| Сценарий | Поведение до 3.5.0 | Поведение в 3.5.0 |
| Симлинк в каталог назначения обычного receiver | Путь мог пройти через симлинк, созданный другим uid | Симлинк принимается только при доверенном владельце — root или текущем эффективном uid |
proxy protocol = true без списка доверенных прокси | Конфигурация могла принять переданный адрес | Соединения отклоняются, daemon предупреждает при старте |
rrsync в restricted-подкаталоге | Набор допустимых опций оставлял опасные комбинации | Принудительно используется --no-D, запрещён --copy-unsafe-links |
Unix socket в подкаталоге с --specials на системах без race-safe bindat() | Передача могла завершиться ошибкой | Объект пропускается с предупреждением |
| Переход через симлинк каталога внутри дерева | Поведение зависело от платформы и конкретного пути | Используется единый покомпонентный resolver с удерживаемыми дескрипторами |
Для фонового резервного копирования от root особенно заметна новая модель доверия к компонентам пути: часть CVE как раз строится на ситуации, где непривилегированный пользователь контролирует каталог, через который затем проходит процесс с большими правами. Для публичного rsync-daemon заметнее сетевые изменения — handshake deadline, ограничения потоков Zstd, проверка ACL и исправления memory-safety. Ограниченные SSH-аккаунты через rrsync получают отдельный набор confinement-механизмов.
Так Rsync 3.5.0 разделяет угрозы по реальным режимам работы программы. Наличие CVE в релизе само по себе ещё не говорит, что одинаковый сценарий доступен через локальный backup-script, SSH-передачу и публичный daemon: условия эксплуатации у каждого advisory свои.
Rsync 3.5.0 завершает многомесячный security-аудит, но часть границ остаётся платформенной
Версия 3.5.0 фиксирует результат нескольких месяцев работы над обработкой путей, daemon-протоколом и fuzzing-тестами. После проблем с регрессиями в 3.4.3 проект одновременно изменил код и процедуру проверки: расширил security-команду, тестовую базу и добавил отдельный regression-тест к каждому из 33 исправлений.
Самые заметные изменения сосредоточены вокруг доверия к пути и удалённой стороне. PROXY protocol теперь проверяет непосредственного прокси, чувствительные файловые операции привязываются к удерживаемым дескрипторам, daemon ограничивает ранний handshake и ресурсоёмкие запросы, а rsync-ssl проверяет сертификат и имя сервера.
Полная одинаковость защиты на всех поддерживаемых ОС пока недостижима: NEWS прямо описывает fallback для ACL/xattr на системах без нужных *at-примитивов и Linux-механизмы rrsync, завязанные на /proc/self/fd. Для части advisory ещё уточняются точные версии, в которых появились отдельные ошибки. Следующий показатель зрелости ветки 3.5 будет виден уже по тому, как эти новые ограничения и расширенный тестовый набор поведут себя в разных Unix-средах после массового распространения релиза.
