Javaアプリケーションで広く使われるHTTP通信基盤ライブラリApache HttpComponents Core（HttpCore）に、サービス拒否（DoS）につながる脆弱性が2件公表されました。CVE-2026-54428（HTTP/2のHPACKデコーダ）とCVE-2026-54399（HTTP/1.1メッセージパーサ）で、いずれもCVSS 3.1基本値7.5（High）です。影響を受けるのはHttpCore 5.4.2以前および5.5-beta1以前で、修正版5.4.3が2026年6月25日にリリースされています。データ窃取やコード実行ではなく可用性（サービス停止）に限定した影響ですが、HttpCoreは自覚なく間接的に組み込まれている（推移的依存）ことが多く、まず「自社が使っているか」の棚卸しが要点になります。
この記事でわかること
- 2件の脆弱性が「何を、どう悪用されるのか」の要点
- 影響を受けるバージョンと、そもそも自社が使っているかの見分け方
- DoSに限定される影響の意味と、優先度をどう判断するか
- 情シスが今すぐ確認すべきことと、公的な参照先
何が起きたのか
Apache HttpComponents Core（通称HttpCore）は、HTTPプロトコルの低レベル処理を担うJavaライブラリです。上位のHTTPクライアント「HttpComponents Client（HttpClient 5.x）」の土台であり、多くのJava製アプリケーション・フレームワーク・ミドルウェアが直接または間接的に利用しています。
今回のポイントは、いずれも受信したHTTPメッセージの解析処理でリソースを使い切ってしまうタイプの脆弱性であることです。攻撃者が細工したデータを送ることで、メモリ枯渇などを引き起こしてサービスを停止させられる可能性があります。
2件の脆弱性の要点
| CVE | 該当コンポーネント | 内容 | CVSS 3.1 |
|---|---|---|---|
| CVE-2026-54428 | HTTP/2（httpcore5-h2） | HPACKデコーダにおけるリソース割り当ての制限不備。過大な圧縮ヘッダブロックを受信するとメモリを使い切るおそれ（CWE-400/770） | 7.5（High） |
| CVE-2026-54399 | HTTP/1.1（httpcore5） | メッセージパーサのリソース消費の制御不備。過剰な数・長さのヘッダを含むメッセージでDoSが生じるおそれ | 7.5（High） |
両者ともCVSSベクトルは AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H です。機密性（C）・完全性（I）への影響はなく、可用性（A）だけがHigh——つまり「情報は盗まれないが、サービスが落ちる」種類のリスクだと読み取れます。認証不要・ネットワーク越し・攻撃の複雑さも低いため、狙われれば成立しやすい点は軽視できません。
影響を受けるのはどの環境か
NVDによると、影響を受けるのは以下です。
- Apache HttpComponents Core 5.4.2 以前
- Apache HttpComponents Core 5.5-beta1 以前（開発版）
修正版は5.4.3（2026年6月25日リリース）および5.5-beta2です。なお5.4.3は本脆弱性以外に、非同期TLSセッションのバックプレッシャ処理の回帰など複数の不具合修正も含むメンテナンスリリースとして公開されています。
「HTTPクライアントなのに、なぜDoS？」という疑問
Q. 自社は外向きのAPIを叩くクライアント用途で使っているだけ。それでも関係あるのか。
A. 影響の有無は「誰が送ってくるデータを解析するか」で決まります。
HttpCoreはクライアント側・サーバ側の両方の処理を提供します。DoSが問題になりやすいのは、攻撃者が制御できるHTTPメッセージを解析する場面です。具体的には次のようなケースが挙げられます。
- HttpCoreベースでHTTPサーバ／リバースプロキシ／APIゲートウェイを実装し、インターネットからのリクエストを受けている
- Webhook受信やSSRF的な経路など、信頼できない相手のサーバからのレスポンスをクライアントとして解析している
逆に、通信先が自社管理下の信頼できるサーバに限られるクライアント用途であれば、直ちに悪用されるリスクは相対的に下がります。ただし「本当に通信相手を限定できているか」は思い込みになりがちな点で、後述の切り分けが要ります。
現場目線の課題——「使っている自覚がない」問題
この手のライブラリ脆弱性で毎回つまずくのが、推移的依存（transitive dependency）です。自社のpom.xmlやbuild.gradleにHttpCoreを直接書いていなくても、HttpClientや各種SDK、フレームワーク経由で引き込まれていることが珍しくありません。「使っていないつもりが、実は動いている」状態です。
限られた人員で稼働中のJavaアプリすべての依存関係を把握するのは、正直に言って骨の折れる作業です。だからこそ、脆弱性が出るたびに手作業で追うのではなく、SBOM（ソフトウェア部品表）やSCA（ソフトウェア構成分析）の仕組みで「どこに何が入っているか」を平時から見える化しておくことが、こういう場面で効いてきます。
自社で使っているかの見分け方
- Mavenなら
mvn dependency:tree、Gradleならgradle dependenciesでorg.apache.httpcomponents.core5:httpcore5/httpcore5-h2の有無とバージョンを確認する - SBOM（CycloneDX/SPDX）やSCA/脆弱性スキャナで
httpcore5を検索する - 稼働中の成果物（jar/warの中身）を対象に確認する。ビルド定義だけでなく実際にデプロイされているバージョンを見るのが確実
情シスはどうすべきか
基本方針はシンプルで、HttpCoreを5.4.3以降へ更新することです。そのうえで、優先度は「インターネットに面していて、外部からのHTTPメッセージを解析しているか」で判断すると整理しやすくなります。
- 優先度・高：外部公開のサーバ／プロキシ／ゲートウェイでHttpCoreを使用 → 早期にアップデート。すぐに更新できない場合は、前段のリバースプロキシやWAFでヘッダ数・ヘッダ長・リクエストサイズの上限を設ける緩和策を検討
- 優先度・中〜低：内部通信・信頼できる相手限定のクライアント用途 → 通常のパッチ運用の中で更新
依存管理やアップデート運用そのものの進め方は、公的なガイドラインを土台にするのが確実です。まずはIPAの資料に一度目を通しておくとよいでしょう。
- IPA「中小企業の情報セキュリティ対策ガイドライン」——資産の把握と更新運用の基本
- 一次情報：NVD CVE-2026-54428 / NVD CVE-2026-54399、Apache HttpComponents 公式ニュース
あわせて、脆弱性が公表されるたびに現場が右往左往しないよう、「どのシステムにどのライブラリが入っているか」を継続的に把握できる体制づくり——SBOMの整備や、開発チームへの依存管理の啓発——を地道に進めておくことが、中長期では最も効いてきます。
まとめ
- Apache HttpComponents Core（HttpCore）にDoS脆弱性2件（CVE-2026-54428／54399、いずれもCVSS7.5）。影響は可用性のみで、情報漏えいやコード実行ではない。
- 影響は5.4.2以前／5.5-beta1以前。修正版5.4.3（2026-06-25）へ更新するのが基本。外部から不正なHTTPメッセージを受ける環境ほど優先度が高い。
- HttpCoreは推移的依存で入り込みやすい。SBOM/SCAや依存ツリーの確認で「自社が使っているか」をまず棚卸しすることが最初の一歩。
出典：NVD – CVE-2026-54428、NVD – CVE-2026-54399、Apache HttpComponents Project News、Security NEXT
