このサイトでの挿絵は、Gemini Proによる生成が大半です。 また、情報収集・まとめなどのサイトについては、検索結果をベースとしたものを使用しています。可能な限り出典を明示するよう努めますが完全ではありません。各自で調べる事もお忘れなく。
Linux・OSSトレンド

駆けつけてくれる現場と、見捨てられる現場 — Ray・GitLab・GitHub障害・Debianの8択投票（2026/8/19 Linux・OSSトレンド）

はじめに

定例リリースを待たずに緊急パッチを出してくれるベンダーがいる一方で、「その製品はもう終わりました」とだけ言われる現場もあります。今回並べた5本を眺めていて印象に残ったのは、脆弱性の深刻度そのものよりも、直してもらえるかどうかが最初から決まっているという事実のほうでした。同じ「危機」でも、駆けつけてもらえる現場と見捨てられる現場に分かれた一日をお届けします。

1. GPUクラスターが採掘ボットに変わる — Ray の脆弱性が CISA KEV 入り

AI/ML ワークロードの分散実行基盤として広く使われている Ray に、ブラウザ経由でリモートコード実行が成立する脆弱性（CVE-2025-62593）があります。これが 2026年8月17日、CISA の KEV（既知の悪用された脆弱性）カタログに登録されました。連邦機関のパッチ期限は 2026年8月20日。つまり明日です。

NVD の詳細によれば、CVSS スコアは v4.0 で 9.4、v3.1 で 8.8。影響を受けるのは Ray 2.52.0 未満のすべてのバージョンで、修正版は 2.52.0 です。

不謹慎を承知で言うと、根本原因が実に人間くさくて笑ってしまいました。Ray のダッシュボード API は、ブラウザからの不正なアクセスを弾く手段として「HTTP リクエストの User-Agent ヘッダが Mozilla で始まるかどうか」だけを見ていました。ところが Firefox や Safari では fetch API の仕様上、スクリプトから User-Agent を書き換えられます。名乗りを信じるだけの防御は、名乗りを変えられた時点で終わります。

攻撃者はこれを DNS リバインディングと組み合わせます。自分が管理するドメインの DNS を、被害者のブラウザがスクリプトを読み込んだ少し後に 127.0.0.1 へ切り替える。ブラウザから見れば「同じドメイン」のままなので、同一オリジンポリシーをすり抜けて localhost の Ray ダッシュボード（既定ポート 8265）へリクエストが飛びます。あとは User-Agent を偽装した POST を /api/jobs に投げれば、任意のシェルコマンドがジョブとして実行されます。

つまり「自分のノート PC で Ray を起動したまま、ブラウザで知らないサイトを開いた」だけで成立しうる。ファイアウォールの外から殴られるのではなく、内側から自分の手で扉を開けてしまう形です。外からの攻撃を想像して守っていると、この経路は完全に死角になります。

悪用はすでに現実のものです。RondoDox という DDoS ボットネットは、脆弱性が公開される 2日前 にはすでに情報を入手して悪用を始めていました。「ShadowRay 2.0」と名付けられたキャンペーンでは、NVIDIA GPU を積んだクラスターが自己増殖型の暗号採掘ボットに改造されています。Oligo Security の調査レポートでは、1,000ノードを超えるクラスターが一つの組織で丸ごと乗っ取られ、クラウド換算で年間300万ドル超に相当する GPU が採掘に回された事例が報告されています。被害は採掘だけで終わらず、MySQL の認証情報や AWS の ECS/EKS ロール認証情報の窃取、SSH キーによる永続的なバックドアの設置、240GB を超える学習データとモデルの流出まで確認されています。インターネットに露出した Ray サーバーの数自体、ここ数年で大きく増えているとされています。

対応はシンプルです。

1
2
3
4
5

# pip によるアップグレード
pip install --upgrade "ray>=2.52.0"

# バージョン確認
python -c "import ray; print(ray.__version__)"

Ray 2.52.0 のリリースでは、ダッシュボード・CLI・API クライアントを含む各コンポーネントにトークン認証が導入され、名乗りだけに頼る形ではなくなりました。既定では無効なので、ローカル開発環境でも意識して有効化しておくのがおすすめです。すぐに上げられない場合の応急処置は、ダッシュボードを 127.0.0.1 にバインドして外から触れないようにすることです。

2. 7時間42分、世界の CI が止まった — GitHub 8月17日の大規模障害

2026年8月17日、GitHub が約7時間42分にわたる大規模障害を起こしました。Web と API で約20%、アーカイブや Raw コンテンツでは約50%のエラー率を記録し、CI/CD パイプラインも Pull Request も Issue の確認も、世界規模で止まりました。GitHub の公式ステータス履歴にタイムラインが残っています。

影響を受けたのは Web UI、REST/GraphQL API、GitHub Actions、Pull Requests、Issues、Webhooks、GitHub Copilot、そして企業向けの SAML/OIDC シングルサインオンです。SSO 利用企業はログインそのものができなくなりました。8サービス中7サービスの緩和が宣言された後も Copilot の認証系だけは復旧が遅れ、全サービス正常の宣言まではさらに4時間以上かかっています。Downdetector には障害ピーク時に 15,000件を超える報告が集まりました。

技術的な根本原因は、本稿執筆時点では公表されていません。GitHub は「調査には多くの側面があり、完全に理解できてから結論を出す」という趣旨の説明にとどめています。

気になるのは、これが単発の事故ではないことです。2026年7月だけで、サービス低下を伴うインシデントが8件発生しています。7月8日は設定メタデータの更新ミスでサービスディスカバリが壊れ、ピーク時96%のエラー率を出して7時間4分。7月9日は Actions のジョブ開始遅延で9時間18分。7月19日は証明書のライフサイクル管理の不具合でランナーが接続できなくなり5時間10分。8月17日の障害は、その月だけで2度目の大規模障害でした。

背景として語られているのが、AI エージェントブームによる需要の急増です。GitHub CTO の Vladimir Fedorov 氏は、2025年秋の時点で「10倍のスケールが必要」としていた見通しを、2026年2月には「30倍のキャパシティが必要」へと上方修正しています。AI コーディングエージェントがインフラに与える負荷は、当初の予測をはるかに超えていたということです。加えて GitHub は既存データセンターから Azure Central US への移行の途中にあり、7月の可用性レポートの時点で読み取りトラフィックの半分ほどが移行済みという過渡期にあります。旧インフラと新インフラが混在した状態は、それ自体が信頼性のリスク要因になりえます。

three-nines（99.9%）で換算すると、1年間に許される停止時間はおよそ8.7時間です。今回の1件でほぼ使い切った計算になります。備えとして現実的なのは、GitLab や Gitea、Forgejo へのミラーリング、git clone --mirror によるローカルのベアリポジトリ保持、そして act や Tekton、CircleCI といった GitHub に依存しない CI 経路の確保でしょう。https://www.githubstatus.com/ の RSS を Slack に流しておくだけでも、朝の「自分の環境が壊れたのか」という数十分の消耗は減らせます。

3. 「LLM を使っていいか」を8択で投票中 — Debian の全体決議

ここで少し肩の力を抜ける話題を。Debian プロジェクトが、AI/LLM をコード・コミュニケーション・パッケージ管理に使ってよいかを問う全体決議（GR）の投票を、2026年8月15日に開始しました。締め切りは 8月28日 23:59 UTC です。

驚くのは選択肢の多さです。複数の提案者がそれぞれ独立して草案を出した結果、Debian 公式の投票ページには8案が並んでいます。Debian 開発者（DD）が Condorcet 法（選好順位投票）で順位をつけて投票します。

  • 提案A（完全禁止）: 社会契約に LLM 使用禁止条項を追加する最も厳しい案。社会契約の改訂を伴うため、可決には3対1の超多数が必要
  • 提案B（条件付き許可）: 6条件つきで LLM 支援の貢献を許可する最も柔軟な案。Generated-By: などの Git トレーラーによる使用開示、機密情報のクラウド AI への送信禁止などを含む
  • 提案C（行動規範による禁止）: AI 生成の出力をそのまま持ち込む行為を CoC 違反として扱う
  • 提案D（Debian 固有作業での受容）: AI 生成コードを「完全に理解し自分の言葉で説明できること」を必須とする
  • 提案E（責任ある使用）: プロジェクトは中立。開示は推奨するが必須としない
  • 提案F（慎重なアプローチ）: 実行可能な範囲で人間の執筆を優先すると明記
  • 提案G（人間が作る Debian）: ツールではなく出力の側を制限する
  • 提案H（気候変動が決定要因）: LLM 利用が生態系破壊を加速するという懸念を主軸に据える唯一の案

議論の発端にあるのは、Debian のフリーソフトウェアガイドライン（DFSG）がライセンスと著作権の明確性を求めるのに対し、LLM 由来のコードはその明確性を担保しにくいという構造的な矛盾です。2025年4月にも同テーマの決議が提案されましたが、翌5月に提案者自身が撤回して先送りになっていました。GCC プロジェクトが 2026年7月に LLM 由来コードを禁止する方針を採った、とも伝えられており、これが議論を加速させた一因とされています。

個人的にいちばん興味深かったのが、セコンド（賛同者）の数です。最多は提案H の17名。著作権でも品質でもなく、気候変動を理由に据えた案が最も多くの賛同を集めているという構図は、正直まったく予想していませんでした。次点は「責任ある使用」を掲げる提案E の11名で、提案B・C・G が9名で並びます。Phoronix の報道や LWN.net の議論を見ても、コミュニティの温度感はかなり割れています。Hacker News では「執行コストが高すぎて実質機能しない」「上流が LLM を使っていれば意味がない」という懐疑論も目立ちます。

Debian の決定は多くの派生ディストリビューションに影響します。提案B や D が通れば Generated-By: トレーラーの運用整備が必要になりますし、Debian をベースに使う企業ではコントリビューションガイドラインの見直しが視野に入ってきます。8月28日の結果は追いかけておく価値があります。

4. 84バイトの「A」で落ちるルーター、しかし修正は来ない

さて、ここからが今回いちばん後味の悪い話です。TRENDnet の PoE+ 無線 LAN コントローラ「TEW-WLC100P」（ファームウェア 12.07b01）に、CVSS v3.1 で 9.6（Critical）のスタックベースバッファオーバーフロー（CVE-2026-75783）が 2026年8月18日に公開開示されました。NVD の記載によれば CVSS v4.0 では 8.6 です。

問題があるのは netifd、OpenWrt のネットワーク設定管理デーモンです。インターフェースの状態管理から DHCP クライアント処理まで、ルーターのネットワーク全体を仕切る中核コンポーネントで、TEW-WLC100P は OpenWrt ベースのファームウェアを採用しているためこれを内蔵しています。

その DHCP blobmsg ハンドラが、サーバーから受け取った DHCP オプションのデータをスタック上の固定長バッファへコピーする際に、長さを検証していませんでした。攻撃者が同じ LAN 上に不正な DHCP サーバーを立て、ターゲットの DHCP リクエストに対して細工した応答を返す。DHCP オプション42（NTP サーバーフィールド）に過大なデータを詰め込めば、スタックが溢れてリターンアドレスを上書きできます。

公開されている PoC スクリプトを見ると、ペイロードは 84バイトのパディングと4バイトのリターンアドレス上書き、合計88バイトです。この短さが逆に不気味で、再現の敷居がほとんどないことを意味します。

CVSS ベクトルは AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H。攻撃元区分が Adjacent（隣接ネットワーク）なので、インターネット側から直接殴られることはありません。ただし裏を返せば、同じ LAN に繋がってさえいれば認証もユーザー操作もなしに成立するということです。TEW-WLC100P は単体のルーターではなく複数のアクセスポイントを集中管理するコントローラですから、落ちれば配下の無線ネットワーク全体が巻き込まれます。ゲスト端末が同居する社内 Wi-Fi は、十分に現実的な射程内です。

そして最大の問題は、この製品がすでに EOL（製品終了）であり、TRENDnet 公式のサポートページを見る限り、セキュリティパッチが提供される見込みが事実上ないことです。CVSS 9.6 の穴が開いていて、PoC も公開されていて、直す人はいない。「もう直しません」と言われた現場が、ここにあります。

白状すると、私も前の職場で似た箱を一台、ラックの最下段で見なかったことにしていた時期があります。「誰も文句を言ってこないから動いているんだろう」で数年放置していたやつです。ああいう機器ほど、こういうニュースのときに真っ先に思い出して冷や汗をかきます。

自衛策としては次のあたりが現実解になります。

  1. 機器の交換（最優先）。サポートが継続している製品へ移行する
  2. ネットワーク分離。管理 VLAN に隔離し、一般ユーザーのネットワークからのアクセスをファイアウォールで遮断する
  3. 上流スイッチで DHCP スヌーピングを有効化する。不正な DHCP サーバーからの応答をブロックすれば、この脆弱性の引き金そのものを潰せる
  4. 未知の DHCP サーバーからの応答を IDS/SIEM で監視する

なお OpenWrt 本体でも 2026年7月に DHCPv6 デーモン odhcpd のスタックオーバーフロー（CVE-2026-53921、CVSS 9.8）が修正されています。netifd は OpenWrt ベースの多くの機器で共通に使われるコンポーネントなので、コードの共通性から他ベンダーのカスタマイズ機器に類似の問題が潜んでいる可能性はあります。手元の機器が OpenWrt ベースかどうか、一度確認しておいて損はありません。

5. 呪文ひとつでリポジトリが消える — GitLab の未認証 GraphQL 脆弱性

最後は、定例を待たずに緊急パッチが飛んできた話です。GitLab CE/EE の GraphQL ディレクティブ処理にコードインジェクションの脆弱性（CVE-2026-19478、CVSS 9.4）が見つかり、2026年8月17日にパッチがリリースされました。GitLab は通常、毎月第2・第4水曜日に定例パッチを出しています。その定例日を待たずに単独リリースしたという事実が、深刻度を物語っています。ちなみにこの8月17日は、さきほどの GitHub 障害が起きたのと同じ日です。世界中の開発者が GitHub の復旧を待っている裏で、自己ホスト GitLab の管理者は緊急アップグレードに追われていたことになります。

何ができてしまうのか。未認証の攻撃者がネットワーク越しに細工した GraphQL リクエストを送るだけで、パブリックプロジェクトの削除、ソースコードや CI/CD 設定を含むデータの改ざん、関連するユーザーデータの変更が可能でした。ログインは要りません。

GraphQL には @skip や @include のような「ディレクティブ」があり、クエリに付けることでフィールドの取得条件や動作を動的に制御できます。GitLab のような規模のアプリケーションは独自のカスタムディレクティブを多数定義していて、その引数がサーバー側のロジックへ渡る作りになっています。今回はその引数がサニタイズされないままコード実行のコンテキストに届いていました。特殊な呪文を唱えるだけで認証の扉が消えてしまう、というわけです。動画のタイトルはここから取っています。

NVD が確定させた CVSS ベクトルは AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H です。ネットワーク越し、低い攻撃複雑性、権限不要、ユーザー操作不要。機密性への影響は低（C:L）ですが、完全性と可用性は最高（I:H/A:H）。読み出せる情報は限られていても、消される・書き換えられる側の被害は最大という配分です。攻撃条件としてはもっとも緩い部類に入ります。

影響と修正のバージョンは次のとおりです。

ブランチ脆弱なバージョン修正バージョン
18.2〜18.11系18.2〜18.11.1018.11.11
19.0系19.0.0〜19.0.719.0.8
19.1系19.1.0〜19.1.519.1.6
19.2系19.2.0〜19.2.319.2.4

注意したいのは、18.2〜18.10系には修正版が提供されないという点です。該当する場合は 18.11.11 以上へ上げるしかありません。同じパッチでは GraphQL マルチプレックスクエリハンドラの CSRF 脆弱性（CVE-2026-19650、CVSS 7.1）も修正されています。未認証ユーザーが GET リクエスト経由でミューテーション（書き込み）を実行できるというものです。

1
2
3
4
5

# 現在のバージョン確認
gitlab-rake gitlab:env:info | grep "GitLab version"

# Omnibus GitLab の場合（例）
sudo apt-get install gitlab-ee=19.2.4-ee.0

GitLab.com と GitLab Dedicated はすでにパッチ済みで、利用者側の対応は不要です。影響を受けるのは自己ホスト環境だけ。GitLab 公式のパッチリリースノートによれば、このアップデートはマルチノード構成でもダウンタイムは通常発生しないとされており、新規のデータベースマイグレーションも含まれません。すぐに上げられない場合は、/api/graphql エンドポイントへの外部 IP からのアクセスを境界で制限するのが応急処置になりますが、あくまで時間稼ぎです。パッチ適用後は、監査ログを遡ってパブリックリポジトリへの予期しない変更がないか確認しておきましょう。

2026年8月18日時点で、悪用の報告も公開 PoC も確認されていません。具体的なディレクティブ名や PoC は GitLab の90日開示ポリシーにより、2026年11月中旬頃に公開される見込みです。猶予はあります。ただし、それは「今のうちに上げる」ための猶予です。

まとめ

5本を並べてみると、線がきれいに引けます。Ray も GitLab も、深刻な穴が見つかって、定例スケジュールを外してでも修正が出ました。GitHub は7時間42分止めた代わりに、少なくとも復旧に人を張り付けています。一方 TEW-WLC100P には、PoC まで公開されているのに直す人がいません。差を分けたのは技術的な難易度ではなく、その製品にまだ人が張り付いているかどうかです。

セキュリティの話をするとき、私たちはつい CVSS の数字で危険度を測ります。けれど本当に効くのは「これは直してもらえるのか」という問いのほうかもしれません。皆さんの現場にある機器は、まだ駆けつけてもらえる側でしょうか。それとも、もう見捨てられた側でしょうか。棚の奥で静かに動き続けている箱に、今日あたり一度目を向けてみてください。

参考リンク

© 2022 - 2026 Copyright(c) 2022-2025 SATO Daisuke. All rights reserved.
Hugo で構築されています。
テーマ Stack は Jimmy によって設計されています。