rsyncのアップデート手順と脆弱性｜最新3.5.1で直るCVEと配布版の確認方法

rsyncの脆弱性は2025年1月の6件で終わりませんでした。2026年に入って3.4.2から3.5.1まで5つの版が出ており、2026年8月の3.5.0だけでCVE番号33件を修正しています。2025年1月の上流3.4.1に更新した後、配布元の修正パッチも適用していない環境には、2026年に公表された脆弱性が残った状態です。この記事では、2026年10月2日時点の公式NEWSと各ディストリビューションの告知をもとに、自分の環境が該当するかの判定、版の確認方法、OS別の更新手順、すぐ更新できないときの緩和策を順に整理します。

まとめ：rsyncの最新版3.5.1と配布版で判断する更新の要点

• 上流の最新版は3.5.1（2026年9月21日）。3.5.0で33件のCVEを直し、3.5.1はその回帰修正です。
• 追加パッチのない上流3.4.0／3.4.1には、2026年5月・8月のセキュリティ修正が含まれません。配布版の修正状況と各CVEの影響範囲は個別に確認します。
• ディストリビューションの修正版は上流の版番号を据え置くため、rsync --versionが3.2.7でも修正済みの場合があります。判定はパッケージ版と変更履歴で行います。
• 2026年10月2日時点で、Debian 12とUbuntu 22.04／24.04／26.04 LTSには3.5.0分の修正が未提供です。RHELは8／9／10とも9月に修正版が出ましたが、各版で9〜12件が「修正延期」のままです。rsyncデーモンを外部に公開している場合は、提供を待たず緩和策を先に入れます。
• セキュリティ修正の直後には毎回回帰修正が出ています。更新後は-n（ドライラン）でバックアップジョブを一度流して確かめます。

以下、rsyncの動作形態から順に説明します。影響範囲は動作形態で大きく変わるためです。CVE番号とCVSSの読み方に不安がある場合は、先にCVEとCWEの違いとCVSSの読み方を確認しておくと表を追いやすくなります。

rsyncの動作形態：SSH経由とデーモン（873番ポート）で変わる攻撃面

rsync（読み方は「アールシンク」）は、転送元と転送先の差分だけを送るファイル同期ツールです。Andrew Tridgell氏らが開発し、現在はGitHubのRsyncProject/rsyncで保守されています。

接続方法は2つあります。1つはrsync -av src/ user@host:/backup/のようにSSHを経由する方法で、通信はSSHが暗号化し、相手側ではログインしたユーザーの権限でrsyncが動きます（1ファイルを送るだけならSCPコマンドの基本構文とSSH越しの転送で足りる場面もあります）。もう1つはrsync://host/moduleで接続するデーモン方式です。rsync --daemonが既定でTCP 873番を待ち受け、rsyncd.confで公開するディレクトリ（モジュール）を定義します。rsync自身のプロトコルは暗号化しません。

脆弱性の深刻度はこの違いでほぼ決まります。認証前に突ける欠陥の大半はデーモンにあり、873番をインターネットに開けているサーバーが最優先の更新対象です。SSH経由でも、悪意のある接続先、SSH認証を通過した接続元、転送対象のパスを操作できるローカルユーザーが攻撃の起点になり得ます。

rsyncの脆弱性とリリースの年表：2025年1月から2026年9月まで

上流のrsync NEWSに記載された日付で、セキュリティに関わる版を並べます。GitHubのリリース一覧でも、2026年10月2日時点の最新は3.5.1です。

2025年1月：CVE-2024-12084ほか6件と3.4.0／3.4.1

Google Cloud Vulnerability ResearchのSimon Scannell氏らが報告し、2025年1月14日に公表された6件です。最も重いCVE-2024-12084はデーモンのチェックサム解析にあるヒープバッファオーバーフローで、Red HatのCVSSv3は9.8。匿名で読めるモジュールがあれば、未認証の接続元からコード実行に至る可能性があります。CVE-2024-12085（初期化されていないスタックの漏洩・7.5）と組み合わせるとASLRを破れる点が深刻度を押し上げました。

残る4件は、悪意のあるサーバーに接続したクライアント側の問題（CVE-2024-12086のファイル読み取り、12087と12088の転送先外への書き込み）と、シンボリックリンクの競合状態（CVE-2024-12747）です。CVE-2024-12084は3.2.7で入り込んだ欠陥のため、それより前の版を積むRHEL 8／9やUbuntu 20.04は、Red HatとCanonicalが対象外と判定しています。

2026年4〜6月：3.4.2〜3.4.4とCVE-2026-29518ほか6件

3.4.2についてNEWSは「CVEは割り当てられていない」と書いています。ただし外部の採番機関が2件に番号を付けました。xattrのqsort()に渡す要素数の誤りは、MITREがCVE-2026-41035（3.0.1〜3.4.1、-Xで拡張属性を受け取る側のuse-after-free、NVDの評価は7.8）とし、files配列への不正アクセスはRapid7がCVE-2025-10158（4.3）としています。Ubuntuは5月のUSN-8283-1でこの2件も修正対象に含めました。

3.4.3で直った6件は、3件が非既定の設定でしか届きません。CVE-2026-29518（CVSS v4.0 7.3）とCVE-2026-43619はモジュールにuse chroot = noを設定したデーモン、CVE-2026-43617はdaemon chrootを設定したデーモンが対象です。use chroot = yesを明示してchrootを必須にしたモジュールでは前者2件の成立条件を外せます。3.2.7以降の未設定時はchrootを試みますが、失敗しても警告を記録して継続する場合があります。

既定設定でも届くのは2件です。CVE-2026-43618（CVSSv3.1 8.1）は圧縮トークンの復号処理の整数オーバーフローで、認証済みのデーモン接続からプロセスのメモリ（環境変数やパスワードを含む）を読み出せます。CVE-2026-43620は、悪意のあるサーバーから取得する（pull）クライアントを落とせる範囲外読み取りです。残る1件のCVE-2026-45232は、環境変数RSYNC_PROXYでHTTPプロキシを経由するクライアントが、不正なCONNECT応答を受けたときに起きるスタックの1バイト境界外書き込みです。

2026年8〜9月：3.5.0の33件の脆弱性修正と3.5.1の回帰修正

3.5.0はパス処理とデーモンプロトコルの集中監査の結果で、NEWSは「33 security issues」と書き、Debianのトラッカーでも33件のCVE（CVE-2026-53783〜53803のうち53787を除く20件と、CVE-2026-70452〜70464の13件）が3.5.0で修正済みになっています。上流がCRITICALとしたCVE-2026-53791は、proxy protocol = trueのデーモンに直接接続した相手がPROXYヘッダーで接続元IPを偽り、hosts allow／hosts denyをすり抜けられる欠陥です。ただしRed Hatの評価は7.4で、採点者によって重さが違います。

数の大半は、root権限で動くrsyncがローカルユーザーの仕込んだシンボリックリンクをたどってしまう型です。SSH経由の定期バックアップをrootで回している環境も、同じマシンに信頼できないユーザーがいれば対象になります。3.5.1ではプロトコル番号が33に上がり、3.5.0のパス処理の回帰が直りました。

自分の環境が影響を受けるかの判定：使い方別の攻撃の起点と更新優先度

CVEの件数ではなく、rsyncをどう使っているかで優先度を決めます。上から順に急ぎます。

表の「ほか2件」の内訳は、デーモン公開がCVE-2024-12084・CVE-2026-53791・CVE-2026-70464、外部サーバーからのpullがCVE-2024-12087・CVE-2024-12088・CVE-2026-43620です。

最後の行でも更新は必要です。ただ、1人で使うMacやPCからSSH経由で自分のサーバーへ送るだけなら、ディストリビューションの定期更新を待って構いません。逆に、873番を開けたまま「社内向けだから」と放置するのは最も避けるべき状態です。未認証で届く欠陥が2025年と2026年の両方に含まれているためです。

rsyncのバージョン確認の方法と、版番号だけで判定できない理由

rsync –versionの版番号とプロトコル番号による判定の限界

手元の版はrsync --versionの1行目で分かります。Debian sidのコンテナに入れた3.5.1（パッケージ版3.5.1+ds1-1）で実行した結果は次のとおりです。

$ rsync --version | head -1
rsync  version 3.5.1  protocol version 33

プロトコル番号は3.4.0で32に、3.5.1で33に上がりました。3.5.0はNEWSにプロトコル番号の変更がなく32のままです。つまり「protocol version 32」と出ても、3.4.1（3.4.3と3.5.0で直った39件が未修正）か3.5.0（修正済み）かは区別できません。

rsyncデーモンの@RSYNCD挨拶とプロトコル番号の確認

デーモンは接続直後に@RSYNCD:で始まる挨拶を返し、そこにプロトコル番号が出ます。同じコンテナで3.5.1のデーモンをポート18730で起動し、ncで接続すると次の1行が返りました（後ろのsha512〜md4はデーモン認証で使えるダイジェスト方式の一覧で、ビルド時のライブラリによって変わります）。

$ nc 127.0.0.1 18730
@RSYNCD: 33.0 sha512 sha256 sha1 md5 md4

自社サーバーの棚卸しには使えますが、判定材料は番号だけです。32なら3.4.0以降、33なら3.5.1以降と分かる程度で、次に述べるディストリビューションの修正版は見分けられません。

ディストリビューション版のバックポートと修正済みパッケージ版の確認

Debian・Ubuntu・RHELは、上流の新しい版に置き換えず、修正パッチだけを古い版に当てて配ります。DebianのDSA-6282-1は、2026年5月の6件のうち5件をDebian 12向けに3.2.7-1+deb12u5で直し、残るCVE-2026-45232は通常の更新3.2.7-1+deb12u6で直りました。どちらもrsync --versionには3.2.7と出ます。手元のOSの版の確かめ方はLinuxのバージョン確認（os-releaseとuname）にまとめています。

判定はパッケージ版と変更履歴で行います。

# Debian / Ubuntu
dpkg -s rsync | grep '^Version'
apt changelog rsync | grep -E 'CVE-2026-(43618|53791)'

# RHEL / AlmaLinux / Rocky Linux
rpm -q rsync
rpm -q --changelog rsync | grep -E 'CVE-2026-(43618|53791)'

CVE-2026-43618は2026年5月の6件、CVE-2026-53791は8月の33件の代表です。この検索は手掛かりにすぎません。代表CVEの記載の有無だけでは判断せず、インストール済みパッケージ版を各CVEの公式修正状況と照合してください。

OS別のrsyncアップデート手順と適用前に照合する修正済みパッケージ版

Debian・Ubuntu・RHEL系の修正状況（2026年10月2日時点）

各社のセキュリティトラッカーとアドバイザリで、修正を含むパッケージ版を確認した結果です（確認日：2026年10月2日。出典：Debian Security Tracker、Ubuntu CVE情報、Red HatのRHSA-2026:74095ほか）。修正状況は日々変わるので、適用前に各ページで最新の状態を確かめてください。

Debian 13は、8月分を当てるためにセキュリティ更新（DSA-6527-1）で3.5.0そのものへ上げました。Ubuntuの5月分は、LTS向けのUSN-8283-1（2026年5月20日）で直り、回帰修正のUSN-8349-2（6月8日）で表の版になりました。8月分はCVE-2026-53791などが「Needs evaluation（未判定）」のままです。

Red Hatは、RHEL 9向けRHSA-2026:67462とRHEL 10向けRHSA-2026:67463（いずれも2026年9月14日）、RHEL 8向けRHSA-2026:74095（9月30日）で修正しました。ただしCVE-2026-53796などのシンボリックリンク競合系は、3つの版とも「Fix deferred（修正延期）」です。RHEL 8ではCVE-2026-53791を含む7件が「Not affected」とされています。未修正・延期の行に当たる環境は、次章の緩和策を併用してください。

更新コマンドはいつもの手順です。

# Debian / Ubuntu
sudo apt update
sudo apt install --only-upgrade rsync

# RHEL / AlmaLinux / Rocky Linux
sudo dnf upgrade rsync

# デーモンを使っている場合は再起動（systemdのユニット名はディストリで異なる）
sudo systemctl restart rsync      # Debian / Ubuntu
sudo systemctl restart rsyncd     # RHEL系（rsync-daemonパッケージ）

デーモンは接続ごとにプロセスを分けますが、親プロセスは古いバイナリのまま動き続けます。パッケージを入れ替えただけでは修正が効かないので、再起動まで行います。

macOS：openrsync・旧2.6.9とHomebrew版3.5.1の使い分け

macOS標準の/usr/bin/rsyncは、上流の3.x系ではありません。Appleが公開しているmacOS向けrsyncのソース（apple-oss-distributions/rsync）には、OpenBSD由来の別実装openrsyncと、NEWSが「rsync 2.6.9（2006年11月）・プロトコル29」で止まった旧来のrsyncの2つが入っています。

上流rsyncとはコードの系統が違うため、2025年・2026年の上流のCVEはそのまま当てはまりません。一方で修正はAppleの更新でしか入らず、上流3.x系の新しいオプションにも対応していません。/usr/bin/rsync --versionの1行目が「rsync version 3.x」の形式でなければ上流版ではない、と判断できます。上流版が必要ならHomebrewで入れます。Homebrewのrsyncは2026年10月2日時点で3.5.1です。

brew install rsync        # 初回
brew upgrade rsync        # 2回目以降
which -a rsync            # Homebrew側が先に来ているか確認

上流rsyncは相手のプロトコル番号に合わせて低い番号で通信するため、Homebrewの3.5.1からプロトコル29の相手へ送る構成でも転送自体は成立します。Macを含むバックアップ全体の組み立てはバックアップのやり方（PC・サーバー・クラウド別）を参照してください。

配布版の修正を待てないサーバーでソースから3.5.1をビルドする手順

配布版の修正を待てないサーバーでは、上流のソースから入れる方法があります。rsyncはzstd・lz4・xxhash・OpenSSLを任意で使い、3.5.1からは国際化ドメイン名（IDN）のライブラリも使います。開発用ヘッダーが無い場合、configureは無効化オプションを示して停止する動作です。debian:sidのコンテナ（build-essentialだけを導入）で確かめたところ、--disable-idnを足した次の最小構成でconfigureとmakeが通り、rsync version 3.5.1 protocol version 33と表示されました。

curl -LO https://download.samba.org/pub/rsync/src/rsync-3.5.1.tar.gz
tar xzf rsync-3.5.1.tar.gz && cd rsync-3.5.1
./configure --disable-md2man --disable-xxhash --disable-zstd --disable-lz4 --disable-openssl --disable-idn
make
./rsync --version | head -1

ここまでの操作はビルドと版確認だけで、稼働中のrsyncは更新されません。採用する場合は配置先を決め、定期ジョブ・デーモンの実行パスを新しいバイナリへ切り替えて再確認します。この構成で使える転送用チェックサムはmd5・md4、圧縮はzlib系に限られるという制約です。相手側と速度重視の方式を交渉できなくなるので、恒久的に使うなら各ライブラリの開発パッケージを入れてから有効のままビルドします。パッケージ管理外の/usr/local/binに入れたrsyncは、以後の更新を自分で追う必要がある点も運用上の負担です。

すぐ更新できないときのrsync脆弱性の緩和策と接続元・設定の制限

NEWSに公式の回避策が書かれているものと、設定で攻撃面を減らせるものを、効果の大きい順に並べます。

1. 873番を外部に開けない。ファイアウォールで接続元を限定し、可能ならデーモンをやめてSSH経由に切り替えます。未認証で届く欠陥の大半はこれで遮断できます。
2. use chroot = yesを明示し、chrootを必須にする。CVE-2026-29518とCVE-2026-43619はuse chroot = noのモジュールでしか成立しません。
3. refuse options = compressをrsyncd.confに追加する。CVE-2026-43618に対する、NEWS記載の旧版向け回避策です。
4. proxy protocolを使うならファイアウォールでデーモンへの直接接続元を信頼するプロキシだけに限定する。CVE-2026-53791の条件を外せます。3.5.0以降はrsyncd.confのproxy protocol hostsでも信頼するプロキシを指定できますが、3.4.4以前にこの設定はありません。
5. 信頼できないサーバーからpullするクライアントでは--no-inc-recursiveを付ける。CVE-2026-43620に対するNEWS記載の回避策です。

設定例は次のとおりです。

# /etc/rsyncd.conf（抜粋）
use chroot = yes
refuse options = compress acls
hosts allow = 192.0.2.0/24
hosts deny = *

aclsを拒否しているのは、3.5.0でもmacOSやBSDではACL適用の競合状態（CVE-2026-53799）が残るとNEWSが明記し、回避策としてrefuse options = aclsを挙げているためです。緩和策は更新の代わりにはなりません。修正版が出たら置き換えます。873番を開けたサーバーや、rootで動くバックアップジョブが社内に何台あるか把握できていない場合は、一創の脆弱性診断・セキュリティ診断で、公開ポートと稼働中のrsyncの版の洗い出しから相談できます。

rsync更新後に壊れやすいバックアップの挙動と定期ジョブの確認手順

rsyncのセキュリティ修正は、ここ2年すべて回帰修正を伴いました。3.4.0の翌日に3.4.1、3.4.3の19日後に3.4.4、3.5.0の39日後に3.5.1です。UbuntuもLTS向けUSN-8283-1（2026年5月20日）とESM向けUSN-8349-1（6月1日）の後に、回帰修正のUSN-8349-2（6月8日）と-3（6月16日）を出しています。更新そのものは急ぎつつ、バックアップが黙って失敗していないかを必ず確かめます。

3.5.0で変わった4つの既定動作とバックアップが停止する条件

• 転送先に指定したシンボリックリンク（例：/backupが/mnt/diskを指す）は、所有者がrootか実行ユーザーのときだけたどります。別ユーザー所有なら拒否され、従来どおりにするには--insecure-linksが必要です。
• proxy protocol = trueでproxy protocol hostsが空だと、全接続を拒否します。
• macOS・BSD・Solarisでは、--specialsで転送する階層内のソケットファイルが警告付きで飛ばされます。
• rrsyncで制限したディレクトリでは--no-Dが強制され、--copy-unsafe-linksは拒否されます。

1つ目は、外付けディスクへのシンボリックリンクを転送先にしたバックアップで踏みやすい変更です。rootで回すジョブならリンクの所有者もrootのことが多く影響しませんが、NASのマウントポイントを一般ユーザーが作ったリンク経由で指している場合は止まります。

更新直後の定期ジョブのドライランによる転送差分・終了コードの確認

定期ジョブと同じオプションに-n（--dry-run）と--itemize-changesを足して一度流し、転送予定と終了コードを見ます。debian:sidのコンテナで3.5.1に対して実行すると、末尾に「(DRY RUN)」と表示され終了コードは0でした。

rsync -avn --itemize-changes --delete /data/ /backup/data/
echo $?

ドライランでは実際の書き込みや属性設定の成功までは確認できません。終了コードが0でも、一時ディレクトリへの小規模な実転送と復元確認を行ってください。終了コードが0以外なら、ログの先頭のエラーから原因を探します。3.5.0以降でリンクの所有者を理由に止まる場合は、--insecure-linksを足す前にリンクの所有者をrootへ変えるほうが安全です。

rsync -u（–update）オプションとソフトウェア更新の違い

「rsync update」で検索すると、rsync本体の更新ではなく-u（--update）オプションの説明が出ることがあります。-uは「転送先のほうが新しいファイルは上書きしない」指定で、脆弱性とは無関係です。

転送先d/f（中身newer・2026年9月1日更新）が転送元s/f（中身old・2026年1月1日更新）より新しい状態で、debian:sidのコンテナ（rsync 3.5.1）で実行した結果です。

$ rsync -avu s/ d/
sending incremental file list
$ cat d/f
newer

ファイル一覧に何も出ず、転送先の内容が残りました。同じファイルで-uを外すと、転送元の古い内容で上書きされました。双方向で編集が入るディレクトリを片方向に同期するとき、先祖返りを防ぐのが用途です。更新日時だけで判定するため、時計のずれたサーバー間では期待どおりに動きません。

よくある質問

rsyncの脆弱性と更新について、検索で多い質問に答えます。

rsyncの読み方は？

「アールシンク」と読みます。remote synchronization（リモート同期）の略で、公式サイトはrsync.samba.orgです。開発元はすべて小文字のrsyncと表記しており、コマンド名にも同じ表記を使います。2026年9月21日の3.5.1が最新版です。Linuxのほとんどのディストリビューションに標準で入っており、macOSでは同名のコマンドとしてopenrsyncが入っています。

rsyncの通信は暗号化されますか？

SSH経由（user@host:/pathの形式）なら、SSHが通信を暗号化します。デーモン方式（rsync://やhost::module）ではrsync自身は暗号化せず、パスワード認証もチャレンジ・レスポンスでデータ本体は平文です。インターネット越しに使うならSSH経由にするか、同梱のrsync-sslでTLSを使います。なおrsync-sslのstunnelモードは3.4.4以前では証明書を検証していなかったため（CVE-2026-70454）、使うなら3.5.0以降にします。

rsync –versionで3.2.7と出ますが脆弱ですか？

ディストリビューションのパッケージなら、それだけでは判断できません。Debian 12は3.2.7-1+deb12u6、Ubuntu 24.04は3.2.7-1ubuntu1.5で2026年5月の6件を修正済み（回帰修正込み）で、どちらも--versionには3.2.7と出ます。dpkg -s rsyncやrpm -q rsyncでパッケージ版を見て、変更履歴にCVE番号があるかを確かめてください。自分でビルドした上流の3.2.7なら、2025年と2026年の修正はすべて未適用です。

Macのrsyncはアップデートしたほうがいいですか？

標準の/usr/bin/rsyncはopenrsyncまたは旧2.6.9系で、上流rsyncの2025年以降のCVEは直接は当てはまりません。更新はmacOSのアップデートでしか入らないため、OSを最新に保つことが対策になります。--info=progress2など上流rsyncにしか無いオプションが必要な場合だけ、Homebrewで3.5.1を入れてwhich -a rsyncで優先順位を確認します。

rsync -avuのオプションはどういう意味ですか？

-aはアーカイブモードで、再帰コピーに加えてパーミッション・所有者・更新日時・シンボリックリンクを保ったまま転送します（-rlptgoDと同じ）。-vは転送したファイル名を表示する指定、-uは転送先のほうが新しいファイルを上書きしない指定です。組み合わせると「属性を保ってコピーし、相手側で新しく編集されたファイルは残す」動きになります。

関連記事

• SCPコマンドとは？基本構文・主要オプション・SSH越しの安全なファイル転送を実装者向けに解説【2026年版】：単発のファイル転送
• Linuxのバージョン確認：os-releaseとunameの使い分けとコンテナでの注意点：トラッカーと照合するOSの版の確認
• Linuxコマンド一覧｜用途別早見表48選とUbuntu 26.04での変更点：rsync以外のよく使うコマンド
• バックアップのやり方｜PC・サーバー・クラウド別の手順と企業の運用設計【2026年】：rsyncを組み込むバックアップ設計
• AWS DataSyncとは？転送の仕組み・EnhancedとBasicの違い・料金と採用判断を実装者目線で解説：クラウドへの大量転送の代替