自社のWebサーバやリバースプロキシが、いま稼働しているバージョンを正確に言えるだろうか。 2026年6月8日、Apache HTTP Server 2.4.68がセキュリティリリースとして公開され、公式の脆弱性情報には13件の脆弱性が掲載された。うち1件は、HTTP/2の仕組みを突いてサーバのメモリを枯渇させる「HTTP/2 Bomb」と呼ばれるサービス妨害（DoS）で、CVE-2026-49975として採番されている。

本記事では、2.4.68の要点と影響範囲を一次情報で正確に押さえたうえで、個々のCVEより本質的な課題——「自社のサーバ群に、公開されたパッチを漏れなく当て続けられるか」という更新統制——をどう仕組み化するかを整理する。

この記事の要点

  • Apache HTTP Server 2.4.68（2026年6月8日公開のセキュリティリリース）で、公式に13件の脆弱性が修正された。
  • 「HTTP/2 Bomb」＝CVE-2026-49975（mod_http2のサービス妨害）はApacheの自己評価で深刻度Moderate。2.4.17〜2.4.67が対象で、2.4.68で修正。CVSSスコアはNVDで未付与のため、本記事では数値を断定しない。
  • 同種のHTTP/2増幅・接続枯渇という攻撃手法は、Apacheだけでなくnginx・IIS・Envoy・Cloudflare Pingoraなど複数のHTTP/2実装に及ぶ「プロトコル層の攻撃クラス」だが、CVE-2026-49975という採番はApache向け。
  • 本質的な課題は個々のCVEより、Web・リバースプロキシ群のバージョンを把握し、パッチを当て続ける「更新統制」が回っていないこと。

Apache 2.4.68の要点

Apache HTTP Server 2.4.68は、公式（Apache HTTP Server Projectの脆弱性情報）に基づき2026年6月8日に公開されたセキュリティリリースであり、合計13件の脆弱性が修正されている。

項目内容
リリースApache HTTP Server 2.4.68（2026-06-08・セキュリティリリース）
修正された脆弱性公式情報で13件
注目の脆弱性CVE-2026-49975（mod_http2のサービス妨害／「HTTP/2 Bomb」・深刻度Moderate）
CVE-2026-49975の対象Apache HTTP Server 2.4.17〜2.4.67（2.4.68で修正）

CVE-2026-49975は、HTTP/2のヘッダ圧縮（HPACK）などの仕組みを悪用して過大なメモリ割り当てを誘発するタイプの脆弱性で、Apache自身は深刻度をModerateと評価している。NVD（米国の脆弱性データベース）ではCVSSスコアが未付与（Awaiting Enrichment）の状態のため、本記事ではあえて数値スコアを断定しない。対象は2.4.17〜2.4.67で、2.4.68で修正された（採番年の関係でCVE-2025-…とCVE-2026-…が混在するが、これは正常だ）。

補足：HTTP/2の脆弱性は過去にも複数あり、別番号（例：mod_http2のメモリ破損や、より深刻度の高いHTTP/2関連のCVE）と混同しやすい。対応にあたっては「自社のApacheが2.4.68以降になっているか」を起点に、公式の脆弱性一覧で個別に確認したい。

「HTTP/2 Bomb」は自社だけの問題ではない

CVE-2026-49975はApacheに採番された脆弱性だが、その背景にある攻撃手法——少ないリクエストで大量のメモリ割り当てや接続保持を誘発する「HTTP/2増幅」——は、特定の製品固有ではなく、HTTP/2というプロトコルの実装全般に関わる攻撃クラスとして報告されている。研究者の公表によれば、Apacheに加えてnginx・Microsoft IIS・Envoy・Cloudflare Pingoraなど、複数のHTTP/2実装が影響を受けうるとされる。

ここで誤解しやすい点を正確に押さえておきたい。

  • CVE-2026-49975という「採番」はApache向けであり、「CVE-2026-49975がnginxやEnvoyに影響する」という言い方は正しくない。各実装はそれぞれ別に対応している（例えばnginxは別途の設定・修正で対処）。
  • 増幅率などの具体的な数値（実装ごとに差がある）は、研究者・報道による推計であり、Apache公式の数値ではない。本記事では具体的な倍率は断定しない。
  • 現時点で、JPCERT/CCの注意喚起やIPAの脆弱性情報として、2.4.68／CVE-2026-49975に特化した公式アナウンスは確認できていない。対応はApache公式の一次情報を起点とし、利用しているプロキシ／ロードバランサ製品のベンダー情報も併せて確認するのが安全だ。

要するに、自社が「Apacheを使っていないから関係ない」とは言い切れない。Webの前段に置いたリバースプロキシやAPIゲートウェイが何のソフトで動いているか——そこまで把握できているかが問われる。

本当の課題は「サーバ側の更新統制」

端末（PC・スマホ）のパッチ管理は意識されやすいが、サーバ側——Webサーバ・リバースプロキシ・APIゲートウェイ・ロードバランサの更新統制は、属人化したまま放置されがちだ。

  • どのサーバが・どのミドルウェアの・どのバージョンか、台帳が最新でない
  • クラウド移行やコンテナ化で構成が増え、「誰も把握していないApache」が残る
  • 構築時のまま塩漬けで、メジャー脆弱性が出ても気づけない
  • 公開サーバ（インターネットに面した資産）の棚卸しができていない

DoS系の脆弱性は「情報漏えいではないから後回し」と見られがちだが、HTTP/2 Bombのように少ないリクエストでサービスを停止させられる脆弱性は、事業継続に直結する。攻撃の入口になりうる未更新サーバを放置しないことが要だ。

サーバ更新統制チェックリスト

自社のサーバ・公開資産について、以下を確認したい。「いいえ」があれば、そこが統制の穴だ。

  • インターネットに面したサーバ・プロキシ・ゲートウェイの一覧（台帳）が最新化されている
  • 各サーバのOS・ミドルウェア（Apache/nginx等）とバージョンを把握している
  • Apache 2.4.68（および利用製品の最新版）への更新要否を判断できている
  • 重要な脆弱性情報を、公式・JPCERT/CC・IPA等から継続的に収集する担当・仕組みがある
  • 緊急パッチを一定期間内に適用するルールと検証手順がある
  • 構築後に放置された「塩漬けサーバ」や遊休資産が管理から漏れていない

これらを人手の棚卸しで回すのは限界がある。資産台帳・バージョン・脆弱性情報を継続的に突き合わせる仕組みがあってはじめて、「メジャー脆弱性が出たら、当該サーバを即座に特定して対応する」状態がつくれる。脆弱性対応とEOL（保守終了）対応、資産棚卸しを月額で仕組み化する考え方は、セキュリティ運用伴走（脆弱性対応・EOL対応・棚卸）で整理している。

脆弱性対応を「仕組み」にする

単発のパッチ適用で終わらせず、継続的に回す仕組みにするには、次の3点が有効だ。

  • 資産と公開面の可視化：どのサーバが外部に面し、何のソフトで動いているかを一元管理する。考え方はゼロトラスト・セキュリティの実装ガイド（中小企業向け）が参考になる。
  • 脆弱性情報の継続収集と判断：公式・JPCERT/CC・IPAの情報を継続的に拾い、自社資産への影響を判断する運用を回す。
  • 緊急時の対応体制：実際に悪用された場合に備え、検知・封じ込め・復旧の手順を用意する。考え方はインシデント対応支援で扱っている。

自社のインフラ構成に合わせてこうした運用を設計する場合は、セキュリティ事業として現状把握から組み立てるのが近道だ。

「自社サーバのバージョン、正確に言えますか」

GXOでは、公開資産の棚卸しから、脆弱性情報の継続収集・パッチ適用の運用設計、緊急時の対応体制づくりまで、サーバ側の更新統制を仕組みにする支援を行っています。「何が動いているか把握できていない」段階のご相談を歓迎します。

サーバ更新統制を相談する → GXO お問い合わせ

※ 営業電話はしません ｜ オンライン対応可 ｜ 構想段階の相談だけでもOK

よくある質問（FAQ）

Q1. すぐにやるべきことは？

まず自社で稼働しているApache HTTP Serverのバージョンを確認し、2.4.67以前であれば2.4.68以降への更新を検討する。HTTP/2を有効化している公開サーバは特に優先度が高い。併せて、Webの前段に置いているリバースプロキシ／APIゲートウェイ（nginx・Envoy・各製品）についても、ベンダーの最新情報と更新有無を確認したい。

Q2. CVE-2026-49975はどれくらい危険？

mod_http2のサービス妨害（DoS）で、Apache自身の評価は深刻度Moderate。少ないリクエストでメモリ枯渇を誘発し、サービスを停止させられる可能性がある。ただしNVDではCVSSスコアが未付与の状態のため、本記事では具体的な数値スコアは示していない。情報漏えい型ではないが、事業継続（可用性）に影響しうるため、HTTP/2を有効化した公開サーバでは早めの対応が望ましい。

Q3. Apacheを使っていなければ関係ない？

HTTP/2増幅という攻撃手法自体は、nginx・IIS・Envoy・Cloudflare Pingoraなど複数の実装に関わる「プロトコル層の課題」として報告されている。自社がApacheを使っていなくても、Webの前段に何のソフトを置いているかを把握し、各製品のベンダー情報を確認することが必要だ。「使っていないつもりが、実は使われていた」を防ぐには、公開資産の棚卸しが起点になる。

Q4. パッチ適用以外に備えはある？

更新を仕組み化する（資産台帳・バージョン・脆弱性情報を継続的に突き合わせる）ことが本質的な備えになる。加えて、万一悪用された場合に備えた検知・封じ込め・復旧の体制（インシデント対応）も整えておきたい。

まとめ：パッチは「当てる」より「当て続けられる仕組み」を

2026年6月8日に公開されたApache HTTP Server 2.4.68では13件の脆弱性が修正され、うちHTTP/2 Bomb（CVE-2026-49975・対象2.4.17〜2.4.67）はサービス妨害につながりうる。だが本質的な課題は、Web・リバースプロキシ・APIゲートウェイといったサーバ群のバージョンを把握し、公開されたパッチを漏れなく当て続けられるか——というサーバ側の更新統制にある。人手の棚卸しには限界があり、資産・バージョン・脆弱性情報を継続的に突き合わせる仕組みづくりが、継続的な防御につながる。

GXOは、公開資産の棚卸しから脆弱性対応の運用設計、緊急時の対応体制づくりまで支援している。詳細はセキュリティ運用伴走・セキュリティ事業・インシデント対応支援をご覧いただきたい。

公開資産の棚卸しから、脆弱性対応の仕組み化まで

「外に面しているサーバが何台あるかも正確に分からない」状態でも大丈夫です。現状把握から、脆弱性情報の収集・パッチ適用・緊急時対応の設計まで、貴社の運用に合わせて整理します。

セキュリティ運用の現在地を相談する → GXO お問い合わせ

参考情報

  • Apache HTTP Server Project「Apache HTTP Server 2.4 vulnerabilities」公式（2.4.68で13件修正・CVE-2026-49975はmod_http2のサービス妨害／深刻度Moderate・対象2.4.17〜2.4.67）：https://httpd.apache.org/security/vulnerabilities_24.html
  • NVD CVE-2026-49975（執筆時点でCVSSスコアは未付与＝Awaiting Enrichment。本記事で数値を断定しないのはこのため）：https://nvd.nist.gov/vuln/detail/CVE-2026-49975
  • ※ 同種のHTTP/2増幅攻撃が複数実装（nginx・IIS・Envoy・Cloudflare Pingora等）に及ぶという指摘、および増幅率の推計は、研究者・報道による公表に基づく。各実装の影響・対応はそれぞれのベンダー情報を確認のこと。
  • ※ 執筆時点で、JPCERT/CCの注意喚起・IPAの脆弱性情報として2.4.68／CVE-2026-49975に特化した公式アナウンスは確認できていない。最新情報はApache公式および各ベンダーの一次情報を参照。

関連記事