ssh-keysign-pwn（CVE-2026-46333）解説：Linux のローカル情報漏えい、SSH ホスト鍵、/etc/shadow のリスク

ssh-keysign-pwn は、Linux kernel の __ptrace_may_access() のロジック問題をめぐって公開された一連の利用経路で、CVE 番号は CVE-2026-46333 です。リモートから未認証で悪用できる脆弱性ではなく、直接 root shell を得るものでもありません。それでもリスクは高く、ローカルの低権限ユーザーが、本来アクセスできない root 所有の機密ファイル、たとえば SSH ホスト秘密鍵や /etc/shadow を読み取れる可能性があります。

運用上の重点は PoC の再現ではありません。影響を受けるマシンを特定し、カーネルを更新し、再起動して修正済みカーネルで起動し、必要に応じて SSH host keys のローテーションやパスワードリセットを行うことです。

まず結論

この脆弱性は高い優先度で対応すべきです。理由は次の 4 つです。

root 権限は不要で、ローカルの低権限ユーザーから発火できます。
公開 PoC が存在し、悪用のハードルが下がっています。
対象は通常ファイルではなく、SSH ホスト秘密鍵や /etc/shadow になり得ます。
修正にはカーネルパッチと再起動が必要で、パッケージ更新だけでは不十分です。

複数ユーザー、ローカル shell、共有ホスト、CI runner、コンテナホスト、学生用端末、踏み台サーバー、または完全には信頼できないローカルユーザーがいるサーバーでは、優先的に対応してください。

脆弱性の概要

Qualys は 2026 年 5 月 15 日、oss-security でこの問題を公開しました。Qualys はそれ以前に Linux kernel の __ptrace_may_access() ロジック問題を security@kernel.org に報告しており、上流修正は Linus によってマージ済みでした。その後、公開 exploit コードが現れたため、Qualys は情報を oss-security に投稿しました。

その後 Linux kernel CVE チームがこの問題に CVE-2026-46333 を割り当てました。NVD ページではソースが kernel.org とされ、問題説明はカーネルコミット ptrace: slightly saner 'get_dumpable()' logic に対応しています。

簡単に言えば、この脆弱性はプロセス終了経路にあります。一部の特権プロセスが終了中の場合、対象タスクがすでに mm を持たないため、カーネル内の ptrace アクセスチェック関連ロジックが、本来依存すべき dumpable チェックを迂回してしまう可能性があります。攻撃者は非常に狭い競合ウィンドウで、終了中の特権プロセスがまだ開いているファイルディスクリプタを取得できます。

これが ssh-keysign-pwn と呼ばれる理由です。公開された利用経路の一つは ssh-keysign を使い、SSH host private keys を読み取るものです。

SSH ホスト秘密鍵と /etc/shadow が読まれる理由

この問題の本質はローカル情報漏えいです。特権プログラムの終了過程で「メモリ記述子は切り離されたが、ファイルディスクリプタはまだ閉じられていない」時間差を悪用します。

AlmaLinux のアドバイザリはリスクを明確に説明しています。特権プログラムが権限を落とす前に機密ファイルを開いており、攻撃者が終了ウィンドウ中に対応するファイルディスクリプタを取得できれば、その機密ファイルを読み取れる可能性があります。

公開議論でよく挙がる対象は次の 2 つです。

ssh-keysign：/etc/ssh/ssh_host_*_key のような SSH ホスト秘密鍵に関係する可能性があります。
chage：/etc/shadow に関係する可能性があります。

SSH ホスト秘密鍵が漏えいすると、攻撃者はそのホストになりすまし、SSH のホスト ID 信頼を損なう可能性があります。/etc/shadow が漏えいすると、攻撃者はパスワードハッシュをオフラインで解析し、後続の侵害を広げることができます。

そのため、これは「直接 root shell」ではなくても高優先度で扱うべき問題です。

影響範囲の判断

上流の観点では、これは Linux kernel の脆弱性です。NVD の記録では、この問題は 2026 年 5 月 15 日に NVD データセットへ追加されており、その時点では CVSS スコアは付与されていませんでした。

ディストリビューションごとの状態は、それぞれのアドバイザリで確認してください。

AlmaLinux 8、9、10 は対応情報を公開し、2026 年 5 月 16 日の更新で patched kernels が本番リポジトリに入ったと説明しています。
Debian Security Tracker は bullseye、bookworm、trixie、sid などの vulnerable/fixed 状態と fixed versions を掲載しています。
その他のディストリビューションでは、Ubuntu、Red Hat、SUSE、Arch、Alpine などの公式セキュリティページや更新リポジトリを確認してください。

カーネルの上流バージョン番号だけで安全かどうかを判断しないでください。ディストリビューションは修正を backport するため、同じ上流バージョンに見えても、配布元によってパッチ状態が異なる場合があります。

優先的に対応すべきマシン

リスク順に対応するなら次の順序を推奨します。

複数ユーザーサーバーと共有ホスト。
通常の shell アカウントがある踏み台、教育用端末、開発機。
CI runner、ビルドマシン、ホスティング基盤ノード。
コンテナホストと仮想化ホスト。特に完全には信頼できない workload が共存する環境。
公開サービス用マシン。脆弱性自体はローカルアクセスを必要としますが、Web/RCE/弱いパスワードで低権限の足場が得られるとリスクが重なります。

純粋な単一ユーザーデスクトップのリスクは相対的に低めですが、システム更新で修正することを推奨します。ブラウザ、開発ツール、スクリプト、サードパーティソフトウェアを通じたローカル低権限コード実行は珍しくないためです。

修正方針

最優先の修正は、ディストリビューションが提供する修正済みカーネルをインストールし、再起動することです。

コマンドはディストリビューションごとに異なりますが、原則は同じです。

パッケージメタデータを更新する。
CVE-2026-46333 修正を含む kernel パッケージをインストールする。
再起動して新しいカーネルで起動する。
uname -r とディストリビューションのセキュリティアドバイザリで、実行中カーネルが修正済みか確認する。

AlmaLinux のアドバイザリでは、本番リポジトリに修正済みカーネルが提供されており、通常の dnf upgrade と再起動で対応できるとされています。Debian tracker も複数ブランチの fixed versions を掲載しています。

注意点として、新しい kernel パッケージをインストールしただけで再起動しない場合、古い脆弱なカーネルがまだ動作しています。

一時的な緩和策：ptrace_scope を厳しくする

すぐに再起動できない場合は、まず Yama の ptrace_scope を厳しくしてください。

Qualys は oss-security の後続返信で、/proc/sys/kernel/yama/ptrace_scope を 2（admin-only attach）または 3（no attach）に設定すると、既知の公開利用経路を阻止できると確認しています。ただし理論上は別の利用方法が存在し得るとも述べており、これは修正ではなく緩和策です。

一時設定は次の通りです。

1

sudo sysctl -w kernel.yama.ptrace_scope=3

永続化する場合は sysctl 設定に書き込みます。

1

echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf

ptrace_scope=3 は ptrace attach を無効化するため、gdb や strace -p などのデバッグに影響する可能性があります。本番環境でデバッグが必要なら 2 を検討してください。どちらを選んでも、カーネル更新と再起動は早めに計画すべきです。

SSH ホスト鍵をローテーションすべきか

脆弱性公開前後に次の条件があったマシンでは、保守的に対応することを推奨します。

信頼できないローカルユーザーがいる。
共有ホスト、またはコンテナ/CI のマルチテナント環境である。
Web 脆弱性、弱いパスワード、サプライチェーンスクリプトなど、攻撃者にローカル足場を与え得る要素がある。
ログに不審なローカルプロセス、異常なデバッグ挙動、公開 PoC ファイルがある。
修正前に長時間露出していた。

保守的な対応には次が含まれます。

修正と再起動後に SSH host keys をローテーションする。
既知ホスト指紋管理システムを更新する。
そのホスト指紋に依存する自動化システムへ通知する。
SSH 接続アラートを確認し、正当な指紋変更を中間者攻撃と誤認しないようにしつつ、本当のリスクを見逃さない。

/etc/shadow が漏えいした疑いがある場合は、パスワードリセット、弱いパスワードの禁止、古いハッシュがオフライン解析可能かどうかの確認も検討してください。

監視すべきもの

この種の脆弱性は利用ウィンドウが短く、従来のログに完全には残らない可能性があります。それでも次の点は確認できます。

通常ユーザーディレクトリに ssh-keysign-pwn、chage_pwn、または類似 PoC ファイルがないか。
短時間で見慣れない C プログラムをコンパイルするなどの不審なコンパイル行為。
/etc/ssh/ssh_host_*_key や /etc/shadow への異常アクセスの兆候。
異常な pidfd_getfd、ptrace、デバッガ関連の挙動。
外部システムから SSH ホスト指紋異常が報告されていないか。

これらのシグナルは悪用を証明するものではなく、存在しないからといって悪用されていない証明にもなりません。最優先事項は、パッチ、再起動、認証情報のローテーション、リスク隔離です。

よくある誤解

1 つ目の誤解：これは OpenSSH のリモート脆弱性ではありません。名前に ssh-keysign が入っていますが、根本原因は Linux kernel の ptrace アクセスチェックロジックであり、sshd のリモート認証フローではありません。

2 つ目の誤解：ローカルユーザーがいなければ完全に安全、というわけではありません。確かにローカル実行条件は必要ですが、実際の攻撃チェーンでは Web サービス、CI、スクリプト、弱いパスワード、コンテナエスケープなどを足がかりに低権限のローカル実行を得ることがよくあります。

3 つ目の誤解：ptrace_scope を設定すれば十分、というものです。これは一時的な緩和策であり、根本修正ではありません。カーネル更新と再起動は必要です。

4 つ目の誤解：root を取られていなければ問題ない、というものです。SSH ホスト秘密鍵や /etc/shadow の漏えいだけでも、横展開、ホストなりすまし、オフライン解析につながる十分なリスクがあります。

対応チェックリスト

次の順序で実行することを推奨します。

影響を受ける Linux ホストを棚卸しする。特に複数ユーザー環境と共有環境を優先する。
ディストリビューション公式のセキュリティアドバイザリを確認し、fixed kernel version を特定する。
修正済みカーネルをインストールして再起動する。
すぐに再起動できないマシンでは、先に kernel.yama.ptrace_scope=2 または 3 を設定する。
修正後、実行中のカーネルバージョンを確認する。
高リスクマシンでは SSH host keys をローテーションする。
/etc/shadow 漏えいが疑われる場合、パスワードリセットとアカウント監査を検討する。
公開 PoC、異常なコンパイル、不審なローカルデバッグ挙動を確認する。

まとめ

ssh-keysign-pwn（CVE-2026-46333）は、Linux kernel の __ptrace_may_access() 関連ロジックに起因するローカル情報漏えい脆弱性です。リモートから直接侵入できるものでも、直接 root shell を与えるものでもありませんが、低権限ローカルユーザーが高価値の機密ファイルを読み取れる可能性があるため、複数ユーザー、共有ホスト、CI、コンテナホスト環境では特に警戒が必要です。

最も確実な修正は、ディストリビューション提供の修正済みカーネルへ更新し、再起動することです。ptrace_scope=2/3 は一時的な緩和策として使えますが、パッチの代替にはなりません。リスクウィンドウにさらされていた重要ホストでは、SSH ホスト鍵のローテーションとパスワードリスク評価も検討してください。

参考リンク：