13 августа 2026 года вышел rsync 3.5.0, на сайте проекта его называют крупным выпуском безопасности: закрыто 33 уязвимости, обновиться просят всех. Но не каждая из 33 дыр касается вашего скрипта бэкапа. Одни срабатывают только у демона с особыми настройками, другие требуют локального пользователя, который может подложить символическую ссылку, третьи доступны по сети.
Подробности есть в NEWS, отдельные отчёты на странице уязвимостей и в GitHub Security Advisories. Номера CVE выдавал VulnCheck. Разработчики сами предупреждают: у многих уязвимостей диапазон версий намного уже, чем «всё до 3.5.0», так что перед паникой смотрите конкретный отчёт.
Что затронуто
Формально уязвимы все выпуски до 3.4.4 включительно, если отчёт не сужает окно. Версия 3.4.4 вышла 8 июня 2026 года и чинила регрессии после выпуска безопасности 3.4.3 от 20 мая. То есть свежий пакет, поставленный летом, тоже нужно обновлять.
Смотреть стоит на то, как rsync работает у вас. Обычный rsync -a по SSH для бэкапа или выкладки сайта без демона: риск выше, если процесс идёт от root, а в дереве есть каталоги, куда пишет другой пользователь. Демон на порту 873 и rsync://: здесь уже сетевые атаки на протокол, ACL и рукопожатие. Ограниченный доступ через rrsync по SSH: для него есть отдельная серьёзная дыра. И rsync-ssl, где TLS работал без нормальной проверки сертификата.
Одна критичная: подмена адреса через PROXY
CVE-2026-53791 касается демона с proxy protocol = true. Клиент, подключившийся напрямую, а не через доверенный прокси, мог сам прислать заголовок PROXY и выдать себя за чужой IP. Тогда hosts allow и hosts deny проверяли не тот адрес. Теперь пересланный адрес принимается только от настроенного прокси. Если proxy protocol вы не включали, эта уязвимость вас не касается.
Запись и чтение мимо дерева через ссылки
Самая большая группа. Локальный пользователь, который управляет частью пути, подкладывает символическую ссылку, и rsync с повышенными правами идёт по ней.
CVE-2026-53802 позволял читать чужие файлы через ссылки в —filter, —files-from и —password-file. CVE-2026-53803 давал записать файл мимо дерева, в том числе через —log-file и —write-batch. CVE-2026-53785 уводил создание родительских каталогов при —relative. Есть ещё гонки при установке ACL и xattr и удаление файлов вне источника при —remove-source-files.
Исправление общее: путь теперь проходят по одному компоненту через openat с O_NOFOLLOW, а ссылку принимают, только если её владелец root или тот же пользователь, от которого запущен rsync. Это не одна правка в условии, а новый способ обхода дерева.
Демон по сети: память, зависания и ACL
Часть уязвимостей нашли при проверке протокола демона, в отчётах участвовал Грег Кроа-Хартман. CVE-2026-70461, CVE-2026-70458 и CVE-2026-70456: запись за границу буфера, до которой можно дотянуться по сети.
CVE-2026-70464: клиент без авторизации мог пройти приветствие и бесконечно тянуть время, занимая слоты подключений. CVE-2026-70453: квадратичная нагрузка на процессор в hash_search(), о ней как о проблеме производительности писали ещё в 2021 году. CVE-2026-70452: hosts deny пропускал хост, если имя из правила не резолвилось. CVE-2026-70463: правило auth users неправильно разбирало имена групп с пробелом.
rrsync и rsync-ssl
CVE-2026-53783: rrsync проверял путь через realpath(), а потом запускал rsync по старому имени, и между проверкой и запуском оставалось окно. Теперь проверенный путь закрепляется по inode. Это работает только на Linux: на BSD, macOS, Solaris и Cygwin обёртка по-прежнему передаёт имя после realpath(), об этом прямо сказано в NEWS.
CVE-2026-70454: rsync-ssl в режиме stunnel не требовал проверки сертификата и его привязки к имени хоста. Теперь проверка обязательна, пока её явно не отключили.
Что может сломаться после обновления
Приёмник теперь идёт по ссылке, только если её владелец root или пользователь, от которого запущен rsync. Чужая ссылка на /backup больше не сработает. Старое поведение возвращает —insecure-links, но включайте его, только если понимаете зачем.
rrsync в ограниченном каталоге принудительно ставит —no-D и запрещает —copy-unsafe-links. На системах без нужных примитивов ACL иногда применяются по пути, для демона это можно закрыть через refuse options = acls.
Как проверить и обновить
rsync --version # Debian и Ubuntu apt-cache policy rsync sudo apt update && sudo apt install --only-upgrade rsync # Fedora и RHEL rpm -q rsync sudo dnf upgrade rsync
Если пакет в репозитории всё ещё 3.4.x, дождитесь обновления безопасности дистрибутива, обычно исправления переносят в его ветку. Собирать из исходников на рабочем сервере стоит, только если репозиторий молчит слишком долго. С тех пор вышли 3.5.1 с исправлением регрессий и 3.5.2, так что из исходников лучше брать последнюю версию.
Если у вас работает демон, после обновления перезапустите службу. Имя юнита зависит от дистрибутива:
systemctl list-units --type=service --all | grep -i rsync
Что проверить в настройках
Не держите порт 873 открытым в интернет без нужды, для выкладки сайта хватает rsync по SSH. Не выключайте use chroot ради удобства: с use chroot = no часть уязвимостей опаснее. Не включайте proxy protocol без доверенного прокси. Если cron от root копирует дерево, куда пишут другие пользователи, запускайте копирование от отдельного пользователя. Как я сам использую rsync для бэкапов и синхронизации WordPress, описано в отдельном руководстве.
Рядом с rsync на сервере почти всегда работает SSH, его тоже стоит держать свежим: недавно вышел OpenSSH 10.5. Общие правила защиты есть в коротком гайде по Debian и Ubuntu.
rsync 3.5.0 меняет сам способ обхода путей и закрывает пачку сетевых дыр в демоне. Для бэкапов от root и открытого порта 873 это не косметика. Проверьте версию, поймите, работает ли у вас демон, и поставьте обновление из репозитория, как только оно появится.
