13 августа 2026 года вышел Rsync 3.5.0. На сайте проекта это названо major security release: закрыты 33 уязвимости. Обновить просят всех, но не все 33 дыры живут в каждом скрипте деплоя. Часть бьёт только демон с нестандартным конфигом, часть, локального пользователя, который может подложить symlink, часть, уже по сети.
Полный разбор, в NEWS 3.5.0. Отдельные отчёты, на странице advisories и в GitHub Security Advisories. CVE выдавал VulnCheck как CNA. Диапазон «сломано во всех версиях до 3.5.0» проект сам называет слишком широким: у многих номеров диапазон уже, смотрите advisory перед паникой.
Что затронуто
Официально: все релизы вплоть до 3.4.4 включительно, если конкретный advisory не сужает окно. 3.4.4 вышел 8 июня 2026 и чинил регрессии после security-релиза 3.4.3 (20 мая). То есть даже свежий пакет «я же только что обновлялся» к 3.5.0 не относится.
На практике смотреть не на заголовок «33 CVE», а на роль rsync на машине.
- Обычный
rsync -aпо SSH для бэкапа или выкладки сайта, без демона. Риск выше, если процесс идёт от root, а в дереве есть каталоги, куда пишет другой пользователь. - Демон на порту 873, зеркала,
rsync://. Здесь уже сеть: протокол, ACL, handshake, compress. - Ограниченный доступ через
rrsyncпо SSH. Для него отдельный HIGH: побег из restricted-каталога. rsync-ssl. Отдельный MEDIUM: TLS без нормальной проверки сертификата.
Известных массовых атак в анонсе нет. Это не повод держать демон на 873 в интернете «потому что всегда так стояло».
Какие дыры важны руками
Один CRITICAL: подмена адреса через PROXY
CVE-2026-53791. Если в демоне включено proxy protocol = true, клиент мог прислать PROXY-заголовок сам и представиться чужим IP. Host-based ACL (hosts allow / hosts deny) тогда смотрел не туда. Теперь подмену принимают только с настроенного доверенного прокси. Поведение тоже ужесточили: proxy protocol = true без списка хостов с 3.5.0 режет все соединения и пишет предупреждение при старте.
Если прокси-протокол не включали, этот номер вас не касается.
Запись мимо дерева через symlink
Большой пласт, HIGH и MEDIUM. Локальный пользователь подкладывает symlink в компонент пути. Привилегированный rsync идёт за ним.
Примеры из NEWS: CVE-2026-53802 читает произвольный файл через symlink в --filter / --files-from / --password-file. CVE-2026-53803 пишет мимо дерева, в том числе в --log-file (в advisories прямо разбирают дописывание в authorized_keys). CVE-2026-53785 уводит создание родителей при --relative. Есть побег из модуля демона при use chroot = no, гонки на --temp-dir / --link-dest, произвольный ACL через -A/-X, удаление источника мимо дерева при --remove-source-files.
Фикс общий: путь разбирают по компонентам через openat(O_NOFOLLOW), symlink принимают только если его владелец root или текущий euid. На Linux 5.6+ ещё openat2(RESOLVE_BENEATH). Это не «ещё один патч в одном if», а смена того, как rsync ходит по дереву.
Демон по сети: память, DoS, ACL
Отдельный набор нашёл проход по протоколу демона, в том числе Грег Кроа-Хартман. Это уже не «нужен локальный пользователь».
- CVE-2026-70461, CVE-2026-70458, CVE-2026-70456: запись за границу кучи по проводу (HIGH).
- CVE-2026-70464: неаутентифицированный handshake можно растянуть так, что дочерний процесс висит и упирается в
max connections. Параметрtimeoutэто раньше не покрывал. - CVE-2026-70453: квадратичный жор CPU в
hash_search()на цепочке одинаковых слабых checksum. Баг как производительность знали с 2021 (issue #217), как security закрыли сейчас. - CVE-2026-70452:
hosts denyпри нерезолвящемся имени открывался, а не закрывался. - CVE-2026-70463:
auth usersигнорировал документированный разбор только по запятым, правилоdeny/:roс пробелом в имени группы не срабатывало.
Ещё HIGH на инъекцию в незакавыченные подстановки (RSYNC_CONNECT_PROG, exec-hook, rsync-ssl) и на побег модуля через peer-supplied --partial-dir / --backup-dir.
rrsync и rsync-ssl
CVE-2026-53783 (HIGH): rrsync проверял путь через realpath(), а запускал rsync по старому имени (окно TOCTOU), плюс оставлял опасные опции. Теперь путь пинят по inode. Пин завязан на Linux /proc/self/fd. На BSD, macOS, Solaris, Cygwin обёртка по-прежнему отдаёт имя после realpath(), это прямо написано в NEWS.
CVE-2026-70454 (MEDIUM): rsync-ssl в режиме stunnel не требовал проверку CA и привязку сертификата к имени хоста. Теперь проверка обязательна, пока её явно не отключили. Бэкенд GnuTLS в сомнительном режиме отказали консервативно.
Что ломается после обновления
Не-демонный приёмник следует по symlink-назначению, только если symlink принадлежит root или тому uid, от которого запущен rsync. Чужой symlink на /backup больше не примут. Старое поведение возвращает --insecure-links (для модуля, insecure links = yes).
В restricted-каталоге rrsync теперь форсирует --no-D и запрещает --copy-unsafe-links. Обычный rsync -a при этом должен продолжить работать: семантика устройств просто срезается.
На BSD, macOS, Solaris вложенный unix-сокет под --specials могут пропустить с предупреждением, а не валить весь трансфер: bindat() там нет.
Остаточный риск на не-Linux: применение ACL/xattr иногда всё ещё идёт по пути, если нет fd-примитивов. Для демона это можно закрыть refuse options = acls. Смотрите advisory конкретной дыры, не обобщайте «везде осталось дыряво».
Как проверить версию и обновить
Сначала посмотрите, что стоит. Команда одна на всех:
rsync --version
В первой строке будет номер. Нужен 3.5.0. Если меньше, в том числе 3.4.4, пакет ещё старый.
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.5.0 уже лежит в каждом репозитории. Если policy показывает всё ещё 3.4.x, ждите security-апдейт дистрибутива. Собирать tarball руками на проде имеет смысл только если репозиторий молчит слишком долго и вы понимаете зависимости. Официальный архив: rsync-3.5.0.tar.gz плюс подпись. Для тех, кто не может прыгнуть на 3.5 сразу, на сайте выложены патч-сеты на 3.2.7 и 3.4.1.
Если крутите демон, после обновления пакета перезапустите сервис. Имя юнита зависит от дистрибутива, сначала найдите его:
systemctl list-units --type=service --all | grep -i rsync
Перед правкой rsyncd.conf сохраните копию. Не отключайте chroot «чтобы завелось»: use chroot = no как раз расширяет поверхность нескольких HIGH.
Что проверить в конфиге и скриптах
- Демон в интернете без нужды: закройте 873 снаружи. Для выкладки сайта обычно хватает rsync по SSH.
use chroot: оставляйте включённым, если нет железной причины.proxy protocol: если не стоит доверенный прокси, не включайте. Если включено, задайте хосты, иначе 3.5.0 просто не пустит никого.- Cron от root в дерево, куда пишут другие uid: это как раз модель symlink-гонок. Либо отдельный пользователь без лишних прав, либо дерево, куда посторонний не пишет.
- Назначение-symlink на чужом uid: после обновления трансфер могут отказать. Это ожидаемо, не «сломанный пакет».
rrsyncвauthorized_keys: обновите и клиентскую обёртку, и бинарник. На не-Linux пина inode нет, читайте NEWS.- Скрипты с
rsync-ssl: после обновления самоподписанный сертификат без явного insecure-флага перестанет проходить. Это исправление, не регрессия.
Отдельно: rsync в cron на VPS часто соседствует с SSH. Свежий OpenSSH тоже не помешает, про релиз 10.5 уже писали. Общая гигиена сервера: короткий гайд по Debian/Ubuntu.
Вывод
3.5.0, это не «ещё один минор с багфиксами». Это смена того, как rsync режет пути, плюс пачка сетевых дыр в демоне. Для бэкапа от root и для публичного 873 обновление не косметика.
Не надо читать все 33 advisory вслух. Надо: посмотреть rsync --version, понять, демон у вас или только SSH, не держать use chroot = no и proxy protocol без нужды, и не объявлять 3.4.4 «уже безопасным». Когда пакет 3.5.0 появится в репозитории, ставьте его. Пока его нет, смотрите advisory дистрибутива, а не случайный пересказ «33 дыры в любом rsync».
