見出し画像

【lwIP】News #2｜CRAの72時間報告にlwIP製品は間に合うか｜製品担当者が今準備すべき5項目

lwIPトラブル対策室(lwIP Lab)

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

本記事は、外部で公表された制度動向（ENISA公開情報）を整理し、lwIP搭載製品の担当者向けに実務への当てはめを示すものです。制度の細目には未確定の部分があり、その箇所は「要確認」と明記します。

EU Cyber Resilience Act（CRA、サイバーレジリエンス法）の脆弱性・重大インシデント報告について、報告基盤の具体像が見えてきました。ENISA（EUサイバーセキュリティ機関）は2026年7月、報告に使う Single Reporting Platform（SRP）に関するFAQを更新し、稼働時期・報告期限・登録方法などを具体化しています。

lwIPのようなOSSを製品に組み込んでいるメーカーにとって、これは「報告が必要になってから慌てる」のではなく、「事前に自社製品の状態を把握しておく」ことを迫る変化です。本記事では、何が変わるのか、なぜlwIP製品で問題になりやすいのか、そして今から準備しておくべき5項目を整理します。

■ 何が変わるのか（報告基盤SRPと3つの期限）

CRAは、デジタル要素を持つ製品の製造者に対し、積極的に悪用された脆弱性や、製品のセキュリティに重大な影響を与えるインシデントの報告を義務づけています。その報告を受け付ける共通基盤が SRP（Single Reporting Platform）です。ENISAの公開情報によると、主なポイントは次のとおりです。

  • SRPは2026年9月11日に稼働予定で、報告義務の適用開始も同日とされています。なお、この日に始まるのは脆弱性・重大インシデントの「報告義務」であり、CRAの主要義務の適用開始（2027年12月11日）とは別のタイミングです（2026年9月11日にCRAの全要件が課されるわけではありません）。

  • 報告は3段階です。積極的に悪用された脆弱性や重大インシデントを認識した時点から、

    • 24時間以内：早期警告（Early Warning）

    • 72時間以内：初期評価を含む正式通知

    • 脆弱性の場合は修正・緩和策が利用可能になってから14日以内に最終報告（重大インシデントは初回通知後1か月以内）

  • 登録はEU Loginアカウントを使います（EU Login自体は事前に作成できるとENISAのFAQに案内があります）。企業を代表して報告する担当者（Assigned Representative）が本当に代表権を持つかは、最初のアクセス後に担当CSIRTが確認する運用です。ただしENISAは、この確認が完了していなくても報告義務の履行はできるとしており、報告が必要になる前にSRPへ登録して検証を始めることは推奨していません（2026年8月3日更新のガイダンスで明確化されました。この点は News #6｜CRAの脆弱性報告、9月11日開始 で詳しく扱っています）。

  • 現時点でAPIは提供されず、自社システムで報告ワークフローを自動化しても、SRPへの提出はWeb画面経由になる見込みです。

  • ファクトシート（SRP Factsheet）は公開済みです（筆者確認：2026年8月10日）。研修動画の公開状況は筆者未確認です＝要確認。

（出典：ENISA「Single Reporting Platform（SRP）」、CRA SRP - AR User registration、CRA SRP - AR Notification submission and update。上記の細目は今後変更され得るため、実際の運用開始前に一次情報での確認を推奨します＝要確認）

この中で、実務上もっとも重いのは72時間の正式通知です。「認識してから72時間」という時間は、影響を受ける製品を洗い出し、初期評価をまとめるには決して長くありません。

■ なぜlwIP搭載製品で「間に合わない」のか

lwIPを組み込んだ製品は、次の理由から「自社が影響を受けるかどうか」を短時間で判断しにくい構造にあります。

  • バージョンが古いまま：ベンダーSDKに同梱されたlwIPは、1.4.x から 2.2.x まで幅広く、出荷後に更新されていないことが多い。

  • ベンダーforkの改変：ベンダーSDKによってはコアに独自パッチが当たっている場合があり（脆弱性が修正済みのこともあれば、逆に独自の変更が影響することもある）、upstream（開発元オリジナル）の情報だけでは影響有無を断定できない。

  • 設定（有効機能）依存：同じlwIPでも、SNMP・DHCP・DNSなどのどの機能を有効にしているかで、脆弱性が自社製品に到達するかどうかが変わる。

  • 到達可能性の判断が必要：脆弱なコードが含まれていても、その経路が外部から到達可能かどうかで深刻度が変わる。

つまり、脆弱性の一報を受けてから「自社のlwIPは何版か」「どの機能を有効にしているか」を調べ始めると、それだけで72時間を使い切りかねません。事前に自社製品の状態を棚卸ししておくことが、期限内対応の前提になります。

■ 72時間で説明を求められる情報

SRPの報告では、脆弱性・インシデントの内容や影響、実施済み・実施可能な対策などの情報が段階的に求められる想定です（必須・条件付き・任意の項目が3段階の提出に分かれるとされています。項目の詳細は要確認）。

これをlwIP製品の視点で言い換えると、いざ報告となったときに手元で即答できる必要があるのは、おおむね次の情報です。

  • 対象製品と、その製品分類

  • 使用しているlwIPのバージョンと、ベンダーfork（upstreamか、ベンダー改変版か）

  • 有効にしているlwIPの機能（SNMP・DHCP・DNS・RAW/Socket APIなど）

  • その脆弱性が自社製品で到達可能かどうかの判断

  • 適用済みのパッチ、および修正版・回避策の状況

これらは、報告のときに一から調べるのではなく、あらかじめ製品ごとに整理しておくべき情報です。

■ 今から準備する5項目（チェックリスト）

72時間に間に合わせるために、製品ごとに以下を準備しておくことをおすすめします。

□ 1. lwIPのバージョン・ベンダーfork・適用済みパッチの一覧（製品別の台帳）

□ 2. 有効にしている機能の棚卸し（SNMP・DHCP・DNS・IPv6・RAW/Socket APIなど、lwipopts.h の設定を含む）

□ 3. 脆弱性が自社製品に到達可能かを判断できる担当者・体制

□ 4. 対象製品・販売国・顧客通知先の台帳（誰に何をいつ知らせるか）

□ 5. 24時間・72時間報告用の社内テンプレート（何を書くかの雛形）

1つでも「まだ用意できていない」項目があれば、報告が必要になる前に着手しておく価値があります。特に1と2は、後述のとおり本シリーズのBug記事と直接つながります。

なお、SRPには当面APIがないため、社内の脆弱性管理システムから完全自動で提出することはできません。社内で必要情報を自動収集し、最終的に担当者がSRPへ転記・確認する半自動運用が現実的です。

■ 具体例：既存のBug記事で「影響有無」を切り分ける

上記の「有効機能の棚卸し」が、なぜ影響判定に直結するのか。本シリーズで扱ってきた具体的な脆弱性で見てみます。

  • SNMPを有効にしているか：SNMPv3を有効にしたlwIP 2.1.0〜2.2.1には、認証情報を持たない相手からの1パケットで固定長スタックバッファをはみ出す脆弱性（CVE-2026-8836）があります。SNMPを使っていなければこの脆弱性は対象外、SNMPv3を有効にしているなら優先確認、という切り分けができます（詳細：Bug #6）。

  • DHCPクライアントを使っているか：DHCPのトランザクションID（XID）が予測可能になり得る問題は、DHCPクライアントを使う製品に関係します。固定IP運用でDHCPを使っていなければ対象外と判断できます（詳細：Bug #3）。

  • TCPサーバーとして接続を受け付けているか：listen/acceptで外部からの接続を受け付ける製品には、accept()のエラー処理経路にある二重解放バグでクラッシュし得る問題があります（ポートスキャンだけでも発火し得ます）。TCPサーバー機能を持たない製品なら対象外、listen/acceptしているなら確認対象、という切り分けができます（詳細：Bug #1）。

  • SMTPクライアント（メール送信）を使っているか：lwIPのSMTPクライアントには、送信バッファ（tx_buf）のバッファオーバーフローが報告されています。デバイスからメール通知を送るなどSMTPクライアントを使う製品が対象、使っていなければ対象外と切り分けられます（詳細：News #1）。

  • ESP-IDFで独自のDHCPサーバー（SoftAP等）を使っているか：ESP-IDFが独自に同梱するDHCPサーバー実装には、DHCPリクエストのオプション解析で受信データの外側を読むOut-of-Bounds Read（CVE-2026-45160）があります。これは upstream lwIP には無いESP-IDF独自のコードで見つかったもので、upstream のCVEだけを見ていると見落とします。DHCPサーバー（SoftAP等）を使っていなければ対象外、使っているESP-IDF機器なら確認対象、という切り分けができます（詳細：News #3）。

このように、「どの機能を有効にしているか」が分かっていれば、脆弱性の一報に対して「自社は対象か・対象外か」を短時間で切り分けられます。逆に、機能構成が把握できていないと、毎回すべてを調べ直すことになります。

本シリーズのBug記事は今後も継続的に追加していきます。lwIPの脆弱性・不具合は随時新しく見つかり得るため、現時点で自社に該当しそうな項目がなくても、記事一覧（マガジン）をフォロー・ブックマークしておくと、自社が使っている機能に関わる脆弱性が出たときに気づきやすくなります。

（本シリーズでは今後、主要ベンダーSDK（STM32Cube / NXP MCUXpresso / ESP-IDF / TI SDK など）別に、どのCVEが影響するかを整理した資料の公開も検討しています。）

■ まず何をすべきか（次の一歩）

CRAのSRP稼働は2026年9月11日予定です。まだ時間はありますが、製品ごとの棚卸しには手間がかかります。次の順で進めるのが現実的です。

  1. まず「準備5項目」のうち1（バージョン・fork・パッチ台帳）と2（有効機能の棚卸し）に着手する。

  2. 有効機能が分かったら、本シリーズのBug記事で該当する脆弱性の影響有無を確認する。

  3. 影響がある場合の対応方針（最小修正・回避策・アップデート）を、出荷済み製品を含めて検討する。

lwIPの各不具合・脆弱性について、どの条件で・どのバージョンが・どの機能で影響を受けるかは、本シリーズのBug記事でソースコードレベルまで解説しています。まずは自社製品が使っている機能から、関連する記事を確認してみてください。

■ 最後に

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

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

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

  • 不具合や脆弱性の早期発見

  • 原因特定の時間短縮

  • 対応コストの低減

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

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

▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧

いいなと思ったら応援しよう！