OpenSSLに「HollowByte」と呼ばれるDoS脆弱性-わずか11バイトのペイロードでメモリを枯渇させる新手口|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月22日更新日時: 2026年07月22日

Oktaのレッドチームは2026年7月16日、OpenSSLに存在するサービス拒否(DoS)の脆弱性HollowByteに関する技術解説を公開しました。TLSハンドシェイクが始まる最初の段階で、OpenSSLが通信相手の自己申告した長さをそのまま信用してメモリを確保してしまう挙動を悪用したもので、わずか11バイトの悪意あるペイロードを送りつけるだけで、認証を一切必要とせずサーバーに不釣り合いに大きなメモリ割り当てを強制できます。さらに厄介なのは、この攻撃がLinuxで広く使われるglibcのメモリ管理の癖と組み合わさることで、攻撃を止めた後もサーバーのメモリ使用量が高止まりしたまま戻らなくなるという永続的な影響を及ぼす点です。OpenSSLは今回の問題を正式なセキュリティアドバイザリ・CVE番号の付与を伴わない、内部的な堅牢化(ハードニング)修正として扱っています。

サマリー

OpenSSLの脆弱性HollowByteは、TLSハンドシェイクの最初期段階で送信される4バイトのヘッダー内にある長さ情報を、実際のデータが届く前に無条件で信用しメモリを確保してしまう挙動に起因します
わずか11バイトの悪意あるペイロードで、最大131KBのメモリ確保を強制でき、認証前かつ未認証の攻撃者から悪用可能です
接続を保持し続けてスレッドを枯渇させる手口自体はSlowlorisに類似していますが、HollowByteはLinuxのglibcが小〜中サイズのメモリ確保をOS側にすぐ返却せず再利用のために保持し続ける挙動と組み合わさることで、ヒープの断片化と常駐メモリ使用量(RSS)の継続的な増加を引き起こします
攻撃者が接続を切断した後もサーバーのメモリは膨張したままとなり、回復させるにはプロセスを強制終了する以外に方法がありません
検証実験では、メモリ1GBの環境で547MBの断片化したメモリを抱えたままOOM Killerによって強制終了され、メモリ16GBの環境でも通常の接続数上限を超えないまま全体の25%のメモリを占有できることが確認されており、接続数の制限による従来型の対策では防げません
OpenSSLはApache・NGINXなどのWebサーバー、Node.js・Python・Ruby・PHPなどの言語ランタイム、MySQL・PostgreSQLなどのデータベースを含む広範なソフトウェアに組み込まれているため、影響範囲は極めて広範です
修正はバッファを段階的に拡張する方式へ変更する形で行われ、OpenSSL v4.0.1で正式反映されたほか、3.6.3・3.5.7・3.4.6・3.0.21にサイレントにバックポートされています。OpenSSLは今回の問題を正式なCVEを伴うセキュリティアドバイザリではなく、堅牢化のための修正として扱っています

1 整理表
2 脆弱性の技術的な仕組み-ヘッダーを信頼しすぎたバッファ確保
3 Slowlorisとの違い-glibcのメモリ管理を悪用した永続的な断片化
4 実証実験で判明した深刻度
5 影響範囲の広さ-OpenSSLに依存するエコシステム全体
6 修正内容とCVE番号が付与されなかった経緯
7 情報システム部門への示唆
8 出典

整理表

項目	内容
脆弱性名	HollowByte
公表日	2026年7月16日(Okta Security Blog)
発見者	Okta Red Team
脆弱性の種別	サービス拒否(DoS)、未認証・認証前に悪用可能
悪用に必要なペイロードサイズ	わずか11バイト
単発の攻撃で確保されるメモリ量	最大131KB
攻撃の仕組み	TLSハンドシェイクの4バイトヘッダーが申告する長さを未検証のまま信用しmalloc()を実行
併発する副作用	glibcのメモリ再利用挙動によるヒープの断片化とRSSの継続的増加、攻撃終了後も回復しない
検証結果(1GB RAM環境)	547MBの断片化メモリを抱えOOM Killerにより強制終了
検証結果(16GB RAM環境)	接続数上限を超えないまま全体の25%のメモリを占有
影響を受けるソフトウェア	Apache、NGINX、Node.js、Python、Ruby、PHP、MySQL、PostgreSQL等、OpenSSLに依存する幅広い製品
修正方法	バッファの段階的拡張方式へ変更(PR #30792・#30793・#30794)
修正版	OpenSSL v4.0.1、および3.6.3・3.5.7・3.4.6・3.0.21へのバックポート
CVE番号	付与されず(堅牢化修正として扱い)

脆弱性の技術的な仕組み-ヘッダーを信頼しすぎたバッファ確保

TLSハンドシェイクは、レコードに包まれたClientHelloメッセージから始まります。各ハンドシェイクメッセージには、これから届くメッセージ本体のサイズを申告する4バイトのヘッダーが付いています。

古いバージョンのOpenSSLは、実際のデータが1バイトも届いていない段階で、このヘッダーが申告した長さに基づいて受信用バッファを確保してしまいます。悪意ある11バイトのペイロードが届くと、TLSのステートマシンはこのヘッダーを読み取り、ヘッダー内の3バイトの長さ申告に基づいて未検証のままメモリの事前割り当てを実行します。処理の流れを単純化すると、ヘッダーの読み取りからgrow_init_buf()、OPENSSL_clear_realloc()を経てmalloc(攻撃者が指定したサイズ)が呼び出されるという流れになります。

この段階ではペイロードの妥当性検証が一切行われないため、パケットの申告だけを根拠にmalloc()が最大131KBのメモリを確保してしまいます。そのままワーカースレッドは、決して届くことのないデータを待ち続けて無期限にブロックされた状態になります。

Slowlorisとの違い-glibcのメモリ管理を悪用した永続的な断片化

接続を保持し続けてスレッドを枯渇させるという手口自体は、Slowlorisと呼ばれる古典的な攻撃と同じ発想です。しかしHollowByteは、GNU Cライブラリ(glibc)がメモリを扱う際の挙動と組み合わさることで、より悪質な相乗効果を生みます。

攻撃側の接続が切断されると、OpenSSLは確保していたバッファを解放します。しかしglibcは、小〜中サイズのメモリ確保についてはOS側にすぐには返却せず、再利用に備えて保持し続けるという特性を持っています。攻撃者が申告するサイズをランダム化しながら大量の接続を波状的に送り込むことで、glibcのアロケータが解放済みのメモリチャンクを再利用する機会を奪うことができます。この結果、ヒープは激しく断片化し、サーバーの常駐メモリ使用量(RSS)は増加し続けます。

とりわけ深刻なのは、攻撃者が接続を切断した後もサーバーのメモリ使用量が膨張したまま戻らないという点です。このメモリを回収する唯一の方法は、プロセスそのものを強制終了することだとされています。

実証実験で判明した深刻度

Oktaのレッドチームは、修正前後のOpenSSLをNGINX上で稼働させ、さまざまな負荷条件下で検証を行いました。標準的な1GBのRAM環境では、修正前のサーバーは547MBの断片化したメモリを抱えた状態でOOM Killer(メモリ不足時にプロセスを強制終了するLinuxカーネルの仕組み)によって強制終了されました。より高スペックな16GBのRAM環境における検証では、通常の接続数上限を下回ったまま、システム全体のメモリの25%を占有することに成功しています。これは、接続数を制限する従来型の防御策だけではこの攻撃を防げないことを意味します。

影響範囲の広さ-OpenSSLに依存するエコシステム全体

OpenSSLは非常に広く利用され、様々なソフトウェアに組み込まれているライブラリであるため、今回の脆弱性の影響範囲もそれに比例して広範囲に及びます。具体的には、ApacheやNGINXといったWebサーバー、Node.js・Python・Ruby・PHPといった言語ランタイム、MySQLやPostgreSQLといったデータベースまで、TLS通信にOpenSSLを利用するソフトウェア全般が対象になり得ます。当サイトで既報のとおり、OpenSSLはこれまでにもAIによって発見された脆弱性を含む複数の修正を重ねてきており、インターネットインフラの根幹を支えるライブラリとして継続的な注視が必要な存在であることが改めて浮き彫りになっています。

修正内容とCVE番号が付与されなかった経緯

OpenSSL開発チームは今回の問題を、バッファを段階的に拡張する方式へと変更することで解決しました。修正はPR #30792・#30793・#30794としてマージされ、OpenSSL v4.0.1のリリースに正式に組み込まれたほか、3.6.3・3.5.7・3.4.6・3.0.21へもサイレントにバックポートされています。ヘッダーの申告を無条件に信頼するのではなく、実際にワイヤー上にバイトが届いた分だけバッファを拡張する方式に変更されたことで、実体を伴わない申告だけではサーバー側に一切のコストが発生しなくなりました。

注目すべき点として、OpenSSLは今回の問題を正式なCVEを伴うセキュリティアドバイザリとしてではなく、堅牢化のための修正(hardening fix)として扱っています。Okta側はこの分類にかかわらず、対象となるディストリビューションのOpenSSLパッケージを直ちにアップグレードすることを推奨しています。

情報システム部門への示唆

今回のHollowByteは、正式なCVE番号が付与されていないという点で、通常の脆弱性管理プロセスの中で見落とされやすいリスクだといえます。多くの組織では、CVEデータベースやNVDのフィードを基準にパッチ適用の優先順位を判断していますが、今回のようにベンダーが堅牢化修正として静かに取り込んだ変更は、そうした仕組みでは検知されない可能性があります。OpenSSLのような基盤ライブラリについては、CVE番号の有無にかかわらず、上流のリリースノートやセキュリティアドバイザリを定期的に確認する運用を組み込むことをお勧めします。

また、外部公開しているTLSエンドポイントについては、接続数の制限だけに頼った対策では今回のような攻撃を防げない点にも注意が必要です。未認証・認証前の段階で悪用可能な脆弱性であることを踏まえ、インターネットに面したサーバーを中心に、OpenSSLを含む依存ライブラリのバージョンを速やかに確認し、該当する修正版(v4.0.1、または3.6.3・3.5.7・3.4.6・3.0.21以降)への更新を優先的に実施することが重要です。あわせて、メモリ使用量やRSSの異常な増加傾向を監視する仕組みを整えておくことも、この種の緩やかな枯渇型攻撃を早期に検知するうえで有効な備えになります。