Дата в файле NEWS — 13 августа 2026, анонс разошёлся вечером 12-го. Релиз rsync 3.5.0 закрывает 33 уязвимости: это результат целенаправленного аудита работы с путями и протокола демона, а не обычная порция багфиксов. Одна дыра помечена как CRITICAL, семнадцать — HIGH.
Инструмент, который на домашнем сервере обычно живёт в трёх строчках cron и о котором не вспоминают годами, внезапно требует внимания. Разберём по ролям: риск сильно зависит от того, как именно у вас запущен rsync.
В благодарностях к релизу — исследователи Trail of Bits и Google Cloud, плюс независимые репортёры. Полный список CVE с описаниями лежит в официальном NEWS на download.samba.org; всё, что ниже, взято оттуда.
Роль 1. Просто rsync -a между своими машинами по SSH
Самый частый сценарий: ноутбук → домашний сервер, сервер → внешний диск. Здесь оба конца ваши, и злоумышленнику надо сначала попасть на одну из машин.
Риск умеренный, но не нулевой. Часть багов срабатывает, когда удалённая сторона враждебна, а не когда враждебен клиент. Например, CVE-2026-53789 (MEDIUM) — вредоносный демон-отправитель мог расширить область действия --delete на приёмнике; CVE-2026-70462 (MEDIUM) — сторона-пир подсовывала MSG_IO_TIMEOUT и тем самым отключала ваш собственный таймаут ввода-вывода. То есть достаточно один раз синхронизироваться с чужим зеркалом.
Отдельно: CVE-2026-70454 (MEDIUM) — rsync-ssl устанавливал TLS-соединение без аутентификации. Если вы пользовались обёрткой rsync-ssl, считайте, что защиты там не было.
Роль 2. Поднят rsyncd (демон на 873/tcp)
Здесь всё серьёзнее — большинство из 33 находок относится именно к демону. Ключевое:
| CVE | Уровень | Суть |
|---|---|---|
| CVE-2026-53791 | CRITICAL | при proxy protocol = true клиент мог подделать адрес источника |
| CVE-2026-70452 | HIGH | hosts deny «открывался», если имя хоста не резолвилось |
| CVE-2026-70463 | HIGH | auth users игнорировал документированный разбор списка через запятую |
| CVE-2026-70456 | HIGH | запись за границами кучи в read_args() |
| CVE-2026-70461 | HIGH | однобайтовая запись за границей в add_implied_include() |
| CVE-2026-70455 | HIGH | клиент мог запросить произвольное число потоков Zstandard (--compress-threads) |
| CVE-2026-70464 | HIGH | неаутентифицированный пир вешал дочерний процесс навсегда |
| CVE-2026-53784 | HIGH | побег из корня модуля при use chroot = no |
Три верхние строки — это не переполнения, а именно обход контроля доступа: и hosts deny, и auth users, и подделка адреса источника означают, что ваши ACL могли не работать так, как написано в конфиге.
Публичный rsyncd без аутентификации в 2026 году — это в принципе анахронизм. Если он у вас смотрит наружу, обновление стоит совместить с переносом за WireGuard или на SSH-транспорт. hosts allow в rsyncd.conf после CVE-2026-70452 больше не выглядит как надёжный периметр.
Роль 3. rrsync в authorized_keys — приёмник бэкапов
Классика: ключ клиента прописан с command="rrsync -wo /srv/backup", чтобы он мог только заливать бэкап и ничего больше. CVE-2026-53783 (HIGH) — побег из ограниченного каталога, то есть ровно та граница, ради которой rrsync и ставится.
В 3.5.0 поведение ужесточили: support/rrsync в ограниченном подкаталоге теперь принудительно включает --no-D и запрещает --copy-unsafe-links.
Что изменилось в поведении (может сломать ваши скрипты)
- Приёмник вне режима демона идёт по символической ссылке на каталог назначения только если ссылка принадлежит root или текущему пользователю; ссылка, созданная другим uid, теперь отклоняется.
proxy protocol = trueбезproxy protocol hostsтеперь отвергает все соединения (fail-closed) — раньше пропускал.- Вложенный unix-сокет, передаваемый под
--specials, на платформах без гонко-безопасного создания сокета в подкаталоге пропускается с предупреждением, а не валит весь трансфер.
Первый пункт — самый вероятный источник «внезапно сломалось». Если у вас точка назначения бэкапа — симлинк, созданный от имени сервисного пользователя, а rsync запускается от другого, перенос молча перестанет работать. Проверяйте вывод, а не только код возврата.
Как обновляться
rsync --version— на обоих концах. Обновлять надо и клиент, и сервер: часть уязвимостей эксплуатируется «с той стороны».- В стабильных дистрибутивах пакет ещё поедет: Debian/Ubuntu обычно бэкпортируют патчи в старую версию, поэтому ориентируйтесь на changelog пакета, а не на номер 3.5.0.
- В контейнерных бэкап-стеках (
rsyncвнутри образа) пересоберите образ — базовый слой сам не обновится. - Если rsyncd смотрит в интернет и обновиться прямо сейчас нельзя: закройте 873/tcp фаерволом до обновления. Это дешевле, чем разбирать последствия.
Тема про то, как вообще устроить бэкапы на домашнем сервере, у нас была отдельно — дорожная карта от первого контейнера к отказоустойчивости.
Источники
- rsync NEWS, раздел 3.5.0 (первоисточник) — NEWS for rsync
- Phoronix, «Rsync 3.5 Released As “Extraordinary” Update To Fix 33 Security Issues», 12.08.2026 — https://www.phoronix.com/news/Rsync-3.5
- Исходники и зеркала — https://rsync.samba.org/
У кого rsyncd до сих пор торчит наружу — и почему не переехали на SSH-транспорт? Интересны реальные причины, а не «руки не дошли»: бывают сценарии, где демон правда удобнее.