【lwIP】News #11｜MQTTの脆弱性、自社製品は対象か｜CVE-2026-87121（CVSS 9.8）と6LoWPANのCVE-2026-91018

2026年9月25日 23:42

2026年9月22日（米国時間）、米CISAがlwIPのMQTT脆弱性（CVSS v3.1 で9.8）と、6LoWPANの二重解放を公表しました。対象はlwIP 2.0.1〜2.2.1とされていますが、自社製品が本当に対象かは、使っている機能と同梱されているコードで決まります。さらに、修正を含むlwIPの正式リリースはまだ出ていません。

このnoteでは、lwIPで実際に起こり得る不具合・脆弱性・再現方法・最小修正の考え方やデバッグのノウハウをシリーズで解説しています。
▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧

本記事は「News」として、公表内容を整理したうえで、lwIPのソースコードとベンダーSDKを照合して分かったことをまとめます。確認は2026年9月25日時点のものです。

■ 今回のニュース概要

MQTTクライアントの境界外書き込み（CVE-2026-87121）

CISAのアドバイザリ：ICSA-26-265-01
種類：Out-of-bounds Write（CWE-787）
深刻度：CVSS v3.1 で 9.8（Critical）、`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`。CVSS v4.0 の基本評価（CVSS-B）で 9.3（Critical）
対象：CISAの記載では "lwIP MQTT Client Application" の 2.0.1〜2.2.1
影響：CVEレコードの説明は "may allow an attacker to gain full code execution on the device"（機器上でコードを実行される可能性がある）

6LoWPANの二重解放（CVE-2026-91018）

CISAのアドバイザリ：ICSA-26-265-02
種類：Double Free（CWE-415）
深刻度：CVSS v3.1 で 8.8（High）、`CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`。CVSS v4.0 の基本評価（CVSS-B）で 8.7（High）
対象：CISAの記載では "lwIP API" の 2.0.1〜2.2.1
影響：クラッシュ、DoS、メモリ破壊、コード実行の可能性。CISAは "This vulnerability is not exploitable remotely." としています

2件とも、CISAは「この脆弱性を狙った既知の悪用は報告されていない」としています。CISAが管理する「悪用が確認された脆弱性の一覧」（KEV）の2026年9月24日版にも、lwIP関連の項目はありません。

■ 自社製品が対象かを切り分けるチェック

MQTTクライアント（CVE-2026-87121）

□ lwIP 2.0.1〜2.2.1、またはそれをベースにしたベンダーSDKを使っている
□ lwIPに同梱されているMQTTクライアント（`src/apps/mqtt/mqtt.c`。`mqtt_client_connect()` を呼んでいる）を使っている
□ 製品がMQTTブローカーへ接続する
□ 同梱の `mqtt.c` に、後述の修正コミットが取り込まれていない

6LoWPAN（CVE-2026-91018）

□ lwIP 2.1.0〜2.2.1、またはそれをベースにしたベンダーSDKを使っている（CISAの記載は2.0.1からです。後述）
□ IPv6（`LWIP_IPV6`）を有効にしている
□ IEEE 802.15.4 の6LoWPANインターフェース（受信に `lowpan6_input()` または `tcpip_6lowpan_input()` を使う）か、6LoWPANをUDPでトンネルする `zepif` を使っている
□ 同梱の `lowpan6.c` に、後述の修正コミットが取り込まれていない

それぞれ4項目すべてに当てはまる場合は、影響を受ける可能性があります。ベンダーSDKは独自に修正を取り込んでいることがあるので、最後の項目は同梱のソースで確認してください。

Ethernet や Wi-Fi だけで通信し、`zepif` も使っていない製品では、6LoWPANのソースがビルドに含まれていても、この受信処理には到達しません。

■ CISAの記載だけでは判断を誤る3点

1. 「lwIP全体」に見えるが、関係するのは2つの機能だけ

CVE-2026-91018 のCVEレコードは、製品名を "lwIP API"、説明を "lwIP (Lightweight IP) has a double free vulnerability" と書いています。CVEレコード、CISAのアドバイザリ（機械可読版のCSAF）、NVDのどれにも、6LoWPANという語は出てきません。これらの記載だけでは、対象が6LoWPANの受信処理だとは判断できません。示された修正コミットを開くと、変更されているのが `src/netif/lowpan6.c` だと分かります。

製品名とバージョンだけで照合し、機能ごとの到達性を考慮しないツールでは、6LoWPANを使わない製品も候補として検出される可能性があります(推定)。品質保証やセキュリティの担当者へ「対象外」と説明するには、上のチェックのように機能単位の根拠が必要です。

2. CISAが示す修正コミットは、テストコードの1行だけを変えている

CVE-2026-87121 のCVEレコードとCISAのアドバイザリは、修正コミットとして f89407e だけを挙げています。原文は "The commit identifier that contains the fix is f89407ea711879c04d91c92b35d67be78bbaf0f1." です。

upstream lwIP（開発元オリジナル）のリポジトリで確認すると、このコミット（件名 `mqtt: fix wrong memset in last test commit`）の変更は、ユニットテスト `test/unit/mqtt/test_mqtt.c` の1行だけです。MQTTクライアント本体の変更は、その1つ前のコミットに入っています。コミット 68b2c11（件名 `mqtt: fix rx_buffer overrun`）で、`src/apps/mqtt/mqtt.c` を変更しています。

影響は、修正の取り込み方で分かれます。

開発版をそのリビジョンまで丸ごと更新する場合：f89407e が指すソースツリーには直前の 68b2c11 も含まれるので、本体も修正されます
古いlwIPへ修正だけを取り込む場合（いわゆるバックポート）：f89407e の差分だけを当てても、MQTTクライアント本体は変わりません。取り込むべきなのは 68b2c11 です

なお、Debianのセキュリティトラッカーは、この2つのコミットを両方とも修正として記載しています。

3. 修正は開発版にだけ入っていて、正式リリースはまだない

2件の修正コミットは、どちらも2026年8月31日にupstream lwIPの開発ブランチ（master）へ入りました。しかし、最新の正式リリースは2025年2月6日の lwIP 2.2.1 のままです。「最新版へ更新すれば直る」という状態ではありません。上流のバグ報告（後述の Bug #68590）の Planned Release 欄は `2.2.2` ですが、2.2.2 はまだ公開されていません。

■ lwIPのMQTT脆弱性（CVE-2026-87121）：何が起きて、誰が攻撃できるか

何が起きるか

MQTTのパケットは、先頭の固定ヘッダに「残りのデータの長さ」（Remaining Length）を持っています。この長さは可変長で、各バイトの最上位ビットが立っていれば「次のバイトも長さの続き」を意味します。MQTT 3.1.1 仕様の 2.2.3 節は、この長さのフィールドを最大4バイトと定めています。

lwIPのMQTTクライアントは、受信処理 `mqtt_parse_incoming()` の中で、固定ヘッダのバイトを受信バッファ `rx_buffer` へ1バイトずつ保存します（lwIP 2.2.1 より抜粋）。

        b = pbuf_get_at(p, in_offset++);
        client->rx_buffer[client->msg_idx++] = b;

最上位ビットが立ったバイトが届き続けるかぎり、書き込み位置 `msg_idx` は増えていきます。`rx_buffer` の大きさは `MQTT_VAR_HEADER_BUFFER_LEN`（既定値128バイト）ですが、書き込み位置がこの大きさを超えたかどうかを確認していません。その結果、`rx_buffer` の外側へ書き込みます。

正常なブローカーは4バイトを超える長さのフィールドを送らないので、通常の運用では起きません。問題になるのは、相手が不正なデータを送ってくる場合です。はみ出した書き込みが何を壊し、最終的に何が起きるかは、本記事ではソースから断定していません。上流の報告は "heap corruption, potentially RCE on MCU targets"、CISAは "may allow an attacker to gain full code execution on the device" と、どちらも可能性として書いています。

攻撃できるのは、接続先のブローカーか、通信経路上の第三者

MQTTクライアントは、機器の側からブローカーへ接続します。待ち受けポートを開けるわけではありません。そのため、不正なデータを送れるのは次のどちらかです。

接続先のブローカー自身（悪意のあるブローカー、または乗っ取られたブローカー）
通信経路上でブローカーになりすませる第三者（暗号化していないMQTT、またはTLSでもサーバー証明書を検証していない構成）

lwIP 2.2.1 の受信コールバック `mqtt_tcp_recv_cb()` は、接続状態を確認せずに、受信したデータを `mqtt_parse_incoming()` へ渡します。つまり、TCP接続の直後、ブローカーから接続応答（CONNACK）が返る前に届いたデータでも、この処理に入ります。MQTTのユーザー名とパスワードによる認証は、この問題を防ぎません。

対象バージョン（ソース照合）

手元にあるlwIPの各正式リリースで、上記の書き込み処理を1版ずつ確認しました。

該当コードあり：2.0.1 / 2.0.2 / 2.0.3 / 2.1.0 / 2.1.1 / 2.1.2 / 2.1.3 / 2.2.0 / 2.2.1
2.0.0：MQTTクライアント自体が含まれていない（2.0.1で追加）

CISAの対象範囲とソースの照合結果は一致しています。確認はソースの照合のみで、実機での再現は行っていません。

CVEの約7週間前から、公開のバグトラッカーに載っていた

修正コミット 68b2c11 のメッセージには、"This has been reported multiple times, e.g. bug #68590, #68315 and #68581" とあります。このうち Bug #68590 は公開されていて、2026年8月3日に、単体テスト形式の再現ハーネスつきで登録されていました（Bug #68315 と Bug #68581 は非公開）。脆弱性の情報が出る順番は News #5 で整理しましたが、今回もCVEより、upstream lwIPのバグトラッカーのほうが先でした。同じ関数には2021年から Open のままの報告（Bug #61479、Bug #61480）もありますが、今回の修正との関係は未確認です。

■ 6LoWPAN（CVE-2026-91018）：対象は6LoWPANを使う構成だけ

何が起きるか

6LoWPANは、IEEE 802.15.4 のような小さなフレームしか送れない無線でIPv6を使うための仕組みです。IPv6ヘッダを圧縮し、大きなパケットは分割（フラグメント）して送ります。

問題は、分割された最初の断片（FRAG1）を受け取る `lowpan6_input()`（`src/netif/lowpan6.c`）にあります。圧縮されたヘッダを戻す `lowpan6_decompress()` は、失敗すると受け取ったパケットバッファを自分で解放してから `NULL` を返します。ところがFRAG1の処理では、`NULL` を受け取ると破棄用の処理へ進み、そこで同じパケットバッファをもう一度解放します。同じバッファを2回解放するので、二重解放になります。解凍の失敗は、ヘッダが途中で切れた短いフレーム1つで起こせます。

到達するのは6LoWPANの受信処理を登録した構成だけ

lwIPの6LoWPAN処理は `LWIP_IPV6` が有効なときだけビルドされます（`opt.h` の既定値は `0`）
IEEE 802.15.4 の6LoWPANインターフェースを登録し、受信処理に `lowpan6_input()`（または `tcpip_6lowpan_input()`）を使っている場合に到達します
Bluetooth Low Energy 用の6LoWPAN（`src/netif/lowpan6_ble.c` の `rfc7668_input()`）には FRAG1 を扱う処理がなく、この経路を通りません
lwIPに同梱されている `zepif`（`src/netif/zepif.c`）は、6LoWPANをUDP（既定ポート17754）でトンネルするインターフェースです。受信したUDPデータのZEPヘッダの形式（識別子・バージョン・種別・CRCモード・長さ）を確認したうえで、登録された6LoWPANの受信処理へ渡します。送信元の照合はしていません。そのため、`zepif` を使う構成では、UDPポートに届く相手から、IPネットワーク越しにこの処理へ到達する余地があります(推定)。CISAの「リモートからは悪用できない」という評価がこの構成を含むかどうかは、公開資料からは分かりません

対象バージョン：CISAは2.0.1から、ソース上は2.1.0から

該当コードあり：2.1.0 / 2.1.1 / 2.1.2 / 2.1.3 / 2.2.0 / 2.2.1
該当コードなし：2.0.0 / 2.0.1 / 2.0.2 / 2.0.3

2.0.x系の `lowpan6.c` には、FRAG1を受け取った時点で解凍する処理そのものがありません。この処理は、2018年3月のコミット 8d85723（Bug #47291 の修正）で追加され、2.1.0から含まれています。CISAが2.0.1を対象に含めた根拠は、公開資料からは確認できませんでした。2.0.x系を使っている場合も、脆弱性管理の上では「CISAの記載では対象」として扱われる点には注意してください。

なお、本シリーズの Bug #1 も二重解放を扱いましたが、あちらはソケットAPIの `lwip_accept()` の問題で、今回とはファイルも関数も異なる別件です。

■ ベンダーSDKの同梱状況（確認できた範囲）

MQTTクライアント（CVE-2026-87121）

NXP MCUXpresso SDK（手元のRT1170用 SDK 26.03.00）：同梱の `mqtt.c` に該当コードがあります。サンプル `lwip_mqtt` と `lwip_mqtt_enet_qos` がこのMQTTクライアントを使っています。`lwip_mqtt` の既定値は、暗号化なしのポート1883で公開のテスト用ブローカーへ接続する設定です
TI MCU+ SDK（手元のAM243x用 10.00.00.20）：同梱の `mqtt.c` に該当コードがあります。サンプル `cpsw_lwip_mqtt` がこのMQTTクライアントを使っています
STM32Cube（手元のF7用 V1.17.0）：同梱の `mqtt.c` に該当コードがあります。MQTTを使うサンプルは、手元では確認できませんでした
ESP-IDF：ビルド設定（`components/lwip/CMakeLists.txt`）では、lwIPのMQTTクライアントはビルド対象に入っていません。ESP-IDF標準のMQTTは別のコンポーネントなので、標準構成は本件の対象外と判断しています。確認したのは master（048ec57）、release/v5.4（25f10df）、release/v5.5（2553c5a）、release/v6.0（7172267）です

GitHubで公開されている各社のlwIPリポジトリも、2026年9月25日時点の最新コミットでは修正前のコードのままでした。

NXP：nxp-mcuxpresso/lwip の mcux_main ブランチ（63acfbc）
ST：stm32-mw-lwip の master ブランチ（07680c8）
Espressif：esp-lwip の 2.2.0-esp ブランチ（fd07630）

6LoWPAN（CVE-2026-91018）

NXP・TI・ST・Renesas・AMD（Xilinx）の手元のSDKでは、どれも同梱の `lowpan6.c` に該当コードが残っていました。ただし、手元のサンプルで6LoWPANのインターフェースを登録しているもの（`lowpan6_if_init()` などを呼ぶもの）は見つかりませんでした。

いずれも手元にある版での確認です。お使いのSDKの版では、同梱のソースを直接確認してください。

■ 当面の対応の選択肢

対象外であることを確認し、根拠を残す：チェックで対象外と判断できた場合も、「MQTTクライアントを使っていない」「6LoWPANを使っていない」という根拠を残しておくと、SBOMの照合結果の説明や、顧客からの問い合わせへの回答に使えます
upstream lwIPの修正コミットを取り込む：MQTTは 68b2c11、6LoWPANは f873b62 です。ベンダーSDKのlwIPは独自の変更が入っていることがあるため、取り込んだ後はそのSDKの環境で動作を確認してください
MQTTの接続先と経路を見直す：TLSを使い、信頼できる認証局の証明書とホスト名でブローカーを検証し、検証に失敗したら接続しない構成にすれば、経路上の第三者によるなりすましへの対策になります。ただし、接続先のブローカー自身が悪意を持つ場合や乗っ取られた場合は防げないため、根本対応にはなりません
ベンダーSDKの更新を待つ：各社が修正を取り込む時期は読めません

MQTTの件は、実機での再現と影響の範囲を、後続のBug記事で扱うことを検討しています。

■ 公式対応状況・要確認事項

NVD： 2件とも "Awaiting Analysis"（分析待ち）で、NVD独自の評価はまだ付いていません（CVE-2026-87121、CVE-2026-91018）。上記のCVSSの値は、CVEを採番したCISA（ICS-CERT）によるものです
Debian： 2件とも、bookworm・trixie・forky・sid のすべてで vulnerable（未修正）とされています（CVE-2026-87121、CVE-2026-91018）
6LoWPANの別の報告： 2026年9月19日、lwIPの開発者向けメーリングリストに、6LoWPANのヘッダ解凍処理 `lowpan6_decompress_hdr()` の境界外読み取りの報告が投稿されています（lwip-devel 2026年9月）。CVE-2026-91018 とは別の箇所で、2026年9月25日時点で修正コミットはありません

■ 本記事の取り扱いについて（免責事項）

目的： 本記事は、公開されている脆弱性情報と公開ソースコードをもとに、lwIP関連の動向を整理し、利用者の注意喚起と確認ポイントの整理を目的としています。
検証： 本記事の技術的な記述は、CVEレコード、CISAのアドバイザリ、upstream lwIPのリポジトリとバグトラッカー、手元にあるlwIPの各正式リリースとベンダーSDKのソースコードの照合に基づくものです。実機での再現・検証は行っていません。
自己責任： 修正の取り込みや対応の判断にあたっては、各プロジェクトの要件に基づき、利用者自身の責任において十分な検証を行ってください。
免責： 万一、本記事の情報に基づいて生じた損害やトラブルについて、筆者は一切の責任を負いかねます。

■ 最後に

今回は、2026年9月22日にCISAが公表したlwIPの脆弱性2件（CVE-2026-87121、CVE-2026-91018）を、ソースコードとの照合結果とあわせて整理しました。深刻度の数字よりも、「関係する機能が限られていること」「示された修正コミットと、実際に取り込むべき変更がずれていること」「正式リリースがまだないこと」の3点が、自社製品の判断では重要です。

lwIPは無料で手軽に製品に組み込める反面、利用する際にはバージョンや設定、既知の問題を把握しておくことが重要です。
また、商用製品のような保証付きサポートが前提ではないOSSであるため、最終的にはメーカー自身で不具合や脆弱性に対応しなければなりません。
そのため対応コストが製品出荷後に増大するリスクについても考慮しておく必要があります。

OSSであるlwIPには多くの利点がありますが、長期保守やサポート体制が重要な製品では、商用スタックを選択するケースもあります。

ただし、すでにlwIPで開発中の製品や出荷済みの製品を今から置き換えることは現実的ではありません。
そういった方に向けて、本記事の情報が、

不具合や脆弱性の早期発見
原因特定の時間短縮
対応コストの低減

の参考になれば幸いです。

今後も、lwIPの問題に対して実用的な情報を公開します。

【lwIP】News #11｜MQTTの脆弱性、自社製品は対象か｜CVE-2026-87121（CVSS 9.8）と6LoWPANのCVE-2026-91018

■ 今回のニュース概要

■ 自社製品が対象かを切り分けるチェック

■ CISAの記載だけでは判断を誤る3点

1. 「lwIP全体」に見えるが、関係するのは2つの機能だけ

2. CISAが示す修正コミットは、テストコードの1行だけを変えている

3. 修正は開発版にだけ入っていて、正式リリースはまだない

■ lwIPのMQTT脆弱性（CVE-2026-87121）：何が起きて、誰が攻撃できるか

何が起きるか

攻撃できるのは、接続先のブローカーか、通信経路上の第三者

対象バージョン（ソース照合）

CVEの約7週間前から、公開のバグトラッカーに載っていた

■ 6LoWPAN（CVE-2026-91018）：対象は6LoWPANを使う構成だけ

何が起きるか

到達するのは6LoWPANの受信処理を登録した構成だけ

対象バージョン：CISAは2.0.1から、ソース上は2.1.0から

■ ベンダーSDKの同梱状況（確認できた範囲）

■ 当面の対応の選択肢

■ 公式対応状況・要確認事項

■ 本記事の取り扱いについて（免責事項）

■ 最後に

関連記事・新着のお知らせ

ピックアップされています

lwIPトラブル対策室｜日本語記事一覧

あなたへのおすすめ

ピックアップされています

lwIPトラブル対策室｜日本語記事一覧