Дата в файле 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 (первоисточник) — https://download.samba.org/pub/rsync/NEWS
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-транспорт? Интересны реальные причины, а не «руки не дошли»: бывают сценарии, где демон правда удобнее.
Вы можете написать сейчас и зарегистрироваться позже.
Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.
Дата в файле 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 находок относится именно к демону. Ключевое:
proxy protocol = trueклиент мог подделать адрес источникаhosts deny«открывался», если имя хоста не резолвилосьauth usersигнорировал документированный разбор списка через запятуюread_args()add_implied_include()--compress-threads)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.Что изменилось в поведении (может сломать ваши скрипты)
proxy protocol = trueбезproxy protocol hostsтеперь отвергает все соединения (fail-closed) — раньше пропускал.--specials, на платформах без гонко-безопасного создания сокета в подкаталоге пропускается с предупреждением, а не валит весь трансфер.⚠️ Осторожно
Первый пункт — самый вероятный источник «внезапно сломалось». Если у вас точка назначения бэкапа — симлинк, созданный от имени сервисного пользователя, а rsync запускается от другого, перенос молча перестанет работать. Проверяйте вывод, а не только код возврата.
Как обновляться
✅ Как правильно
rsync --version— на обоих концах. Обновлять надо и клиент, и сервер: часть уязвимостей эксплуатируется «с той стороны».rsyncвнутри образа) пересоберите образ — базовый слой сам не обновится.Тема про то, как вообще устроить бэкапы на домашнем сервере, у нас была отдельно — дорожная карта от первого контейнера к отказоустойчивости.
Источники
💬 Вопрос к сообществу
У кого rsyncd до сих пор торчит наружу — и почему не переехали на SSH-транспорт? Интересны реальные причины, а не «руки не дошли»: бывают сценарии, где демон правда удобнее.
TOP HOSTERS: KAMATERA (30 дней бесплатного теста!)
Универсальный хостер №1 - 4VPS.su (2Гб\с сервера) - 10% скидка на первый заказ или 15% бонус на первое пополнение