【lwIP】News #5｜lwIPの脆弱性に気づけるのはいつか｜GitHub・Savannah・CVE・ベンダーSDKで情報が出る時期はずれている

2026年7月31日 22:24

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

lwIPに脆弱性が見つかったとき、製品担当者はそれをいつ、どこで知ることになるでしょうか。本記事は「News」として、本シリーズで実際に追いかけた2件を材料に、GitHub・Savannah・CVE/NVD・正式リリース・ベンダーSDKで情報が出る時期と、そこから分かる内容がどうずれるのかを整理します。断定できない点は「要確認」と明記します。

■ 今回の記事のきっかけ

本シリーズでは、これまでlwIPの脆弱性を個別に追いかけてきました。その過程で確認できたことがあります。

「CVEが出れば気づける」という前提は、常に成り立つわけではありません。

実際に追跡した2件を並べると、情報の出方がまったく違っていました。片方はCVE番号がつき、NVDにも載っています。もう片方は、修正が upstream lwIP に入ってから2か月半が経っても、CVE番号が確認できません。

どちらも実在する脆弱性で、どちらも upstream lwIP のmasterでは修正済みです。違うのは「外から見えるかどうか」だけです。

以下は、記事執筆時点（2026年7月31日）に筆者が公開情報を確認した結果です。状況は今後変わり得るため、実際の判断時には一次情報での再確認を推奨します。

■ 実例1：CVEが出た脆弱性（SNMPv3・CVE-2026-8836）

SNMPv3の認証パラメータ処理に関する脆弱性（CVE-2026-8836）は、比較的そろっていたほうです。

CVE番号が採番されている
NVDに登録されており、影響範囲が "lwIP up to 2.2.1"（2.2.1以前）と記載されている
脆弱性データベースを検索すれば発見できる

SBOMや脆弱性管理ツールを運用している組織であれば、この件は自動的に引っかかります。通常想定されている「気づき方」が機能するケースです。

ただしこの件でも、ひとつだけ想定どおりでない点があります。影響を受ける 2.1.0〜2.2.1 の正式リリースには、まだ修正が反映されていません。 つまり「CVEを検知して、最新の正式リリースへ上げれば解決する」という手順が成立しません。

この脆弱性の詳細（再現手順・原因・対策）は Bug #6 で解説しています。

■ 実例2：CVEが出ていない脆弱性（SMTPクライアント）

もう1件は、SMTPクライアントの認証応答処理に関するバッファオーバーフローです。この件は News #1 で、公開ソースコードをもとに内容を確認しました。

こちらの情報の出方は、次のようになっています。すべて公開情報から確認できる範囲です。

upstream lwIP（GitHub master）：修正は入っている

2026年5月12日、コミット `614420f` で `src/apps/smtp/smtp.c` が修正されています（コミットメッセージは "smtp: fix server-driven AUTH line overflow into tx_buf"、変更は7行追加2行削除）。lwIPプロジェクト側の対応として外から確認できる最初の手がかりが、このコミットです。

Savannah（バグトラッカー）：報告内容は追えない

上記コミットは Savannah の Bug #68313 を参照しています。ところがこのチケットは非公開で、閲覧しようとすると「This item is private. You are not listed as member allowed to read private items.」と表示されます（2026年7月31日時点で確認）。

つまり、コミットから報告チケットへたどっても、何が報告され、どこまでが影響範囲なのかは読めません。

一方で、CISAが公開報告を発見してlwIP側へ連絡した件は、別チケット Bug #68397 として公開されています。ただしこちらは2026年5月26日に「重複（Duplicate）」としてクローズされており、技術的な内容は含まれていません。

「バグトラッカーを見れば修正理由が分かる」とは限らない、というのがこの件の実態です。

CVE / NVD：本記事執筆時点で確認できない

修正から約2か月半が経過していますが、この問題に対応するCVE番号を、筆者が確認した範囲（NVD、CVEプログラム、GitHub Advisory Database、各種脆弱性データベース）では見つけられていません（要確認：今後採番・公開される可能性はあります）。

脆弱性データベースを起点にした監視では、この件は現時点で拾えません。

正式リリース：入っていない

本記事執筆時点で、lwIPの最新リリースタグは `STABLE-2_2_1_RELEASE` のままです。そして 2.2.1 の `src/apps/smtp/smtp.c` を確認すると、`smtp_prepare_auth_or_mail()` のコピー処理は修正前の構造のままでした。

つまり、正式リリース版を使っている限り、この修正は手元に届いていません。

■ 2件に共通していること

情報の出方は正反対でしたが、ひとつだけ共通していました。

どちらも、修正は upstream lwIP のmasterに入っているのに、正式リリースには反映されていません。

これは実務上、かなり重い意味を持ちます。「脆弱性情報を検知する」「最新版へ更新する」という一般的な運用手順が、そのままでは効かないということです。lwIPの場合、正式リリースの間隔と修正の取り込みタイミングが一致しないため、リリース版を追うだけでは修正が届かない期間が生じます。

■ ベンダーSDKのlwIPバージョンはさらに後ろにいます

ここまでは upstream lwIP の話です。実際の製品では、ベンダーが提供するSDKに同梱されたlwIPを使っていることがほとんどです。

本シリーズで調査した、主なSDKが同梱するlwIPのバージョンは次のとおりです。古い順に並べます。

NXP LPCOpen（LPC17xx / LPC40xx系）：lwIP 1.4.1
TI TivaWare（TM4C123 / TM4C129、2.1.4.178）：lwIP 1.4.1
Renesas RZ/A1H Software Package 1.7.0：lwIP 1.4.1（Renesas社による改変あり）
STM32Cube FW_F1 / FW_F2：lwIP 2.0.3
STM32Cube FW_F4 / FW_F7：lwIP 2.1.2
ESP-IDF 5.0〜5.3系：esp-lwip（lwIP 2.1.3 ベース）
ESP-IDF 5.4以降・6.0系：esp-lwip（lwIP 2.2.0 ベース）
Renesas RA FSP（v5.5.0以降）：lwIP 2.2.0
AMD Vitis 2024.1以降：lwIP 2.2.0
STM32Cube FW_H7（v1.13.0）：lwIP 2.2.1（ST社による改変あり）
NXP MCUXpresso SDK（26.03.00）：lwIP 2.2.1 ベースのNXP fork（NXP社による改変あり）

upstream lwIP の最新リリースが 2.2.1 であることを踏まえると、SDKによって開きが大きいことが分かります。最新に追随しているものもあれば、1.4.1 のまま提供されているものもあります。lwIP 1.4.1 に同梱されているCHANGELOGの最終エントリは 2012年9月26日付けで、現行の 2.2.1 とはメジャーバージョンが異なります。

注目したいのは、同じベンダーでも提供するSDKによって位置が違うという点です。上の一覧で、NXPは LPCOpen（LPC17xx / LPC40xx系）が 1.4.1、MCUXpresso SDK が 2.2.1 ベースと、一覧の両端に現れています。旧世代の製品系列向けSDKが古いバージョンのまま維持されているためです。

つまり、upstream lwIP のmasterに修正が入ってから、それがSDKに降りてきて、さらに自社製品のビルドに取り込まれるまでには、相応の時間がかかると考えておく必要があります。自社が使っているSDKがどの位置にいるかは、ベンダー名だけでも、SDK名だけでも決まりません。

なお、ベンダーSDKは upstream lwIP に独自の改変・追加を加えている場合があります。その場合、upstream lwIP の情報だけでは影響有無を判断できません。この具体例は、ESP-IDF独自のDHCPサーバー実装で見つかった脆弱性（CVE-2026-45160）を扱った News #3 で解説しています。

■ lwIPの脆弱性情報：チャネル別に何が分かって何が分からないか

ここまでを整理すると、次のようになります。

upstream lwIP のリポジトリ（GitHubおよびSavannahのgitリポジトリのmaster）

分かること：修正が入った事実と、その日付。最も早い
分からないこと：深刻度、影響を受けるバージョンの範囲、外部から到達可能かどうか

Savannah バグトラッカー

分かること：公開されているチケットであれば、報告内容・再現条件・議論の経緯
分からないこと：非公開チケットの内容。脆弱性の報告が非公開で扱われている場合、ここからは何も読めない

CVE / NVD

分かること：採番されていれば、影響範囲と深刻度スコア。自動監視に載せやすい
分からないこと：採番されていない問題。そして採番までの時間は一定ではない

正式リリースタグ

分かること：自分が更新すべき対象があるかどうか
分からないこと：masterに入っている修正のうち、どれがまだ届いていないか

ベンダーSDK / ベンダーの告知

分かること：自社製品に最も近い形での対応状況
分からないこと：upstream lwIP からの遅れ幅。SDK独自コードの問題は upstream lwIP 側には出てこない

情報が出る順序は案件ごとに変わります。 今回の2件でも、片方はCVE経由で拾えて、もう片方は拾えませんでした。ひとつのチャネルだけを見て「何も出ていないから大丈夫」と判断するのは危険です。

■ ただし、監視だけでは判定できません

ここが本記事でいちばんお伝えしたい点です。

仮に上のチャネルをすべて見張っていたとしても、「自社製品が影響を受けるか」は分かりません。

実例2のコミットを例にすると、そこから読み取れるのは「SMTPクライアントの認証応答処理が修正された」ということだけです。自社製品の担当者が判断しなければならないのは、その先です。

自社が使っているlwIPに、そもそも該当のコードが含まれているか（`apps/smtp` はlwIP 2.1.0で追加されたもので、2.0.x系には含まれていません）
その機能を有効にしてビルドしているか
外部から到達可能な経路があるか（接続先が信頼できる相手か、通信経路上で応答が改ざんされ得るか）
ベンダーSDKが独自に手を入れていないか

自社が対象かどうかを切り分ける具体例は、本シリーズの各記事で扱っています。SNMPを有効にしているか（Bug #6）、DHCPクライアントを使っているか（Bug #3）、ESP-IDFで独自のDHCPサーバーを使っているか（News #3）といった観点です。

チャネルの監視は「気づく」ための入口にすぎず、「判定する」には自社製品側の情報が要ります。 そして判定に必要な情報は、脆弱性の一報が来てから集めていては間に合いません。

EU Cyber Resilience Act（CRA）の報告義務が2026年9月11日から始まることを踏まえると、この点はさらに重くなります。認識時点から24時間・72時間という期限は、気づいた瞬間から動き始めます。気づくのが遅れれば、その分だけ判定と報告に使える時間が減ります。

製品担当者が事前に整備しておくべき情報（製品ごとのlwIPバージョン・ベンダーfork・有効機能・到達可能性など）は、News #2｜CRAの72時間報告にlwIP製品は間に合うかに「準備5項目」のチェックリストとして整理しています。また、lwIP由来の脆弱性について誰が責任を負うのかという論点は、News #4 で扱っています。

■ 要確認事項

本記事の各チャネルの状況は、2026年7月31日に筆者が公開情報を確認した時点のものです。CVEの採番状況・リリースタグ・SDKのバージョンは今後変わります。実際の判断時には一次情報で再確認してください。
実例2についてCVE番号が確認できないことは、「採番されていない」ことの証明ではありません。筆者が確認した範囲で見つけられなかった、という事実の記述です。今後公開される可能性があります。
ベンダーSDKの同梱バージョンは、本シリーズで調査した時点のものです。SDKの更新により変わります。自社が使用しているSDKの実際のバージョンは、手元のソースツリーで確認してください。
lwIPの正式リリースの方針・間隔について、本記事は事実の観測を述べたものであり、プロジェクトの運営を批判する意図はありません。OSSの開発体制として一般的な範囲です。

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

目的： 本記事は、公開情報をもとに、lwIP搭載製品の担当者向けに脆弱性情報の流れ方を整理し、注意喚起・確認ポイントの整理を目的としています。
法的助言ではありません： CRAの条文解釈に関する法的助言ではありません。個別の義務の有無・報告要否の判断は、一次情報および法務・専門家の確認に基づいて行ってください。
自己責任： 対応の判断にあたっては、各社の事業形態・製品要件に基づき、利用者自身の責任において十分な確認を行ってください。
免責： 万一、本記事の情報に基づいて生じた損害やトラブルについて、筆者は一切の責任を負いかねます。

■ 最後に

今回は、本シリーズで実際に追いかけた2件を材料に、lwIPの脆弱性情報がどのチャネルにいつ出るのかを整理しました。要点は次の3つです。

情報が出る順序は一定ではない。 CVEが出る件も、出ない件もある
修正が upstream lwIP のmasterに入っていても、正式リリースには入っていないことがある。 今回の2件はどちらもそうだった
監視は「気づく」ための入口にすぎず、「自社が影響を受けるか」の判定には自社製品側の情報が要る

脆弱性情報を追う仕組みを整えることと、自社製品の構成を把握しておくことは、どちらか一方では足りません。両方そろって初めて、一報が来たときに短時間で判断できるようになります。

なお、本記事の実例2（SMTPクライアントの脆弱性）については、CVEの採番・公開が確認できた時点で、改めて続報としてお伝えする予定です。

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

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

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

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

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

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