ESP-IDFにDHCP脆弱性 ESP32搭載機器が影響

Espressif の ESP-IDF に、DHCP サーバのオプション解析処理を突く脆弱性 CVE-2026-45160 が公表されました。細工した DHCP 要求を送られると解析処理が受信バッファの外まで読み進み、接続してきた端末に IP アドレスを配れなくなるおそれがあります。CVSS v3.1 は 6.5（中）、影響は情報漏えいではなく可用性です。攻撃条件は、その機器の無線ネットワークに届く位置（隣接ネットワーク）にいることです。

ただし情シスにとっての本題は深刻度そのものではありません。「自社に ESP-IDF で作られた機器があるかどうか、そもそも把握できていない」という点です。この記事は、その洗い出し方に重心を置いて整理します。

この記事でわかること

  • ESP-IDF とは何で、なぜ「うちは使っていない」が通じないのか
  • CVE-2026-45160 の影響範囲と修正バージョン
  • 「境界外読み取り」なのに機密性への影響が「なし」と評価された理由
  • 社内に ESP32 搭載機器があるかを調べる具体的な手順
  • 情シスが現実的に打てる手と、打てない手

ESP-IDF とは何者か──「うちは使っていない」が通じない理由

ESP-IDF（Espressif IoT Development Framework）とは、Espressif 社の Wi-Fi/Bluetooth 内蔵チップ「ESP32 シリーズ」向けの公式開発フレームワークです。OS・ネットワークスタック・ドライバ・ビルドツールを一式で提供する SDK で、C/C++ でファームウェアを書くための土台にあたります。

誰が使うものか。使うのは情シスではなく、機器を作るメーカー側の開発者です。ESP32 は Wi-Fi と Bluetooth を1チップに載せて安価に調達できるため、ネットワークにつながる小型機器を作るときの定番になっています。つまり ESP-IDF は「買って導入するソフト」ではなく、買った機器のファームウェアの中に最初から入っているものです。

どこに組み込まれているか。ここが最も重要です。Espressif 自身が ESP-IDF について「単純な電球やおもちゃから、大型家電や産業機器まで」ネットワーク接続製品を作るために使われ、すでに現場で数百万台規模のデバイスを動かしていると説明しています。同社の累計チップ出荷は 10 億個を超えたとも公表されています。資産管理台帳に「ESP-IDF」と書かれることは絶対にありませんが、台帳に載っていない小型機器の中で動いている可能性は十分にあります。

一方で、「御社のあの製品に入っています」と名指しできるだけの一次情報は、個々の製品については公開されていないのが実情です。推測でメーカー名を並べても意味がないので、この記事では代わりに「自社の機器がそれに当たるかを自分で判定する手順」を後半に示します。

何が起きたのか

脆弱性があるのは、ESP-IDF に同梱される lwIP コンポーネント内の DHCP サーバ、具体的には components/lwip/apps/dhcpserver/dhcpserver.c の parse_options() です。この関数は BOOTP/DHCP パケットのオプション領域を先頭から順に読み進めますが、各オプションの長さバイトと宣言されたペイロード長が、受信したパケットバッファの中に収まっているかを検証していませんでした。

その結果、細工された DHCP 要求を1つ送るだけで、パーサがオプション領域の末尾を越えて隣接するヒープメモリを読み込みます。読み込んだ内容が攻撃者に返るわけではありませんが、パーサの内部状態が壊れ、その機器が SoftAP として抱えているクライアント全員へのアドレス割り当てが止まる可能性がある、と Espressif の Advisory は説明しています。

項目 内容
CVE CVE-2026-45160
CWE CWE-125（境界外読み取り）
CVSS v3.1 6.5（中） / AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
影響を受けるバージョン 5.2.7 / 5.3.5 / 5.4.4 / 5.5.4 / 6.0.1
修正済みバージョン 5.2.8 / 5.3.6 / 5.4.5 / 5.5.5 / 6.0.2
影響を受ける機能 SoftAP など、機器が DHCP サーバとして動作する構成
公表 Espressif Advisory 2026年5月21日 / NVD 登録 2026年6月上旬 / JVNDB 登録 2026年6月12日

なお、上に挙げた「影響を受けるバージョン」は各系列の当時の最新版を指しており、それより古いバージョンが安全という意味ではありません。系列ごとに修正版のリリース時期が異なるため、実際にどの版が出ているかは公式のリリース一覧で確認してください。

境界外読み取りなのに、なぜ「情報漏えいなし」なのか

CVSS ベクトルは C:N/I:N/A:H、つまり機密性と完全性への影響は「なし」、可用性だけが「高」と評価されています。「境界外読み取り＝情報漏えい」と反射的に読むと、この評価は違和感があるはずです。

理由は、読み取ったメモリの中身が攻撃者に返る経路がないためです。壊れるのはパーサの内部状態であり、そこから先は DHCP のアドレス割り当てが機能しなくなる、という結果に落ちます。この脆弱性は情報漏えいではなく、実質的に無線経由の DoS（サービス妨害）として扱うのが妥当です。優先度を判断するときは、CWE の名前ではなく CVSS ベクトルの実測値を見てください。

いつ発火するのか──SoftAP は「初期設定の入口」

攻撃元は AV:A、すなわち同一の L2 ネットワークです。ESP32 搭載機器が SoftAP（機器自身が一時的に Wi-Fi アクセスポイントになるモード）を立てている間、その AP に接続できる範囲にいる攻撃者が DHCP 要求を投げれば成立します。

この SoftAP がいつ立つかというと、典型的には機器の初期設定時です。Espressif の Unified Provisioning の仕組みでは、設定前の機器が一時的に SoftAP と HTTP サーバを起動し、利用者がスマートフォンでその SSID に接続して Wi-Fi の認証情報を入力する、という流れになっています。この「設定モードの数分間」に、機器は DHCP サーバとして振る舞います。

実務上やっかいなのは次の2点です。

  • 設定モードのままになっている機器がある。設置したものの Wi-Fi 設定を完了していない機器、あるいは設定が外れて設定モードに戻った機器は、SoftAP を出しっぱなしにします。この状態の SSID は暗号化なし、あるいは既知の初期パスワードのことが多く、誰でも接続できます。
  • 常時 SoftAP で運用している機器がある。スタンドアロンで使う計測機器や現場端末など、社内 LAN につながずに機器自身の AP に直接つなぐ運用をしている場合、常に条件が揃っています。

逆に、Wi-Fi 設定が完了して STA モード（既存 AP に接続するだけ）で動いている機器は、DHCP サーバを動かしていないため、この脆弱性の影響を受けません。「ESP32 が入っている＝即危険」ではないという点は、社内説明の際に押さえておくと過剰反応を避けられます。

自社に該当機器があるか、どう調べるか

製品名からは辿れないので、ネットワーク側から探します。台帳に頼らずに済むのがポイントです。

  1. MAC アドレスのベンダーから洗い出す。Espressif は IEEE に多数の OUI（MAC アドレス先頭3バイト）を登録しています。DHCP サーバのリース一覧、無線 LAN コントローラの接続端末リスト、NAC やスイッチの MAC アドレステーブルを吐き出し、ベンダー名が Espressif になっている端末を抽出してください。多くの管理コンソールはベンダー名を自動解決して表示します。これが最も確実で、しかも今日できる作業です。
  2. 周囲の SSID をスキャンして「設定モードのまま」を見つける。オフィスやフロアで Wi-Fi スキャンを行い、見覚えのない小型機器の AP が出ていないかを確認します。設定用の SoftAP は ESP_ で始まる名前や、製品名＋末尾数桁という形をとることが多く、無線 LAN コントローラの不正 AP 検知（Rogue AP）ログにも残っているはずです。この「設定モードのまま放置」を潰すこと自体が、本 CVE とは無関係に価値のある対処です。
  3. 該当した機器のベンダーに問い合わせる。ESP32 搭載と分かったら、そのメーカーのサポートページでファームウェア更新履歴とセキュリティ情報を確認し、CVE-2026-45160 への対応予定を確認します。ここが最大の関門で、後述のとおり待つしかない場面が出ます。

現場目線の課題──直したくても自分では直せない

この手の脆弱性で毎回いちばん重くのしかかるのは、情シスの側に修正の手段がないことです。ESP-IDF はフレームワークなので、脆弱なコードは製品ファームウェアの中にコンパイル済みで焼き込まれています。ESP-IDF を自分でアップデートすることはできません。機器メーカーが新しい ESP-IDF でビルドし直したファームウェアを配布し、それを自社で適用して、初めて直ります。

ところが実際には、メーカーが ESP-IDF のどのバージョンを使っているかを公表していないことが大半で、問い合わせても回答に時間がかかります。安価な機器ではファームウェア更新自体が提供されず、事実上直らないまま使い続けるという判断を迫られることもあります。

加えて、こうした機器は誰が買ったのかすら分からないことがあります。会議室の予約表示パネル、環境センサー、デジタルサイネージ、スマートプラグ。部署が備品として個別に発注したものは情シスの購買を通っておらず、台帳にも載りません。脆弱性情報が出るたびに「うちに何台あるのか」から始めなければならない状況は、限られた人員でやっている現場としては正直かなりつらいところです。業務用清掃ロボットの脆弱性やEV充電器の脆弱性を扱ったときにも同じ壁にぶつかりました。構造的な問題なので、都度の場当たり対応では追いつきません。

もっとも、今回に限れば救いはあります。影響は可用性だけで、しかも攻撃者は電波の届く範囲まで近づく必要があります。侵入や情報窃取に直結する類ではないので、緊急のパッチ適用祭りにする性質のものではありません。AirDrop・Quick Share の近距離脆弱性と同様、物理的な近接という条件が実効リスクをかなり絞っています。

情シスはどうすべきか

本 CVE 単体への対応は「該当機器を洗い出し、SoftAP を出しっぱなしにしない、ベンダーの更新を待つ」に尽きます。それより、この機会に IoT 機器全般の管理の型を整えるほうが投資対効果は高くなります。以下の公的資料が土台として使えます。

自前で長大なチェックリストを作るより、まず上記に沿って「ネットワークにつながっている機器の一覧を、ネットワーク側から機械的に作れる状態」を目指すほうが実務的です。前述の MAC ベンダーによる抽出は、その第一歩としてそのまま流用できます。

中長期の視点──公式一覧に載らない脆弱性がある

付け加えておきたい点があります。本記事執筆時点（2026年8月16日）で確認した範囲では、Espressif 公式ドキュメントの脆弱性一覧ページに、本 CVE の記載は見当たりませんでした。情報が存在するのは GitHub Security Advisory、NVD、そして JVNDB です。

ここから読み取るべきなのは、「ベンダーの公式脆弱性ページだけを巡回していると、拾えない案件がある」という運用上の現実です。情報源は複数持ち、GitHub Advisory Database や JVN/JVNDB のような横断的なデータベースも合わせて見る必要があります。とくに OSS やフレームワークが関わる領域では、公式サイトよりリポジトリの Advisory のほうが早く、かつ詳しいことが珍しくありません。

また、ESP32 のように「部品として無数の製品に入り込むコンポーネント」の脆弱性は、今後も同じ形で繰り返し出てきます。境界機器が攻撃の中継拠点にされる ORB 化のように、管理の目が届かない機器がそのまま攻撃基盤になる流れを考えると、SBOM（ソフトウェア部品表）をベンダーに求めていく動きは、面倒でも避けて通れない方向だと考えています。

まとめ

  1. CVE-2026-45160 は ESP-IDF の DHCP サーバの境界外読み取り（CVSS 6.5）で、影響は情報漏えいではなく可用性。攻撃には機器の無線ネットワークに届く位置にいることが必要で、緊急対応を要する種類ではありません。
  2. 影響するのは SoftAP など機器が DHCP サーバとして動く構成のみ。初期設定モードのまま放置された機器が最も危険なので、まずそこを潰してください。
  3. ESP-IDF は自分ではアップデートできない。できるのは、MAC アドレスのベンダー情報から ESP32 搭載機器を洗い出し、台帳に載せ、メーカーのファームウェア更新を追いかけることです。棚卸しの仕組みづくりが本丸です。

出典

タイトルとURLをコピーしました