セキュリティ
セキュリティ入門 04|セキュリティ予算はいくらにするか:まず一日止まったらいくら損するかを訊く
他社がセキュリティ予算をいくら組んでいるか、売上の何パーセントかを訊いても、あなたの会社の参考にはなりません。予算の上限を決められるのは、自分のシステムが一日止まったら、あるいは一度漏洩したらいくら払うことになるかです。本稿は経営者が自分で計算できる四段階の式を示します。
これは恩梯科技(NT IT)セキュリティ週報の第 2 号です。2026 年第 44 週(10 月 26 日以降)を対象とし、情報は 11 月 1 日時点までを読み取っています。
先に結論です。今週は新しい大きな脆弱性はほとんどありませんが、前号で扱ったものの状況が変わりました。前号の冒頭に並べた PHP のリモートコード実行 2 件、Brotli の展開処理の脆弱性、そして GitLab の 1 件は、いずれも今週、米国 CISA の「悪用が確認された脆弱性」カタログに追加されました。これは、実際の攻撃で使われていると当局が判断したという意味です。前号を読んで「もう少し待とう」と決めた方にとって、今週の知らせは、その待っていた期間に攻撃が始まっていたということになります。
今週、新しく出てきて、かつ多くの方が手を動かすべき唯一の項目は WordPress 7.1.4 です(10 月 28 日)。公式が挙げた 1 件目が、アップグレード処理そのものの弱点で、アップグレード中の時間帯にリモートコード実行につながりうるものです。また、改変された Claude Code 拡張が Cursor のマーケットプレイス経由で配布され、入れてしまうと SSH のバックドアを残そうとします。
もう 1 件、新しい脆弱性ではありませんが、単独で読む価値があります。Symfony が「5 月のアナウンスは誤りだった」と自ら訂正しました——修正は書かれていたものの保守ブランチに取り込まれておらず、5 か月間どのリリースにも入っていなかったというものです。バージョン番号が一致していても修正が入っているとは限らない、という話を第 6 節で扱います。
〔公式:米国 CISA〕米国サイバーセキュリティ・インフラセキュリティ庁(CISA)は「悪用が確認された脆弱性」カタログ(Known Exploited Vulnerabilities、KEV)を維持しています。ここに載るということは、理論上悪用可能なだけでなく、実際の攻撃で使われていると当局が判断したという意味です。参照したのは CISA 自身が公開しているデータファイルで、バージョンは 2026.10.30、その時点の総数は 1766 件でした。
今週(10 月 26 日から 10 月 30 日)追加された項目は以下です。最初の 3 組は前号の第 1 節から第 3 節そのものです。
読み違えやすい点が 2 つあります。1 つ目は、カタログの「期限」欄が米国の連邦機関向けの修正期限であり、一般企業に対する法的な期限ではないことです。これは私たちの推測ではありません。各項目の必要措置欄が CISA の行政指令(BOD 26-04)を指しており、その指令自身が、適用対象は「連邦情報システム」における機関の資産であり、対象は連邦文民行政機関だと明記し、さらに「調達契約で別途求められる場合を除き、本指令は請負業者には適用されない」と書いています。したがってその日付は「当局がこの件をどれだけ急ぎと見ているか」の参考にはなりますが、読者の契約上の義務ではありません。2 つ目は、今週追加された項目の「ランサムウェアでの利用」欄がいずれも「不明」である点です——これは「なし」ではなく「データがない」という意味です。
〔公式:シンガポール CSA〕シンガポールのサイバーセキュリティ庁は 10 月 30 日に注意喚起を出し、その 1 文目は、攻撃者が複数の製品に影響するこの重大な Brotli 脆弱性を実際に悪用しており、影響を受けるシステム上でリモートから任意コードを実行し、あるいは機密情報を漏えいさせうるため、直ちに修正を適用すること、という内容です。公式はこの脆弱性の CVSS v3.1 スコアを 9.8 とし、PoC(概念実証)が公開されており、報告によれば実際に悪用されていると記しています。
公式は悪用の前提条件も書いています。影響を受けるアプリケーションが、攻撃者が制御できる Brotli 圧縮データを展開する必要があるという点です。この限定は重要で、自分のシステムが対象かどうかを決めます。
公式が挙げた影響範囲は、Node.js 22.x の 22.23.4 より前、24.x の 24.22.1 より前、26.x の 26.12.1 より前、および Microsoft .NET 8、9、10、11 です。ただしその一覧は公式自身が「網羅的ではない」と明記しており、PHP は載っていません。
〔公式:PHP〕今週 PHP の利用者が実際に手を動かすべきなのはここです。PHP プロジェクトは 10 月 26 日、再ビルドした Windows パッケージ PHP 8.5.12-1、8.4.27-1、8.3.36-1、8.2.35-1 を公開しました。これらには Brotli 1.2.1 が含まれ、同じ CVE-2026-111497 を修正します。公式はさらに 3 点を書いており、どれか 1 つを読み落とすと判断を誤ります。
-1 という接尾辞は依存関係を更新した Windows パッケージの再ビルドを示すものであり、これらは同じ PHP ソースリリースを用いるため、PHP ランタイムのバージョンは変わらないと明記しています。言い換えると、php -v を実行しても入れ替えたかどうかは分かりません。この最後の点は、〈セキュリティ入門 01〉で示した「バージョン番号を照合する」方法では見落とす形です。今回確認すべきなのは PHP のバージョンではなく、Windows パッケージの再ビルド番号と、その中の Brotli のバージョンです。
スコアの食い違いは前号から続いています:シンガポール CSA は CVSS v3.1 9.8 と書き、Node.js 公式は 10 月 21 日のセキュリティリリースで同じ CVE を high としています。9.8 という数値は Node.js の公式アナウンスには見つかりませんでした。どちらの区分を取っても、修正版は同じ組み合わせです。
〔公式:GitLab〕CISA が追加した CVE-2026-97229 は、公式の表題では CI/CD の正規表現コンパイラにおける整数オーバーフローの問題で、深刻度は critical、CVSS 10.0、修正版は 19.2.8/19.3.5/19.4.2、公開日は 10 月 12 日です。影響範囲は公式の記載で、19.2 から 19.2.8 より前、19.3 から 19.3.5 より前、19.4 から 19.4.2 より前です。
したがって照合のしかたは次のようになります。
公式は自己ホストの利用者向けに、悪用の試みを探すための脅威検知ルールを 6 件公開しています。
〔公式:GitLab〕今週、GitLab はもう一つの修正リリースを出しており、それは下の第七節の eMudhra と同じ流れのものです。10 月 29 日に 19.5.3、19.4.5、19.3.7、19.2.10、19.1.10、19.0.11、18.11.14 を公開しました(公式は 19.5.2 と 19.4.4 を飛ばしたとも書いています)。対象は CVE-2026-111943 で、公式が付けた表題は逐語で「GitLab CE/EE において、侵害された eMudhra 中間 CA 証明書への信頼を削除した」です。公式の説明では、削除したのは秘密鍵が侵害された 8 枚の eMudhra 中間証明書で、GitLab 自身が同梱する証明書ストアから取り除いたとしています。影響範囲は 18.11.14 より前のすべてのリリース、および 19.0 から 19.5 の各修正版より前です。
この組はリモートコード実行の修正ではありませんが、見落としやすい後続作業が 3 つあります。3 つとも公式が書いていることです。GitLab を上げても Runner は更新されないため、自己ホストの Runner は別途 19.5.1 に上げる必要があります。AI Gateway も別途上げる必要があります(公式が挙げているのは 18.11.8、19.0.13、19.1.9、19.2.5、19.3.3、19.4.3、19.5.3 以降)。そして自前の ca-certificates を含む CI/CD ジョブイメージは作り直しが必要です——証明書ストアはイメージの中にあるので、サーバーを上げても入れ替わりません。GitLab.com は公式によれば既に修正済みの版で動いており、GitLab Dedicated で 19.4.3-internal0 以降のテナントはすでに修正を含むため対応は不要だとしています。
どうやってこれを見つけたかは書き残す価値があります。一覧ページが当てにならないからです。GitLab の修正リリース一覧ページは私たちの環境では項目が何も読み取れませんでした(だから本節の前の版では「今週新しい修正リリースがあったかは確認できない」と書いていました)。公式の修正リリースのフィード(https://docs.gitlab.com/releases/patch-releases.xml)にはデータがあり、そのフィード自身の更新時刻は 10 月 29 日なので、19.5.3 の組はフィード上でも最新の組です。GitLab の修正を追うなら、あのページではなくフィードを追ってください。
〔公式〕WordPress は 10 月 28 日に 7.1.4 を公開しました。これが今週、新しく出てきて多くの方が手を動かすべき唯一の項目です。公式が挙げた修正は 13 件で、その 1 件目は、WordPress のアップグレード処理における弱点で、アップグレード中の時間帯にリモートコード実行につながりうるものです。残りの多くは保存型のクロスサイトスクリプティングで、ブロックのマークアップ、Interactivity API、Customizer の選択的リフレッシュ、カテゴリーブロック、ユーザーのログイン名、プレイリストと画像のブロック、コメントのページ送りブロックなどに分布しています。ほかに Interactivity API の保存型サービス停止 1 件と、権限の問題(当該投稿を編集する権限がない特権ユーザーがメモを読めてしまう)1 件があります。
13 件のうち 1 件は第 7 節と同じ線上にあります:公式は、今回あわせて同梱のルート証明書も更新したと書いており、理由は eMudhra の失効です。つまりあの件の影響範囲はブラウザとサーバー側の言語処理系だけでなく、CMS が同梱している信頼リストにも及びます。
〔公式:Cursor〕10 月 29 日、改変された Claude Code 拡張が Cursor の拡張マーケットプレイス経由で流通しました。公式の説明では、この拡張は悪意あるコードを実行し、永続的な SSH バックドアの設置を試み、あわせてホストと利用者の情報を収集し、攻撃者が管理する SSH 鍵を追加しようとします。
これは前号の LiteLLM の件と同じ形で、2 つあわせて、調達と運用の両方にとって具体的な意味を持ちます。入れたものが改変されていないかどうかは、配布経路の安全性に依存し、そのプロジェクトのコードの出来には依存しません。最後の「信頼できるマシンから資格情報を入れ替える」という手順はとくに飛ばされがちですが、すでにバックドアが入っている可能性のあるマシン上でパスワードを変えるのは、新しいパスワードも渡すのと同じことです。
〔公式:Symfony〕Symfony は 10 月 29 日、10 月 28 日のリリース(5.4.55、6.4.49、7.4.22、8.1.10)に含まれるセキュリティ項目についての説明を公開し、その一部が自己訂正になっています。公式の説明では、5 月に公開した CVE-2026-45070 は Mime ヘッダーのパラメータ名を経由したメールヘッダーインジェクションで、当時は 5.4.52、6.4.40、7.4.12、8.0.12 で修正済みと書いたが、それは誤りだった——修正はコミットされていたが、そのコミットが保守ブランチに取り込まれず、どのリリースにも含まれていなかった、というものです。
〔公式:Symfony〕脆弱性そのもの:公式の CVE ページの説明では、Content-Type や Content-Disposition のような構造化ヘッダーの直列化を担うコンポーネントが、パラメータの「値」は検証して正しくエンコードする一方、パラメータの「名前」は検証しておらず、与えられた名前をそのまま直列化後のヘッダーへ出力していました。そのため、パラメータ名を信頼できない入力から組み立てるプログラムでは、名前の中に改行バイトを入れて現在のヘッダーを途中で終わらせ、追加のヘッダーを注入できます。同ページは影響範囲として、5.4.55 より前、6 系の 6.4.49 より前、7 系の 7.4.22 より前、8 系の 8.1.10 より前を挙げており、現在そのページ自身に訂正が添えられ、以前修正版として挙げていた 5.4.52、6.4.40、7.4.12、8.0.12 には修正が含まれていないと明記しています。
今回は実際に修正されています:5.4.55、6.4.49、7.4.22、8.1.10。公式はあわせて、Symfony 8.0 は保守対象外になったため、8.0 の利用者は 8.1.10 へ上げる必要があるとしています。上げるべきかどうかの判断基準も具体的です。アプリケーションが、利用者の入力に由来するパラメータ名で Mime ヘッダーを組み立てているなら、上げる。
同じリリースの変更履歴には CVE-2026-109413(Yaml)、CVE-2026-108082(HttpFoundation)、CVE-2026-109449(ExpressionLanguage)も並んでいますが、公式はこれらについて今回のリリースでは何も変わっていないと明言しています。修正はそれぞれのブランチでもっと早く公開済みで、6.4 系は 6.4.45/6.4.46/6.4.48、7.4 系は 7.4.18/7.4.19/7.4.21、8.1 系は 8.1.6/8.1.7/8.1.9、5.4 系は 3 件とも 10 月 15 日公開の 5.4.54 で修正されています。変更履歴に CVE が並んでいることは、いま初めて適用できる修正が出たことを意味しません。この段落はまさにその誤読を避けるために置かれています。
この件は、深刻度よりも運用上の意味のほうが大きいです。「公式がそのバージョンで修正したと言っている」ことと「そのバージョンに実際に修正が入っている」ことは別の話です。〈セキュリティ入門 01〉で示した方法はバージョン番号の照合ですが、今回はその照合が誤った答えを返します。この隙間を埋められるのは、修正後に検証することだけで、アナウンスの記述を読むことではありません。
前号の第 3 節で、eMudhra の中間証明書 8 枚の秘密鍵漏洩を扱いました。今週、追跡レポートが出ています。
〔公式:Cloudflare、同社自身のネットワークについて〕Cloudflare の 10 月 30 日の記事は、まず鍵がどれほど弱かったかを明示しています。本来 115 桁の数であるべきところ、8 つの値は 4、56、66、115、155、156、230、237 でした。記事は、今回の件が過去の認証局侵害とは根本的に異なるとし、理由として影響を受けた中間証明書の秘密鍵が、公開されている証明書そのものから誰でもほぼ即座に復元できた点を挙げています。また、eMudhra が公開認証局事業からの撤退を表明し、鍵生成スクリプトの誤りだと述べている一方、そのスクリプトはまだ公開されていないとも書いています。
測定された内容(範囲は Cloudflare 自身の接続に限られます。記録の展開が完了した 10 月 21 日からの 1 週間)は、弱い鍵を用いたハンドシェイクの試行が約 22,000 件で、そのうち 3 分の 2 はテストサイトの取得でした。約 160 件は様子が異なり、証明書のサブジェクト代替名が、ハンドシェイクで要求されたホスト名とは無関係な他組織のドメインを名乗っていました。その一部は消費者向け IoT 機器に関連するドメインで、これらの偽造証明書は鍵の漏洩後に作られ、一部は有効期間が 2 年を超えており、公開認証局が発行できる期間より長いものでした。
あわせて読むべき 2 文:Cloudflare は、弱い鍵が同社の接続の傍受に使われた証拠は現時点でないとしつつ、同じ段落で、これは入念に狙われた傍受を排除するものではないとも書いています。そして最も覚えておく価値があるのは数字ではなく時刻です。確認された偽造証明書の 1 枚は 10 月 20 日 18:19(UTC)付で、Mozilla のバグ報告が公開されてから 1 時間も経っていません。
未対応の利用者がどれだけ残っているかについては、Cloudflare はチャレンジページから探索用の接続を送って推定しており、1 週間で約 5,000 万回の探索です。公式が先に偏りの注意書きを置いており、その注意書きは数字と一緒に読む必要があります:これらのページへの通信は設計上大きく偏っており、確認されていないボットが多数含まれ、しかも JavaScript を実行するクライアントだけが探索を送ります。その前提のうえでの観察は、最新に保たれた現代的なブラウザはおおむね対応済みだが、ボットと古いブラウザはそうではなく、Android WebView のような組み込みブラウザは遅れており、30〜40% がまだそれらの証明書を受け入れているというものです。
自社サイトがアプリ内のウェブ表示で使われている場合、あるいはクライアント機器が IoT 機器である場合、ブラウザの段落よりこの段落のほうが近い話になります。
〔公式〕Chrome の安定版と延長安定版が、Windows と Mac で 156.0.8078.79/.80、Linux で 156.0.8078.79 に更新されました。公式は、今後数日から数週間かけて順次配信されるとしています。今回は 21 件のセキュリティ修正を含み、critical と評価されたのは CVE-2026-76024(MediaStream のメモリ破壊)1 件のみです。残りの多くは high で、FileSystem、Quota、Skia、V8、Blink などに集中し、ほかに medium が 1 件あります。このリリースノートには、いずれかの脆弱性が実際に悪用されたという記述はありません。
〔公式〕LiteLLM の事後説明(10 月 30 日):前号の第 8 節で、LiteLLM のリリース経路が 10 月 21 日に侵害された件を扱いました。今週、公式が振り返りを公開しており、主題は「10 月 21 日のあとに何を変えたか」で、3 月以降に作った管理策がなぜそのリリースを止められなかったのか、そして identity・資格情報・検知の面での変更が含まれています。この AI ゲートウェイに依存しているシステムがあるなら、前回の事故報告よりこちらのほうが重要です——同じ経路がまた壊れるのかという話だからです。
同じプロジェクトは 10 月 27 日に、重大な脆弱性の修正を公開前に特定の利用者へ先に提供するためのプライベートレジストリも発表しました。これは調達の観点で考えておくべき設計です:修正のタイミングそのものが段階的なサービスになるという意味になります。その条件や価格は確認していないため、ここでは存在することだけを記録します。
〔公式〕GitHub(10 月 28 日):GitHub の変更履歴に今週のセキュリティ事故の告知はありませんでしたが、運用に関わる項目が 2 つあります。Dependabot の警告を「到達可能性の解析」で優先度付けできるようになったこと(つまり、脆弱なコードが自分のプロジェクトから到達できるのかを先に見る)と、秘密情報の漏洩に対するプッシュ保護が、あらかじめ定義されたパターン以外にも広がったことです。どちらも修正ではなく、「どれを先に直すか」という問いに答えやすくする道具です。
8dbb08b に対応すると明記しています。当該アナウンスの影響範囲は「v12.68.0 より前」と「13.29.0 より前」で、前者には下限がありません——したがって 10.x と 11.x はその範囲から除外されていませんが、アナウンスはそれらの修正版を挙げていません。私たちはコードを読みました:11.x の v11.56.1(8 月 25 日)に含まれる修正 commit は 1 つで、TokenGuard.php の user() と validate() に文字列かどうかの検査を加え、テストを 2 件追加しています。公式が名指しした 12.x の修正と同じ形です。ただし 11.x が修正済みだと述べた公式の文章はありません——これは同じ変更から私たちが推定したものであり、公式の見解ではありません。10.x や 11.x を使っている場合は、アナウンスの日付ではなくこのバージョンと照らし合わせる必要があります。週報は週 1 回、出典リストは固定で、毎号「確認したが何もなかったもの」と「裏付けが取れなかったもの」を一緒に挙げます——読者には私たちが何を漏らしたかが見えないので、私たち自身が言う必要があります。次号は 11 月 2 日からの 1 週間を対象とし、すでに予定が 1 つ入っています。Next.js の 11 月のセキュリティリリースが 11 月 3 日です。
恩梯科技(NT IT)は受託開発を出発点とするシステムソフトウェア会社で、現在は AI システムの長期的な運用保守を手がけています。手元のシステムのどれが今週のセキュリティ更新に追随すべきか分からない場合は、システム健康診断の予約から始められます。
深く取り組む価値のある、少数の企業と長期的な関係を築きます。
お困りですか?
LINEで直接ご相談ください