Zephyr HTTP/2サーバーにメモリ破壊の脆弱性、修正版あり
ZephyrのHTTPサーバーでHTTP/2の静的ファイル配信を使う機器は、認証なしの要求でメモリを破壊され、停止やコード実行に至るおそれがあります。自社のZephyrの版を確認し、4.3.2または4.5.0の修正版へ更新してください。
急ぎ度: 早めに
CVSS v3は9.1で、ネットワーク経由かつ認証なしで届く脆弱性ですが、修正版が出ているため、該当する機器は早めに更新するのが妥当です。
関係があるか
Zephyrを組み込んだ機器やゲートウェイを開発している組織と、そのファームウェアを使う利用者が対象です。HTTPサーバーで静的ファイルを配信する機器が影響を受けます。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Zephyr(HTTPサーバーのHTTP/2処理) | 4.0.0以上4.3.2未満、および4.4.0以上4.5.0未満 | 4.3.2、4.5.0 |
確かめ方
- 1開発元の場合は、ビルドに使っているZephyrのソースで
cat zephyr/VERSIONを実行し、版が上の範囲に入るかを確認します。4.0.0より前は影響範囲に含まれていません。4.4系は4.5.0にそろえる必要があります。 - 2ビルド設定で、HTTP/2とファイルシステムが有効かを確認します。例:
grep -E "CONFIG_HTTP_SERVER_VERSION_2|CONFIG_FILE_SYSTEM" build/zephyr/.config - 3アプリのソースで
HTTP_RESOURCE_TYPE_STATIC_FSを探し、静的ファイルの配信を登録しているかを確認します。 - 4機器を購入して使っている場合は、メーカーに、ファームウェアがZephyrのHTTPサーバーを使っているか、修正版を取り込んだ版があるかを問い合わせます。
何が起きたか
ZephyrのHTTPサーバーのHTTP/2処理に、メモリの範囲外への書き込みが起きる脆弱性が見つかりました。静的ファイルを返しただけで、接続ごとの受信バッファを管理する値が壊れます。機器が停止するほか、制御情報の上書きによってコードを実行されるおそれもあります。
原因は subsys/net/lib/http/http_server_http2.c の handle_http2_static_fs_resource() です。この関数が、受信バッファに残る未処理バイト数 client->data_len を、ファイルサイズの出力先として http_server_find_file() に渡していました。バッファは既定で256バイトの固定長ですが、data_len がファイルのディスク上のサイズに置き換わり、その後も元に戻りません。受信処理はこの値を信用してバッファの外を読み、memmove で大きなサイズをバッファにコピーし、zsock_recv の長さ指定もアンダーフローして範囲外に書き込みます。CWEはCWE-787です。
修正は http_server_http2.c の4行です。ファイルサイズをローカル変数の size_t file_size で受けるようにしました。HTTP/1とHTTP/3の静的ファイルのハンドラは、もともとローカル変数を使っており、影響を受けません。問題は2024年7月31日の静的ファイル資源の追加（コミットe55278a）で入りました。Zephyrプロジェクトは2026年10月26日付でGitHubに勧告を出し、CVE-2026-82391は11月10日に公表されました。
攻撃の流れ
-
1
ファイル要求
認証なしでHTTP/2のGETを送り、公開領域のファイルを要求する。
-
2
長さ値の上書き
受信バッファの残りバイト数が、ファイルのサイズに置き換わる。
-
3
範囲外の処理
受信処理が本来の範囲を超え、バッファや隣接する領域に書き込む。
-
4
停止・乗っ取り
機器が停止または応答不能になり、制御情報の上書きでコード実行に至る可能性もある。
どう悪用されるか
攻撃者は、機器にネットワークから届けば足ります。認証もTLSも要らず、利用者の操作も要りません。公開されているファイルをHTTP/2のGETで要求するだけで、問題の経路に入ります。
前提になるのは機器側の構成です。アプリが静的ファイルの資源（HTTP_RESOURCE_TYPE_STATIC_FS）を登録し、CONFIG_FILE_SYSTEM=y で動いていることが必要です。CONFIG_HTTP_SERVER_VERSION_2 は既定で有効です。壊れた長さの値が受信バッファの大きさを超えると、サーバーは要求のあとに続く攻撃者のバイト列を、次に処理するフレームとして読み進めます。配信するファイルが既定の256バイトより大きいと、この状態になります。
被害として、メモリの破壊による機器の停止や応答不能は、最低限起こり得ます。バッファの先にある接続情報の構造体には、関数ポインタの表やタイマーの処理先が含まれ、隣の接続の領域も同じ静的メモリにあります。これらが上書きされれば、コード実行に至る可能性もあります。CVSSのベクターでは、機密性への影響はなく、完全性と可用性への影響が高いと評価されています。
今すぐやること
-
1
自社の系列の修正版に更新する
4.3系は4.3.2、4.4系は4.5.0へ更新します。更新後はファームウェアをビルドし直し、出荷済みや稼働中の機器に配布します。
-
2
独自ブランチには差分を取り込む
社内で改変したZephyrを使っていて、すぐに版を上げられない場合は、
http_server_http2.cの修正コミット（4e0a5f3）の差分を取り込みます。ファイルサイズをローカルのsize_t file_sizeで受けるだけの変更です。取り込んだら、HTTP/2で大きめの静的ファイルを配信する試験をしてください。 -
3
購入した機器はメーカーに問い合わせる
ファームウェアがZephyrのHTTPサーバーとHTTP/2を使っているか、修正版を取り込んだ更新が出る時期はいつかを、メーカーに確認します。回答があるまで、機器の管理画面をインターネットに出さない運用に切り替えてください。
すぐ更新できないとき
公式の勧告には回避策が書かれていません。更新までのつなぎとして、次の方法で攻撃が届く経路を狭められます。
- ビルド設定で
CONFIG_HTTP_SERVER_VERSION_2を無効にするか、静的ファイルの資源を登録しない構成にします。HTTP/1のハンドラは影響を受けないと説明されていますが、接続するクライアントの動作は事前に試してください。 - 機器のHTTPポートへは、信頼できる管理用ネットワークからしか届かないようにします。
- 機器が原因不明の再起動や応答停止を繰り返していないかを、監視で確認します。
背景
Zephyrは、IoT機器や産業機器、ゲートウェイなどの組込み機器で使われるリアルタイムOSです。HTTPサーバーのライブラリを使うと、機器が設定画面やステータス画面を自分で配信できます。OSとアプリが同じアドレス空間で動くため、サーバー部分でメモリが壊れると、機器全体の動作に影響します。
この脆弱性が入った静的ファイル資源の機能は、2024年7月に追加されました。Zephyrの脆弱性一覧には、同じ静的ファイルのハンドラで過去に記録されたCVE-2026-8023があり、この経路は外部から認証なしで届く構成だと整理されています。Zephyrはソースの形で製品に組み込まれるため、修正はメーカーがビルドし直して配布する流れになります。ユーザー側からは、自分の機器が修正済みかどうかが分かりにくい点に注意が要ります。
よくある質問
Q.Zephyrを自分では使っていませんが、確認は必要ですか。
まだ分かっていないこと
- 実際の攻撃での悪用が確認されたかどうかは、公表されていません。
- コード実行が実機で成立するかは、勧告では「可能性がある」とされるにとどまります。
- 4.3.2と4.5.0以外の系列に、修正がバックポートされるかどうかは示されていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| zephyrprojectzephyr |
4.0.0 以上 4.3.2 未満→ 4.3.2 4.4.0 以上 4.5.0 未満→ 4.5.0 |
4.3.2 4.5.0 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
The HTTP/2 front-end of the Zephyr HTTP server aliased connection receive state as a scratch output. In subsys/net/lib/http/http_server_http2.c, handle_http2_static_fs_resource() passed &client->data_len as the file_size out-parameter of http_server_find_file(). client->data_len is the count of unprocessed bytes remaining in the fixed-size per-connection receive buffer client->buffer[CONFIG_HTTP_SERVER_CLIENT_BUFFER_SIZE] (256 bytes by default), an invariant every frame handler and the socket receive path rely on. Serving any static file therefore replaced that bounded value with the file's on-disk size, and nothing resets it afterwards.
The defect is reached by an unauthenticated HTTP/2 GET for any file under the web root, in applications that register a static-filesystem resource (HTTP_RESOURCE_TYPE_STATIC_FS) with CONFIG_FILE_SYSTEM=y; CONFIG_HTTP_SERVER_VERSION_2 is enabled by default and no TLS or credentials are required on this path. Once client->data_len exceeds the buffer size, the frame dispatch loop in subsys/net/lib/http/http_server_core.c keeps parsing past the end of the received data, and the peer controls the bytes at client->cursor, so it can choose which fabricated frame the state machine consumes next by appending bytes after its request.
The inflated length defeats the only guards on the buffer. parse_http_frame_header() and the per-frame handlers read and skip up to a 24-bit frame length beyond the buffer (out-of-bounds read); the compaction memmove(cli…
出典: CVE.org (CVE Program・cvelistV5) NVD