見えないところの設計判断が、そのまま強みにも弱みにもなる — セレクタ1つ、ログ1行、sysfs 1ファイル（2026/9/23 Linux・OSSトレンド）

Wed, 23 Sep 2026 00:00:00 +0900

はじめに

ソフトウェアの良し悪しは、たいてい表から見える部分で語られます。機能が多いか、速いか、使いやすいか。ただ、実際に事故を起こしたり、逆に大きな余裕を生んだりしているのは、ほとんどの人が見ない層にある小さな判断だったりします。

今日の5本は、まさにその「見えないところの判断」が結果を左右した話ばかりでした。ブラウザ側のセレクタを1つエスケープしなかったために管理画面が乗っ取られる話。ホストカーネルと VM の結合という前提そのものを外しにいく話。リンク抽出エンジンがどの属性を見るかという地味な設計の話。状態をどう外に見せるかを絞り込んだ話。そして、セッション識別子をどこに書くかという判断がそのまま権限昇格になった話です。

なお今回は、出回っている情報のなかに事実関係の取り違えがいくつか混じっていました。特に1本目については、通称と CVE 番号の対応が広く混乱しています。記事では一次情報で裏が取れた範囲だけを書き、取れなかったものは書かない方針を徹底しました。

1. WordPress「Click2Shell」— 管理者のクリック1回から PHP 実行まで

最初は、今日いちばん急ぐ話です。

WordPress のテーマインストール画面には、URL のパラメータで指定したテーマを画面上で選択状態にする仕組みがあります。Patchstack の解説によれば、この処理でパラメータの値がエスケープされないまま jQuery のセレクタに埋め込まれていました。jQuery のセレクタは CSS の構文を解釈するので、値の中に " や > を仕込めば、それはもう「文字列」ではなく「セレクタの構造」として働いてしまいます。結果として、管理者が意図していないインストールボタンが自動的に押される、という状況が作れます。

修正は WordPress 7.1.1 で入りました。公式リリースノートは、このリリースで11件のセキュリティ修正を行ったこと、そして修正は必要に応じて「現時点では 4.7 系まで」セキュリティ修正の対象ブランチ全てにバックポートされることを明記しています。10年近く前のブランチまで手が伸びているあたりに、WordPress の裾野の広さが出ています。

ここで、読者の方が検索したときに必ず引っかかる混乱を先に潰しておきます。 この脆弱性には、本稿執筆時点で CVE 番号が割り当てられていません。 BleepingComputer の記事も公式な識別子がないと書いており、公式リリースノートにも「Click2Shell」という名称自体が出てきません。この通称は報道側が付けたものです。

そして紛らわしいことに、同時期に公開された CVE-2026-63030 という別の WordPress 脆弱性が実在します。こちらは 6.9.x / 7.0.x の REST API バッチエンドポイントにおけるルート混同の問題で、CVSS 9.8、しかも CISA の KEV カタログに 2026年7月21日付で登録済みという、まったく別のインシデントです。 今回の話と CVE-2026-63030 は無関係です。 両者を結びつけている情報を見かけたら、それは誤りだと思ってください。

CVE がないということは、当然ながら公式な CVSS スコアもありません。発見者側が独自に算出した値は公開されていますが、それは第三者評価を経た数字ではない、という前提で見る必要があります。

技術的な連鎖については、説明の粒度が情報源ごとに食い違っています。発見者の記事は7段階、Patchstack は3段階で説明しており、どちらが正確かは一次情報だけでは決められません。共通しているのは次の3点です。

テーマ指定の値の扱いが、サーバー側とブラウザ側で一致していない
管理者がログイン状態のまま細工されたリンクを踏む必要がある（完全な無操作攻撃ではない）
最終的にサーバー上で PHP が実行される

もう1つ、公開されている PoC リポジトリを読むと、最終段の任意 PHP 実行がサードパーティのテーマ（Mobile Repair Zone 2.5.4 以下）の脆弱な AJAX ハンドラに依存する実装になっています。つまり「WordPress 本体だけで完結して RCE になる」と読める書きぶりには、少し留保が要ります。

なお、野生での悪用については、確認した一次情報のいずれにも記述がありませんでした。「PoC 公開後に攻撃が急増している」という話も同様です。深刻ではありますが、いま現在燃えている火事だという証拠は見当たらない、というのが正確なところです。やることはシンプルで、7.1.1 に上げる。それだけです。

2. Orphaned VMs — ホストカーネルが落ちている間も VM を回し続ける

2本目は、真逆の方向を向いた話です。守りではなく、前提を外しにいく設計。

クラウド事業者にとって、ホストのカーネル更新は面倒な作業です。カーネルを入れ替えるには再起動が要り、再起動すればその上の VM は止まる。そこでライブマイグレーションで逃がすわけですが、台数が増えればコストも時間もかかります。

Phoronix が9月21日に報じたのは、この前提そのものを壊しにいく提案です。Google の Pasha Tatashin が主導する RFC で、パッチは現時点で46本。ホストの Linux カーネルが kexec で完全にオフラインになっている間も、VM を隔離した CPU 上で動かし続けようという内容です。RFC がメーリングリストに投稿されたのは9月20日、Phoronix の記事はその翌朝という時系列になります。

鍵になるのが「Caretaker（世話役）」と名付けられた層です。ハイパーバイザ特権のハードウェア状態の中に居座る、専用のベアメタルな中間層。ホストが元気なうちは VM exit を通常の KVM ハンドラへ素通しするだけですが、ホストが消えている間は Caretaker が単独でゲストの面倒を見ます。カーネルが居なくなった世界でも動き続けられるよう、カーネル抜きでも自律的に動ける作りが前提になっています。

ちなみに Tatashin は、カーネル公式ドキュメントの Live Update Orchestrator（LUO）の著者でもあります。kexec をまたいでリソースを引き継ぐ仕組みを積み上げてきた延長線上に、今回の提案があるわけです。

期待が先走りやすい話なので、温度感は正確に書いておきます。Phoronix は Intel・AMD・Arm のサーバープロセッサで検証済みとしつつ、同時に “very early work in progress and not production ready” と明記しています。 非常に初期の作業中であり、本番運用向けではありません。 技術的な課題として挙げられているのも、タイムキーピングのドリフト、迷子になる割り込み、ゲスト間の IPI ルーティングと、どれも一筋縄ではいかないものばかりです。

今回この記事を書くにあたって、資料側にあった「特定のメンテナがこう発言した」「カンファレンスで発表予定」「Linux 7.x のどこかでマージ見込み」といった記述は、一次情報で裏が取れなかったため全て落としました。RFC 段階の話に確度の高そうな飾りを付けるのは、いちばんやってはいけないことだと思っています。いまは「面白い提案が出た」以上でも以下でもありません。

3. GNU Wget2 2.3 — 地味だけれど、ミラーの取りこぼしが減る

3本目は、肩の力が抜ける話です。

GNU の FTP サーバーを見ると、wget2-2.3.0.tar.gz のタイムスタンプは 2026年9月21日。Phoronix はこれを 2026年に入って最初の新リリースと位置づけています。wget2 は wget 1.x の後継として、マルチスレッドや HTTP/2 対応を前提に作り直された系統です。

GitHub 側のリリースノートから、実際に手元で効いてくる変更を挙げます。

--progress=dot — 進捗表示をドット形式にできるようになりました。デフォルトの温度計バーはターミナルでは見やすいものの、ログにリダイレクトしたり CI のログに流したりすると悲惨なことになります。これが解消します
--convert-links が CSS も対象に — これまで HTML 内のリンクしか書き換えていなかったので、CSS から参照される画像やフォントがローカルを指さないままでした。オフライン閲覧用のミラーを作ったことがある方には、この地味さが刺さるはずです
<iframe srcdoc> と data-src / data-srcset の解析対応 — 遅延読み込みが当たり前になった現代のサイトでは、src だけを見ていると画像の大半を取りこぼします
--spider -S でヘッダーを表示 — ダウンロードせずにヘッダーだけ確認したい、という用途が素直に書けるようになりました

どれも派手さはありませんが、「リンク抽出エンジンがどの属性を見るか」という完全に裏方の設計が、ミラーの完成度をそのまま決めているという意味では、今日のテーマにぴったりの一本です。

ひとつ、一部で流布している誤りを訂正しておきます。直前バージョン 2.2.1 のリリースを「2026年1月4日」とする記述を見かけますが、FTP 上のタイムスタンプは 2025年12月30日です。1月4日は info-gnu メーリングリストでのアナウンスが流れた日で、リリース日そのものではありません。こういう数日のズレは、後から年表を作る人が必ず踏む地雷なので、書いておきます。なお 2.2.1 では get_local_filename_real() と wget_iri_clone() のバッファオーバーフロー修正が入っており、メモリ安全性に関わる内容が含まれていました（NEWS 上に CVE 番号の記載はありません）。

4. AMD SEV の状態を sysfs 1ファイルで — 最小権限の実例

4本目は、「状態をどう外に見せるか」という設計の話です。

AMD の SEV（Secure Encrypted Virtualization）は、VM のメモリを暗号化してホストからも中身を読めなくする機能群です。世代を追って SEV → SEV-ES → SEV-SNP と保護範囲が広がってきました。ところが、ゲスト OS の中から「いま自分はどの保護が効いた状態で動いているのか」を確認するカーネル標準の手段が、長らくありませんでした。

Phoronix は9月22日の記事で、この空白を埋めるパッチが tip ツリーに入ったことを報じ、“A convenient addition that surprisingly hasn’t been added to the Linux kernel until now”、つまり「今まで入っていなかったのが驚きなくらい便利な追加」と評しています。同記事は10月に始まる Linux 7.4 のサイクルを見据えた取り込みだとも書いています。

追加されるのは /sys/devices/system/cpu/sev/sev_status というファイル1つです。パッチ本文によると、実装は MSR_AMD64_SEV（カーネル公式ドキュメントでアドレス 0xc0010131 と定義されている MSR）の値を16進数でそのまま出すだけの読み取り専用属性です。しかも、これまで SEV-SNP のゲストにしか作られなかった sev/ ディレクトリが、SEV・SEV-ES を含む全世代に拡張されています。

面白いのは、この変更の動機です。パッチが置き換えの対象に挙げているのは、MSR を読むためのカーネルモジュール経由での確認です。パッチの説明文はそのやり方について “The use of this module poses a security risk in any trusted execution environment and is generally discouraged."、すなわち「信頼実行環境ではセキュリティリスクを伴い、一般に推奨されない」と述べています。あらゆる MSR を読める口を開けておく代わりに、必要な1つの値だけを読み取り専用で出す。 見せる範囲を絞り込むという判断そのものが、この変更の中身です。 最小権限の原則の、これ以上なく分かりやすい実例だと思います。

経緯も少し変わっています。関連する最初のパッチは 2025年3月12日に投稿されたもので、投稿者は Joerg Roedel。その後 2026年6月に件名を変えた単一パッチとして仕切り直され、8月に改版、9月22日に tip へ取り込まれました。1年半かけて形を変えながら通った、ということです。カーネルに小さなファイル1つを足すのにこれだけかかるのかと思うと同時に、その慎重さが信頼の源でもあるのだろうな、とも思います。

5. Veeam Agent for Windows の権限昇格 — ログに書いた識別子が鍵になる

最後は、また足元に火がついている話に戻ります。

CVE-2026-32996 は、Veeam Agent for Microsoft Windows のローカル権限昇格の脆弱性です。CVSS v4.0 で 7.3（High）、ベクタは AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N と、NVD と Veeam 公式 KB4852 で一致しています。ローカルからしか使えず、低権限のアカウントが1つあれば足りる、という形です。

仕組みが実に教科書的です。The Hacker News の記事によると、問題は2段構えになっています。ひとつは、バックアップサービスがローカルの gRPC 名前付きパイプ上でやり取りするセッション識別子を、要求元のユーザーや接続に紐付けていないこと。もうひとつは、その識別子が一般ユーザーでも読めるログファイルに記録されてしまうことです。

このどちらか片方だけなら、まだ致命傷にはなりません。識別子が接続に紐付いていれば、盗んでも使えない。ログに出なければ、盗めない。2つの独立した判断が重なった瞬間に、「ログを読んで、そこに書いてある識別子を名乗るだけで SYSTEM 権限のコマンドが実行できる」という一本道ができあがります。 設計の穴は単独では見えず、組み合わせで初めて口を開ける という、よくある構図です。

バージョンの扱いには注意が要ります。KB4852 は、脆弱性そのものは Veeam Agent for Microsoft Windows にあると述べたうえで、影響範囲を「Veeam Backup & Replication 13.0.1.2067 およびそれ以前の v13 系ビルド」という Veeam Backup & Replication 側の版数 で示しています。修正済みとされる 13.0.2.29 も同様に Backup & Replication の版数です。製品名と版数の対応がずれた状態で引用されている情報が出回っているので、自分の環境を確認するときは「どの製品の番号か」を必ず意識してください。

現在の状況について。The Hacker News は、Zyxel の別の脆弱性と並べて、この脆弱性が実際の攻撃に使われている状況にあると報じています。PoC も GitHub 上に公開されており、リポジトリの最初のコミットは9月15日です。なお、悪用を報告したセキュリティベンダーの原文は今回どうしても直接取得できなかったため、確認日時などの細かい点は書かずにおきます。ただ、KB4852 自体の公開は 2026年5月27日付です。パッチが出て4か月近く経ってから悪用が表に出てきた、という構図は動きません。

LPE は CVSS の数字が控えめに出がちです。リモートから直接叩けないぶん、スコアが伸びない。それでも、侵入後に確実に SYSTEM を取れる手段は攻撃者にとって極めて価値が高く、実際の被害の大きさは数字ほど素直ではありません。バックアップ製品は業務上どうしても高い権限で動かざるを得ないので、なおさらです。

まとめ

5本を並べてみると、共通していたのは「誰も見ないところの判断が、そのまま強みにも弱みにもなっていた」ことでした。

エスケープ関数を1つ呼ぶかどうか。セッション識別子をログに書くかどうか。MSR を全部見せるか、必要な1つだけを読み取り専用で出すか。どれも、機能一覧にも料金表にも載らない判断です。載らないから見直される機会も少なく、だからこそ何年も残ります。WordPress のセレクタの件も、SEV の確認手段が長年なかった件も、時間軸の長さという意味では同じ話です。

一方で、Orphaned VMs のように「そもそもこの前提を外せないか」と裏側を組み替えにいく動きも同時に出てきます。まだ very early な RFC ですが、ホストカーネルと VM が一蓮托生という当たり前を疑うところから始まっているのが良いなと思いました。

今日の実務的なアクションとしては、WordPress は 7.1.1 へ、Veeam は KB4852 の指す修正版へ。この2つだけは今日中に確認しておいて損はありません。

参考リンク

WordPress 7.1.1 公式リリースノート: https://wordpress.org/news/2026/09/wordpress-7-1-1/
Phoronix: Orphaned VMs のパッチ解説: https://www.phoronix.com/news/Orphaned-VMs-Linux-Patches
GNU Wget2 2.3.0 リリースノート: https://github.com/rockdaboot/wget2/releases/tag/v2.3.0
Linux カーネル公式ドキュメント: AMD Memory Encryption: https://docs.kernel.org/arch/x86/amd-memory-encryption.html
Veeam KB4852（CVE-2026-32996）: https://www.veeam.com/kb4852

Wget on 思いつきそうで思いつかなくていたときに