パッチが出た後から、本当の仕事が始まる — 修正の来ない機器と、期限が切れたあとの宿題（2026/9/15 Linux・OSSトレンド）

Tue, 15 Sep 2026 00:00:00 +0900

はじめに

脆弱性のニュースを読むとき、わたしたちはつい「パッチが出たかどうか」を最初に見てしまいます。出ていれば安心、出ていなければ危険。そういう二択で考えがちです。

でも今日並んだ4本は、そろって「その後」の話でした。パッチを当てたのに、攻撃者はもう来ていた。パッチの期限が切れたのに、プローブは止まらなかった。そもそもパッチを出す会社がもう存在を認めていない機器がある。そして、修正版が永遠に来ないことが確定してしまったプラグインがある。

パッチが出たかどうかは、備えの入口でしかありません。出たあとに何をするか——資産を数えられるか、ログを遡れるか、来ない修正をどう見切るか。そこで実力が試される一日でした。

1. GitLab CVE-2026-85706 — CVSS 10.0、連邦期限が切れたあともプローブは続いている

まず一番重たい話から。GitLab CE/EE のリポジトリコミット API に、CVSS v3.1 で満点となる 10.0 の脆弱性が見つかりました。

GitLab の公式アドバイザリは、この問題をリポジトリコミット API における不適切なパス制限と認証強制の欠落と説明しています。原文は “improper path confinement and missing authentication enforcement in the repository commits API” で、その結果「 特定の条件下で（under certain conditions） 、未認証のユーザーが GitLab サーバー上の任意のファイルを読み取れた可能性がある」としています。

この「特定の条件下で」という限定は、NVD の記述にもそのまま入っています。いつでも無条件に全ファイルが読める、という話ではない点は押さえておきたいところです。

それでもスコアが 10.0 になるのは、ベクタを見ると納得できます。NVD と GitLab 公式のどちらも CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N を採用しています。ネットワーク越し、攻撃複雑度は低、必要な権限なし、ユーザー操作なし。そして S:C（スコープ変更）と機密性・完全性への高影響が組み合わさっています。ちなみに可用性は A:N（影響なし）で、「全項目が最悪値だから満点」というわけではありません。ファイルを壊すのではなく、読むだけ。それでも満点になるのは、GitLab というサーバーが何を抱えているかを考えれば当然でしょう。

GitLab サーバーは、組織の鍵束が一箇所に集まっている場所です。SSH の秘密鍵、CI/CD 変数、データベースの接続情報、クラウドプロバイダの認証情報。読まれるだけで、そこから先のインフラ全体に手が届いてしまいます。

影響を受けるのは 自己ホスト型（self-managed）のみ で、18.7 以降 19.1.8 未満・19.2 系 19.2.6 未満・19.3 系 19.3.2 未満が対象です。GitLab.com と GitLab Dedicated はリリース時点で修正済みでした。

問題はこの先です。GitLab が修正版を公開したのが 2026年9月10日。その翌日の 9月11日には、watchTowr が自社のハニーポット網でこの脆弱性に対する挙動プローブをすでに観測していると報告しました。同社は「攻撃者はすでに脆弱性のリバースエンジニアリングと再現に成功している（attackers have already successfully reverse engineered and reproduced the vulnerability）」と書いています。よく「パッチ公開から24時間以内に悪用」と紹介されますが、これは watchTowr の逐語表現ではなく、9/10 と 9/11 という日付差からの推定です。

CISA は同じ 9月11日に KEV カタログへ追加し、期限を 9月14日に設定しました。ここで注意したいのが2点あります。ひとつは、この期限が 連邦文民行政府機関（FCEB）向けの義務 であって、一般企業のパッチ期限ではないこと。もうひとつは、KEV エントリの forensicTriage が Yes になっていることです。BOD 26-04 の「Forensics Triage Requirements」に沿った対応が求められており、要するに「パッチを当てたから終わり」ではなく、すでに読まれていないかを調べることまで含まれています（この読み替えは原典の逐語ではなく要約です）。

そして記事執筆時点で、その 9月14日の期限はすでに過ぎています。にもかかわらずプローブは続いている。つまり「期限までに当てた組織」も、当てる前の期間に何が起きていたかを確認する宿題が残っているわけです。

watchTowr は検知の手がかりとして、/api/v4/projects/{id}/repository/commits/ への HTTP POST リクエストのうち file.path パラメータを含むものをログから探すよう案内しています。自己ホスト型 GitLab を運用しているなら、まず 19.1.8 / 19.2.6 / 19.3.2 へ上げる。そのうえで、Nginx やリバースプロキシのアクセスログを 9月10日より前まで遡る。この2つが今日の宿題です。

2. Linux 7.3-rc3 — ファイルシステムに修正が集中、AI 支援パッチはどこまで確かなのか

少し肩の力を抜ける話に移ります。Linus Torvalds が 9月13日に Linux 7.3-rc3 を公開しました。

Torvalds 本人は「また比較的大きな rc リリースで、いつもより大きなファイルシステムの占有面積を持つもの」（Another fairly large rc release, and again one with a bigger filesystem footprint that we usually see）と評しています。rc3 でこの規模というのは、確かに珍しい部類です。

中身を見ると、修正が集中しているのは XFS と SMB クライアントでした。XFS では xfs_scrub のビットマップ走査が無限ループに陥るバグ、ディレクトリ B+木が部分破損した際のリカバリパス、6.12 でマージされた親ポインタ機能の後続バグ、オンラインリペアで quota inode を扱ったあとにパニックするリグレッションなどが並んでいます。XFS は RHEL 系ディストリビューションのデフォルトファイルシステムなので、対象になる環境はそれなりに広いはずです。

SMB クライアント側はセキュリティ色が濃く、SESSION_SETUP レスポンス内のセキュリティバッファ長の検証が足りずヒープオーバーフローを起こしうる経路が修正されました。悪意ある SMB サーバーに接続することが前提条件なので、社内の信頼できるファイルサーバーだけを見ているなら実害は小さいですが、ゼロトラストで考えるなら無視できません。

EROFS では実験的な LZ4 ローリング展開が、データ破損の懸念からいったん無効化されました。EROFS は Android のシステムパーティションでも使われているので、組み込み側にも波及する話です。

さて、この rc3 で話題になったのが AI 支援パッチです。Phoronix は記事のなかで “This week brought many more fixes brewed via AI/LLMs."（今週も AI/LLM で醸成された修正が多く入った）と書きました。ただ、ここは慎重に読む必要があります。

まず、 Torvalds 本人の 7.3-rc3 アナウンスメールに AI や LLM への言及は一切ありません 。そして、AI を使った具体例としてよく挙げられるカーネルビルドの高速化パッチシリーズは、AI を分析ツールとして使ってシングルスレッドのボトルネックを洗い出したもので、ビルド時間を約36%短縮・インクリメンタルビルドを約70%高速化する効果が報告されていますが、 マージターゲットは Linux 7.4 です。7.3-rc3 に入ったわけではありません。

わたしはここが今回いちばん面白かった部分だと思っています。「AI がカーネルにパッチを書き始めた」という見出しは強いのですが、確認できる事実は「AI をバグ発見の道具に使った人間のパッチが、次のバージョンを狙ってレビュー中」というところまでです。この事例で AI が向き合ったのは “a lot of ‘hideous code’"（大量のひどいコード）と表現された既存のビルドまわりの実装で、そこからボトルネックを洗い出す分析役を担いました。AI がコードを書いたというより、AI が読んだ、という構図に近いわけです。AI がどこまで入り込んでいるのかは、見出しではなくパッチの行き先を追わないと見えてきません。

なお rc3 は開発版なので、本番環境に入れるものではありません。安定版の 7.3 は10月下旬の予定です。XFS のオンラインリペアを使っている環境なら、それまで定期スクラブを止めておくか 7.2.x に据え置くかを検討してもよさそうです。

3. D-Link DIR-878 の CVSS 9.9 が2件 — 修正が来ないと分かっている機器をどう守るか

3本目は、今日のタイトルにもなっている「修正が来ない機器」の話です。

D-Link のルーター DIR-878（ファームウェア 120B05）に、スタックベースのバッファオーバーフローが2件同時に開示されました。CVE-2026-90692 は Dynamic DNS IPv6 設定を扱う SetDynamicDNSIPv6Settings 関数で、IPv6Address/Hostname 引数の操作によって発生します。CVE-2026-90693 は WAN 設定を扱う SetWan3Settings 関数で、Primary/Secondary 引数が起点です。どちらもリモートから攻撃可能です。

スコアの読み方には少し注意が要ります。CVSS v3.1 では両方とも 9.9（Critical）ですが、v4.0 では 9.4、v2.0 では 9.0 と、版によって数字が変わります。「9.9」と言うときは v3.1 のスコアだと添えておくのが親切でしょう。

そしてもうひとつ、ここは誤解が広まりやすい箇所なのですが、v3.1 のベクタは AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H です。PR:L、つまり 低権限が必要 です。完全に認証不要というわけではなく、管理 UI への基本的な認証相当が前提になります。とはいえ家庭用ルーターの管理画面といえば、初期パスワードのまま動いている個体が世の中にどれだけあるかを考えると、この L はあまり慰めになりません。

問題は「では修正版はいつ出るのか」です。DIR-878 は 2021年1月31日に EoL（End of Life）を迎えています。D-Link の公式アナウンスは「そうした製品のデバイスやファームウェアに関する問題については、開発およびカスタマーサポートが終了している可能性があるため、 対応できない場合があります （We may not be able to address issues related to devices or firmware for such products）」という書き方をしています。「絶対に出さない」と断言しているわけではありませんが、期待して待つ性質のものでもありません。D-Link 自身は現行世代製品への移行を推奨しています。

この日、D-Link（DIR-878・DIR-823G）と Totolink（A3002MU）を合わせたルーター系の CVE が CVSS 9.9 の重大 CVE 6件を占めたと報告されています。この日の CVSS 9.0 以上は全部で14件だったので、およそ4割がルーターだった計算です。

EoL 機器への現実的な対処は、結局のところ買い替えか隔離しかありません。ただ、その前にやることがあります。 自分が何を使っているかを把握すること です。家庭のルーターはいつ買ったか覚えていないことが多いですし、小規模なオフィスなら「前任者が置いていった機器」が現役だったりします。棚卸しをして、EoL 日を調べて、WAN 側から管理画面に届く状態になっていないかを確認する。今日の宿題の2つめは、これです。

4. WordPress CryptoPayment Gateway CVE-2026-81648 — CVSS 10.0、そして修正版が存在しない

最後は、今日いちばん構造が厄介な話です。

WooCommerce 向けの暗号通貨決済プラグイン「CryptoPayment Gateway」のバージョン 1.2.1〜1.2.2 に、CVSS v3.1 で 10.0 の脆弱性が見つかりました。NVD の記述はこうです——「このプラグインは AJAX エンドポイントのひとつに認可チェックを適用しておらず、未認証のユーザーが管理者向けの操作を実行できる。サーバー上の任意ファイルの削除、決済ゲートウェイ設定の上書き、保存されたウォレット認証情報の平文での取得を含む」。

決済プラグインの設定を書き換えられる、しかもウォレットの認証情報が平文で出てくる。金銭被害に一直線です。ベクタは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H で、PR:N / UI:N という組み合わせは自動スキャンによる大量攻撃と相性がよい形をしています。

ここまでなら「よくある深刻な脆弱性」なのですが、厄介なのはこの先です。

まず、 修正版が存在しません 。WPScan の脆弱性エントリは “Fixed in” の欄に「No known fix available」と記載しています。そして WordPress.org のプラグインページは、2026年8月28日からこのプラグインの公開を停止しています。「この公開停止は一時的なもので、完全なレビューを待っている状態です」という表示が出るだけで、ダウンロードはできません。

つまり、CVE の公開（9月14日）より 半月以上前 にプラグインは配布停止されていたわけです。新規にインストールされることはもうありません。でも、すでにインストールされているサイトには何も届きません。自動更新を有効にしていても、更新先が存在しないのですから何も起きない。「自動更新にしてあるから大丈夫」が最も通用しないパターンです。

対処は、更新ではなく削除です。無効化でもリスクは下がりますが、確実なのは削除してしまうことです。そして、別の決済手段へ移行する必要があります。

なお、この件については訂正しておきたい情報がひとつあります。「9月14日時点で野生の悪用リストに載っている」という紹介を見かけますが、これは正確ではありません。CVEBrief の 9/14 アーカイブには「14件の重大 CVE（CVSS 9.0 以上）」と「14件の CVE が能動的な悪用を確認済み」という 2つの別々の14件 が登場します。後者に含まれているのは Citrix NetScaler、Cisco Secure Firewall Management Center、ConnectWise ScreenConnect、GitLab、Microsoft Windows、Google Chrome、JFrog Artifactory であって、CryptoPayment Gateway は入っていません。数字が同じなので混同されやすいのですが、この脆弱性は現時点で「悪用が確認された」ものではないのです。

ではなぜ急ぐのかというと、PoC（実証コード）の公開が 2026年10月1日に予定されている からです。動画のタイトルにある「決済プラグインは2週間後」はこのことを指しています。いまは、攻撃者がまだ手札を持っていない静かな期間です。その静けさが終わる日付だけが、はっきり決まっている。

「悪用が確認されていないから様子を見る」という判断が、ここでは最も危険です。修正版が来ないと分かっていて、公開日が決まっていて、対処が「削除するだけ」で済むのなら、今日やらない理由がありません。

まとめ

4本を振り返ると、どれも「パッチが出たかどうか」では判断できない話でした。

GitLab は、パッチが出ていて、当てるべき期限も過ぎていて、それでもプローブが続いています。やることはパッチではなくログを遡ることです。Linux 7.3-rc3 は、AI が書いたという見出しの奥にある実際のマージ先を追わないと、何が起きているか分かりませんでした。D-Link は、修正が来ない前提で買い替えか隔離を決める話でした。そして WordPress のプラグインは、修正版が永遠に来ないと確定したうえで、悪用が始まる日付だけが決まっているという状態です。

共通しているのは、判断に必要なのが「新しい情報」ではなく「自分の手元の情報」だということです。どの機器を持っているのか。どのバージョンで動いているのか。いつから稼働しているのか。ログはいつまで遡れるのか。

棚卸しとログ遡り。地味で、後回しにしやすくて、そして今日の4本すべてで宿題になった作業です。

あなたの手元のルーター、いつ買ったものか思い出せますか。そして、先月のアクセスログはまだ残っていますか。

D-Link on 思いつきそうで思いつかなくていたときに