sudo-rsとは｜Ubuntu 26.04・26.10既定のRust製sudoとの違い・脆弱性・元に戻す手順

sudo-rsは、Linuxの権限昇格コマンドsudoとsuをRustで書き直した実装です。Ubuntu 25.10で既定のsudoになり、2026年4月23日リリースのUbuntu 26.04 LTSと、2026年10月15日にリリースされたUbuntu 26.10にも引き継がれています。普段どおりsudoと打てば、中身はRust版です。

この記事では、2026年10月31日時点の最新版0.2.15と各ディストリビューションの収録版、従来のsudoと挙動やオプションが変わる箇所、公表済みの脆弱性6件と修正の配信状況、元のsudoへ戻す手順を整理します。10月20日に配信されたUbuntu 26.10向けの修正（USN-8708-2）と、その確認方法も加えました。根拠はsudo-rsのGitHubリポジトリ（ソースコード・CHANGELOG・セキュリティアドバイザリ）と、Ubuntuの配布パッケージ、セキュリティ通知、Launchpadのバグ票です。

まとめ：sudo-rsの現状と押さえるべき変更点（2026年10月時点）

• 開発は非営利団体Trifecta Tech Foundation。対応OSはLinuxとFreeBSDのみ
• 最新版は0.2.15（2026年8月31日）。Ubuntu 26.04の収録版は0.2.13-0ubuntu1.2、Ubuntu 26.10は0.2.14-1ubuntu4.1
• Ubuntuではupdate-alternativesの優先度でsudo-rs（50）が従来のsudo（40）に勝つため、既定でRust版が動く
• 従来と変わる主な点は、パスワード入力時の*表示が既定オン、sudo -Eが警告付きで無視、sudoersの引数ワイルドカードは末尾の*だけ、の3つ
• 直近の脆弱性はsudoeditのシンボリックリンク競合（GHSA-f42v-x7gq-phc8）。0.2.8〜0.2.14が該当し、Ubuntu 26.04は9月1日のUSN-8708-1、Ubuntu 26.10は10月20日のUSN-8708-2で修正版が配信済み
• 元のsudoへ戻すにはsudo update-alternatives --config sudoで/usr/bin/sudo.wsを選ぶ

sudoersに正規表現・LDAP・メール通知・入出力ログを使っている環境は、sudo-rsのままでは要件を満たせません。設定の書き換えでは補えない機能なので、移行前に代替手段を用意するか、従来のsudoを使い続けてください。26.10を10月20日より前に入れたマシンは、aptで更新が適用済みかを先に確かめましょう。

sudo-rsの開発体制とコード規模から見る保守方針と監査の実績

sudo-rsは、Let’s Encryptを運営するISRGのメモリ安全プロジェクト（Prossimo）として始まり、Tweede golfとFerrous Systemsが開発しました。2024年7月から所有・保守はTrifecta Tech Foundationで、Canonicalも2025年の資金提供元に名を連ねています。ライセンスはMITとApache 2.0のデュアルです。

公式FAQに見るsudo-rsのコード規模とunsafeの割合

公式FAQによると、sudo-rsは約40,000行のRustコードのうち25,000行がテストで、本番コードは約15,000行です。そのうちunsafeブロックは350行未満で、主にsetuidやPAMなどCライブラリとの境界にあります。対して従来のsudo（Todd Miller氏が保守するC実装）は180,000行を超えます。

規模が小さいのは、使われない機能を最初から実装しない方針のためです。メール送信やネットワーク接続は意図的に持たず、use_ptyとenv_resetは主要ディストリの従来sudoで有効化されていたため既定オンにしています。

外部監査2回の結果と、原典sudoの脆弱性が波及しなかった例

外部監査はRadically Open Securityが2回実施しています。2023年8月のv0.2.0監査では、セッションファイルのパストラバーサル（CVE-2023-42456）が見つかり、同じ問題が従来のsudoにもあったため双方で修正されました。2025年8月のv0.2.8監査では新しい脆弱性は出ていません。

機能を絞った効果もあります。従来sudoの--chrootを悪用するCVE-2025-32463と、ホスト指定を迂回するCVE-2025-32462は、該当機能を持たないsudo-rsには影響しませんでした。一方で、sudo-rsにも論理の誤りによる脆弱性は出ています（後述）。

sudo-rsのリリース履歴と運用上の変更（0.2.10〜0.2.15）

sudo-rsは1〜4か月おきに版が上がり、そのたびに対応オプションやsudoersの解釈が変わります。ディストリビューションごとに収録版が違うため、「どの版から使えるか」が実務では問題になります。CHANGELOGから運用に効く変更を抜き出しました。2026年10月31日時点で、GitHubのリリース一覧の最新は0.2.15のままです。

0.2.15の変更：sudoeditのTOCTOU修正、log_allowed、timestamp_type=ppid。

0.2.14の変更：runcwd、行継続の誤解析修正、suで空パスワードの相手へ切替可。

0.2.11では認証記録（タイムスタンプ）の形式が変わり、それより前の版で作られた記録はアップデート後に無効になります。アップデート直後に一度だけパスワードを再入力させられるのはこのためで、不具合ではありません。0.2.15のDefaults !log_allowedは、許可されたコマンドの実行をシステムログに書かない設定です。監査ログを取っているサーバーでは入れないでください。

Ubuntu 26.04・26.10でsudo-rsが既定になる仕組み

Ubuntuでは、ソースパッケージrust-sudo-rsから作られるsudo-rsパッケージがRust版を提供します。Launchpadで確認した2026年10月31日時点の収録版です。26.10はリリース時の0.2.14-1ubuntu4（9月23日）に、10月20日付で0.2.14-1ubuntu4.1が重なりました。

Ubuntu 25.10はサポートが終わっており、後述するsudoeditの脆弱性（0.2.8以降が該当）の修正は配信されません。25.10のまま運用しているマシンは、公式にサポートされるアップグレード先の26.04 LTSへ更新してください。Ubuntu 24.04のuniverseにある0.2.2はsudoeditを持たない初期の版で、アドバイザリ2件（CVE-2025-46717・46718）が該当します。24.04で試す場合、x86-64 Linux向けの公式tarballで修正済み版を導入できますが、以後の更新は自分で管理する必要がある点に注意してください。26.04全体の変更点はUbuntu 26.04 LTS（Resolute Raccoon）の解説、言語処理系やサポート期間など開発者向けの差分はUbuntu 26.04 LTS 開発者向け詳細、コマンド群のRust実装への切り替えはUbuntu 26.04での変更点を含むLinuxコマンド一覧にまとめています。

update-alternativesの優先度50と40による既定版の選択

Ubuntu 26.04のsudo-rsパッケージは、インストール時に/usr/lib/cargo/bin/sudoを優先度50で/usr/bin/sudoの候補に登録します。従来のsudoパッケージ（1.9.17p2）は、C版を/usr/bin/sudo.wsという名前で置き、優先度40で登録する仕組みです。自動モードでは数値の大きい方が選ばれるので、両方が入っていてもRust版が動きます。Ubuntu 26.10でもsudoパッケージ（1.9.17p2-7ubuntu5）がsudo-rsを推奨パッケージに指定しており、同じ構成です。

切り替わるのはsudo・visudo・sudoeditとそのmanページだけです。suは対象外で、Rust版はsu-rsというコマンド名で同梱されます。今どちらが動いているかは次で確認できます。

update-alternatives --display sudo
sudo -V | head -n 1

sudo -Vの1行目がsudo-rsで始まればRust版、Sudo version 1.9.17p2のように出れば従来版です。

元のsudo（sudo.ws）へ戻す手順と手動モードでの固定方法

従来版が入っていなければ先にsudoパッケージを入れ、alternativesでsudo.wsを選びます。

sudo apt install sudo
sudo update-alternatives --config sudo
# 対話なしで固定する場合
sudo update-alternatives --set sudo /usr/bin/sudo.ws
# 優先度どおりの自動選択（sudo-rs）に戻す場合
sudo update-alternatives --auto sudo

--setや--configで選ぶと手動モードになり、パッケージ更新で勝手にsudo-rsへ戻ることはありません。リモートのサーバーで作業するときは、rootシェルを別セッションで開いたまま切り替えてください。sudoersの解釈差でsudoが使えなくなった場合も、開いておいたrootシェルから設定や実装の選択を戻せます。

通常は両実装で同じsudoersを読みますが、sudo-rs専用の設定ファイルも使用できます。sudo-rsは/etc/sudoers-rsがあればそちらを、無ければ/etc/sudoersを読みます。

ディストリビューション別の導入コマンドと収録版・呼び出し名の違い

Ubuntu以外の多くのディストリビューションは、従来のsudoと衝突しないようsudo-rsという別名で入れます。各パッケージリポジトリの2026年10月14日時点の版です。

NixOSの有効化設定：security.sudo-rs.enable = true;。

Debian 13の0.2.5は2025年4月の版で、セキュリティ修正は取り込まれているもののsudoeditやNOEXEC:、-A・-bがありません。さらにパッケージの設定不備でsu-rsにsetuidビットが付いておらず使えないと、公式READMEに明記されています。Debianでsudoの名前のまま呼びたい場合は/usr/lib/cargo/binをPATHの先頭に足します。ただし、絶対パスで/usr/bin/sudoを呼ぶ処理や、独自のPATHを使うサービスは従来版のままです。

公式のビルド済みtarballはx86-64 Linux向けのみで、/usr/localに展開します。従来sudoが入っていない環境では/etc/pam.d/sudoと/etc/pam.d/sudo-iも自分で用意する必要があります。ソースからのビルドにはRust 1.85以降とPAMの開発ファイルが必要です。

従来のsudoと挙動が変わる箇所と既存スクリプト・設定への影響

既定の設定で使う限り、差はほとんど目に入りません。引っかかるのは、環境変数の引き継ぎやオプションに頼るスクリプトと、sudoersを作り込んだサーバーです。

パスワード入力時の*表示（pwfeedback）の既定オンと無効化設定

0.2.13（2026年3月10日）からDefaults pwfeedbackが既定で有効になり、入力した文字数だけ*が出ます。Ubuntuはそれ以前から独自パッチで同じ挙動にしていました。プロンプトは[sudo: authenticate] Password:という表記です。

入力中にTABキーを押すと、その回だけ表示を消せます。常に消したい場合はvisudoで次の1行を足します。

Defaults !pwfeedback

文字数が画面に出ること自体を嫌う組織は、イメージ作成時にこの行を入れておくのが確実です。

sudo -Eは警告付きで無視、env_resetは常に有効

sudo-rs 0.2.15のソースでは、値なしの-E（--preserve-env）を受け取るとpreserving the entire environment is not supported, '-E' is ignoredと警告を出して処理を続けます。エラーで止まらないため、sudo -Eでhttp_proxyなどを丸ごと引き継いでいたスクリプトは、変数が渡らないまま実行されます。

必要な変数は名前を列挙して渡します。

sudo --preserve-env=http_proxy,https_proxy apt update

sudoers側で恒久的に許すならDefaults env_keep += "http_proxy https_proxy"を足します。sudo-rsのmanページには、env_resetは無効化できないと明記されており、Defaults !env_resetを書いても最小限の環境で実行されます。

sudo -s・-iなどコマンドラインオプションの対応状況と停止条件

よく使うオプションはそのまま動きます。sudo -sは環境変数SHELLのシェルを対象ユーザーで起動し、sudo -iは対象ユーザーのログインシェルを起動します。v0.2.15のsrc/sudo/cli/mod.rsで確認した扱いは次のとおりです。

基本オプション13種：-s・-i・-u・-g・-l・-v・-k・-K・-n・-S・-p・-U・-V。

未対応オプションでの停止：invalid option provided で停止。

sudo -U ユーザー名 -lで他人の権限を照会するときの認証は、従来sudoのlistpwではなく、sudoersのlist擬似コマンドに付けたPASSWD・NOPASSWDタグで決まります。注意が要るのは最後の行です。-R（chroot）や-T（タイムアウト）は実装されておらず、invalid option providedで止まります。-Eと違って実行自体が止まるので、cronやCIのジョブは失敗として表に出ます。逆に-Eの無視は失敗にならないため、ログを見ないと気付けません。

sudoersで通らない書き方と無視される設定・切り替え前の検査

sudoersの解釈差は、切り替え後にsudoが通らなくなる直接の原因です。ソースコードとmanページで確認できた扱いを並べます。

正規表現のエラー原文：regular expressions are not supported。

ダイジェスト指定のエラー原文：digest specifications are not supported。

ログ・端末の設定：Defaults logfile・log_output・requiretty。

通知・表示の設定：Defaults mail_badpass・insults・lecture。

引数の途中にワイルドカードを置いた/usr/bin/systemctl restart app-*.serviceのような行は、sudo-rsでは構文エラーになります。manページは、従来sudoでの引数ワイルドカードは設定ミスの兆候だったと説明しています。末尾の単独*も、/usr/bin/systemctl restart *と書けば任意のサービスを再起動できてしまうため、サービス名ごとに1行ずつ書き分けてください。切り替え前にroot権限でsudo-rs版のvisudoを実行して既存のsudoersを検査すると（Ubuntuではsudo /usr/lib/cargo/bin/visudo -c）、通らない行を事前に洗い出せます。

Ubuntu 26.04のsudo-rs 0.2.13における行継続後の引数制限消失

0.2.13以前には、sudoersの行末に\を置いて次の行へ続けた場合、その後ろに書いた引数の制限が消える不具合があります。LaunchpadのLP#2152220に載っている例は次の書き方です。

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl \
    restart myapp.service

意図は「myapp.serviceの再起動だけ許す」ですが、0.2.13ではrestart myapp.serviceが落ち、deployユーザーはsystemctlを任意の引数で実行できます。visudoは「invalid sudoers file」と報告するものの、ルール自体は有効になります。上流は、visudoが誤りを報告する点を理由に脆弱性として扱わず、0.2.14で解析を直しました。Ubuntu 26.10は0.2.14を収録していますが、26.04の0.2.13-0ubuntu1.2にはこの修正が入っていません。26.04では引数付きのルールを1行で書き、編集後は必ずvisudo -cの結果を確認してください。

sudo-rsの脆弱性一覧と修正版・影響を受けるsudoers設定の条件

sudo-rsのGitHubで公開されているセキュリティアドバイザリは、2026年10月31日時点で6件です。いずれもメモリ安全性の問題ではなく、パスの扱いや認証記録といった論理の誤りです。

対策は、利用中のディストリビューションが提供する修正済みパッケージへの更新です。上流版を直接導入している場合は0.2.15以降へ更新してください。以下は、sudoersの書き方次第で権限昇格に届く2系統です。

sudoeditのシンボリックリンク競合（GHSA-f42v-x7gq-phc8）

公式アドバイザリは2026年8月31日公開。user ALL=sudoedit /etc/hostsのように特定ファイルだけ編集を許すルールで、利用者がシンボリックリンクを高速に付け替えると、別ディレクトリにhostsという名前のファイルを作れてしまいます。原因は、パスの検証処理が誤って2回走り、ポリシー判定に使ったパスと実際に開くパスがずれるTOCTOU（検査時と使用時の食い違い）です。アドバイザリは、本来1回で済むはずの検証がIterator::collectの呼び忘れで2回実行されていたと説明しています。CVE番号は10月31日時点でも採番されていません。

多くのsudoersは末尾に@includedir /etc/sudoers.dを持つため、そこへファイルを置ければ全権限を得られます。sudoeditを使わない、または全面許可している環境は影響を受けません。報告者はAIモデルを使ってsudo-rsのコードを分析し、この問題を見つけたとアドバイザリに記されています。

Ubuntu 26.04は0.2.13-0ubuntu1.2（2026年9月1日配信のUSN-8708-1）で修正パッチを当てています。Ubuntu 26.10は、リリース時の0.2.14-1ubuntu4に修正が入っておらず、10月20日のUSN-8708-2で0.2.14-1ubuntu4.1が配信されました。26.10でsudoeditを特定ファイルに限って許可しているサーバーは、この版へ更新するまでルールを外すか、sudo.wsへ切り替えておく必要があります。

Ubuntu 26.10向けUSN-8708-2の修正内容とGHSAとの対応

USN-8708-2の本文は、sudoeditでの検査時と使用時の食い違い（TOCTOU）の扱いに誤りがあり、特定ファイルの編集をsudoeditで許可されたローカルの利用者が任意のディレクトリにファイルを置いて権限を昇格できるおそれがある、と説明しています。影響は細かなsudoedit権限を与える設定に限られ、既定の構成は該当しないとも書かれています。通知そのものにはCVE番号もGHSA番号も載っていません。

GHSA-f42v-x7gq-phc8との対応は、通知が参照するLP#2165142で確かめられます。このバグ票のCVE参照欄にGHSA-f42v-x7gq-phc8が登録されており、26.10向けの変更履歴はdebian/patches/fix-sudoedit.patchでsrc/common/context.rsを直したと記録しています。26.04の0.2.13-0ubuntu1.2も同じ名前のパッチで、症状の記述も上流アドバイザリと同じです。上流0.2.15の修正コミットとパッチの差分までは、この記事では突き合わせていません。

26.10だけ遅れたのは、リリース前の取り込み漏れです。LP#2165142には10月20日付で、26.10がリリース前に修正されていなかったことに気付いた報告者への謝辞が書き込まれ、同日中に26.10向けタスクが「Fix Released」になりました。リリース直前に分岐した版では、先行リリースの修正が入っているとは限りません。新しいリリースへ上げた直後も、使っている権限系パッケージの修正状況は通知とバグ票で確かめておくと安全です。

手元の26.10に修正が入っているかは、パッケージの版と変更履歴で確認できます。再起動は要りません。

dpkg-query -W -f='${Version}\n' sudo-rs
apt-get changelog sudo-rs | head -n 12
# 0.2.14-1ubuntu4.1 より古ければ更新する
sudo apt update && sudo apt install --only-upgrade sudo-rs

1行目が0.2.14-1ubuntu4.1以上で、変更履歴の先頭にLP: #2165142が出れば修正済みです。無人アップグレード（unattended-upgrades）を既定のまま有効にしている26.10なら、セキュリティポケットの更新として自動で入っているはずですが、イメージから起動して長く更新を止めているサーバーは手動で確かめてください。sudoersの権限設計を含めて、サーバー全体の権限昇格の経路を第三者の目で洗い出したい場合は、脆弱性診断・セキュリティ診断で設定とパッチ適用状況をまとめて点検できます。

targetpw・rootpwの認証記録誤りとタイムアウト時のパスワード露出

CVE-2025-64517は、Defaults targetpwまたはDefaults rootpwを設定した環境の不具合です。認証した相手のUIDではなく呼び出したユーザーのUIDを認証記録に書いていたため、同じ端末で有効期限内に別ユーザーとして実行すると、本来求められるはずのパスワード入力が省かれました。targetpwやrootpwで課していた追加の認証を、自分のパスワードだけで迂回できる状態です。

CVE-2025-64170は、pwfeedbackが無効な状態でパスワードを途中まで打ってEnterを押さずに放置し、既定5分のタイムアウトが来ると、入力途中の文字列がそのままシェルに流れ込む問題です。シェル履歴に残る恐れがあります。どちらも0.2.10（2025年11月10日）で修正され、Ubuntu 25.10には0.2.8-1ubuntu5.2で配信されました。

sudoより下の層で起きる権限昇格として、2026年にはLinuxカーネルの脆弱性Copy Fail（CVE-2026-31431）も公表されています。sudo実装を替えてもカーネル側の穴は塞がらないので、パッチ適用は別に追ってください。

sudo-rsで表示されるエラーメッセージの意味と設定・権限の確認箇所

エラー文は従来のsudoと異なるため、そのまま検索しても情報が見つかりにくい部分です。v0.2.15のソース（src/common/error.rsほか）にある文面と、出る条件を対応させます。

実行許可の拒否原文：I’m sorry ユーザー名. I’m afraid I can’t do that。

権限照会の拒否原文：Sorry, user … may not run …。

所有者・setuid不正の原文：sudo must be owned by uid 0 and have the setuid bit set。

権限昇格禁止の原文：The "no new privileges" flag is set。

未登録の設定がある条件：sudoersにsudo-rsの知らないDefaults。

I'm sorry ... I'm afraid I can't do thatは映画『2001年宇宙の旅』のHAL 9000の台詞で、従来sudoのis not in the sudoers fileやis not allowed to executeに当たる拒否です。管理者が必要な操作を確認し、sudoersにその操作の許可を追加してください。0.2.13以前には、所属人数の多いグループを読み込めずに同じ文面が出る不具合（Ubuntu 26.04では0.2.13-0ubuntu1.1で修正）もありました。許可しているはずなのに拒否される場合は、パッケージが最新かを先に確認します。

unknown setting: 'requiretty'のように出た場合は、表に挙げた未実装のDefaultsが原因です。その行が担っていた制限やログ要件を確かめ、不要と判断できれば削除します。同等の要件をsudo-rsで満たせないなら従来版を使い続けてください。sudo.wsと設定を共用したまま行を残したい場合は、sudo-rs専用の/etc/sudoers-rsを用意します。

setuidのエラーは、ソースからビルドしたバイナリをコピーしただけ、パッケージの設定不備で権限が付かなかった、といった場面で出ます。Ubuntuのパッケージはインストール時に/usr/lib/cargo/bin/sudoを所有者root・モード4755に設定するので、ls -lでその状態になっているかを確認します。Dockerコンテナ内で動かない場合は、--security-opt no-new-privileges付きで起動していないかを見てください。setuidによる昇格そのものがカーネルに止められます。

sudo-rsへ切り替えないほうがよい環境と、doas・run0との違い

次の要件があるサーバーでは、従来sudoの継続を検討してください。設定を書き換える工数より、監査要件を満たせないリスクの方が大きいからです。

• sudoersをLDAPで一元管理している（Ubuntu 26.04ではsudo-ldapパッケージも削除済みで、sudo.wsへ戻すだけでは復旧しない）
• log_outputとsudoreplayで操作の入出力を記録し、監査証跡にしている
• 認証失敗をメール（mail_badpassなど）で通知する運用に依存している
• 引数ワイルドカードや正規表現のルールが数十行あり、書き分けを検証する時間が無い

このうち入出力ログは、sudo-rsの設定一覧にlog_output自体が存在しません。記録が止まるのに気付きにくいため、監査対象のサーバーでは最優先で確認してください。個人の開発マシンでも、sudo -Eに依存するスクリプトや独自のsudoers設定がある場合は、移行前に動作を確かめます。クラウド上のサーバー群でsudoersを構成管理している場合は、イメージ作成の段階でsudo-rs版のvisudo検査を組み込む方法が移行事故の防止に有効です。こうしたサーバー構築や運用設計はインフラ構築（AWS・Google Cloud・Azure）の支援でも扱っています。

doas・run0との設定互換性と権限昇格方式による移行条件の比較

sudoの代替には、OpenBSD由来のdoasとsystemd 256で入ったrun0もあります。sudo-rsのFAQは、Linux向けのOpenDoasが約5,000行のCで自動テストを持たない点、run0はsetuidを使わない代わりにpolkitのJavaScript形式の規則で権限を書く必要があり、sudoeditも無い点を挙げています。

実務上の分かれ目は既存のsudoersを流用できるかどうかです。doasもrun0も設定を書き直す前提なので、既存のsudoersがsudo-rsの対応範囲に収まり、必要な監査・通知機能も確保できるなら、sudo-rsを優先候補にできます。

よくある質問

Ubuntu 26.04でsudo-rsが動いているか確認するには？

sudo -V | head -n 1を実行し、先頭がsudo-rsならRust版です。update-alternatives --display sudoを使うと、現在のリンク先が/usr/lib/cargo/bin/sudoか/usr/bin/sudo.wsかと、自動モードか手動モードかも分かります。アップグレードした環境で結果が違う場合は、過去に手動モードで従来版を固定していないかを同じ出力で確かめてください。sudoeditの修正が入っているかはdpkg-query -W sudo-rsで版を見て、26.04なら0.2.13-0ubuntu1.2、26.10なら0.2.14-1ubuntu4.1以上かを比べます。

Arch Linuxでsudo-rsをsudoという名前で使えますか？

pacman -S sudo-rsで入るコマンドはsudo-rs・sudoedit-rs・visudo-rs・su-rsで、従来のsudoとは共存します。alias sudo=sudo-rsを書けば自分の入力は置き換わりますが、スクリプトや他のプログラムが呼ぶsudoは従来版のままです。システム全体で置き換えたい場合は、公式のビルド済みtarballを/usr/localへ展開し、PATHで優先させる方法がREADMEに載っています。

パスワード入力で*を表示させないようにできますか？

できます。sudo visudoでDefaults !pwfeedbackを追加すると、従来のsudoと同じく何も表示しない入力に戻ります。一時的に消すだけなら、パスワード入力中にTABキーを押してください（0.2.13以降）。上流の既定がオンになったため、Ubuntuに限らずArch LinuxやFedoraで0.2.13以降を入れても*が表示されます。

sudo-rsのGitHubリポジトリはどこですか？

github.com/trifectatechfoundation/sudo-rsです。旧URLのgithub.com/memorysafety/sudo-rsからも転送される仕組みです。リリースノートはCHANGELOG.md、脆弱性はSecurityタブにアドバイザリとして公開され、監査報告書（2023年と2025年の2本）はdocs/auditにPDFで置かれています。従来sudoとの設定差を調べるときはdocs/manのsudoers.5.mdが一次情報です。Ubuntuでの修正配信はUSN（Ubuntu Security Notice）とLaunchpadのrust-sudo-rsのバグ票で追えます。

Rust製なのに脆弱性が出るのはなぜですか？

Rustの安全なコードはバッファオーバーフローや解放済みメモリの使用といったメモリ破損を防ぎますが、unsafeコードやCライブラリとの境界には別途検証が必要で、判定ロジックの誤りも防げません。sudo-rsの6件のアドバイザリはすべて、パス検証の二重実行や認証記録のUID取り違えといった論理の誤りです。公式FAQは、これまでsudo-rsでメモリ安全性の脆弱性は見つかっていないとしています。従来sudoで2011年から2021年まで潜んでいたヒープオーバーフローBaron Samedit（CVE-2021-3156）の種類の問題を減らすのが狙いです。

関連記事

• Ubuntu 26.04 LTS（Resolute Raccoon）とは｜リリース日・新機能・24.04からのアップグレード
• Ubuntu 26.04 LTS 開発者向け詳細｜言語バージョン・x86-64-v3・フレーバー・サポート期間
• Linuxコマンド一覧｜用途別早見表48選とUbuntu 26.04での変更点
• CVE-2026-31431（Copy Fail）とは｜影響カーネルの修正版と緩和策・確認手順
• Dirty Frag(CVE-2026-43284/43500/46300)とは｜Copy Fail 2の影響範囲と修正版・緩和策