【lwIP】News #12｜CRAの72時間通知、脆弱性の「発生日時」を出せますか｜SRP Glossaryが版番号1.3のまま改訂、利用者への通知義務も確認

2026年9月27日 12:02

CRAの報告窓口であるSRPの入力項目一覧（Glossary）が、版番号を変えないまま改訂されました。版の表示は `Version 1.3` のままで、更新日だけが `25 September 2026` に変わっています。追加は1項目で、積極的に悪用されている脆弱性を報告するときの72時間通知で、「その脆弱性が発生した日時」が必須とされました（Glossaryの表記は `Required`）。版番号だけを記録していた場合、この変更には気づけません。あわせて、SRPへの報告とは別にCRAが製造者に求めている利用者への通知（第14条(8)）を、条文で確認します。

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

本記事は「News」として、lwIPに関する速報・重要な動向をお届けします。News記事は、基本的に外部で公表された情報の整理・注意喚起が中心です。

■ 今回のニュース概要

Glossaryの改訂（CRA SRP Glossary）：表示は `Version 1.3. Last update: 25 September 2026`。9月24日に筆者が取得した版は、同じ `Version 1.3` で `Last update: 10 September 2026` でした。本文の差分は、脆弱性側の項目 `v26a` の追加1件だけです
CRA第14条(8)（Regulation (EU) 2024/2847）：積極的に悪用されている脆弱性や重大インシデントを認識した後、製造者は影響を受ける利用者へ知らせる必要があります。SRPへの報告とは別の義務です

本記事は、lwIPを組み込んだ製品を出荷しているメーカーで、脆弱性・インシデントの報告を担当する方（品質保証・セキュリティ担当、開発リーダー、製品担当者）に向けたものです。読むと、72時間通知までに何をそろえておく必要があるかと、SRPへの報告だけでは済まない義務がどこにあるかが分かります。

本記事の確度

2026年9月27日に、SRPの公式文書（Glossary、FAQ、操作マニュアル、各ガイダンス、CSIRT一覧、利用規約のページ）を取得し、筆者が9月24日と9月25日の朝に取得した原文と比べました。Glossary以外は本文が変わっておらず、操作マニュアルのPDFはファイルのハッシュ値も同じでした
Wayback Machine（Internet Archiveの保存版）には、9月27日に検索した時点で、9月15日より後のGlossaryの保存がありません。変更が入った正確な時刻は分かりません（9月25日朝の取得分にはまだありませんでした）
CRAの条文は、EUR-Lex（EUの官報）の原文から引用しています。引用は原文（英語）をそのまま示し、日本語は筆者による説明です
筆者はSRPの画面を操作していません。本記事は公開文書の記載に基づきます。lwIPのコードそのものへの影響はありません

■ 確認1：Glossaryでは、72時間通知で「脆弱性が発生した日時」が必須とされました

追加された項目

Glossaryの脆弱性（AEV：積極的に悪用されている脆弱性）側に、項目番号 `v26a` として次の項目が加わりました。

Date and time when the Actively Exploited Vulnerability occurred (UTC time)

（積極的に悪用されている脆弱性が発生した日時（UTC）、という趣旨）

報告の段階ごとの扱いは、次のとおりです。

早期警告（24時間）：`Optional`（任意）
72時間通知：`Required`（必須）
最終報告：`By default copied from previous step, or updated`（前の段階から引き継がれ、必要なら更新）

Glossary上は、72時間通知でこの日時の入力が必須です。実際の画面にこの欄がすでにあるのか、未入力だと送信できないのかは確認できていません。未入力では提出できない可能性を前提に準備しておくのが安全です。

正確に分からない場合は、推定値でよいとされています

同じ行の記入方法の欄には、次の記載があります。

Known or estimated date and time when the actively exploited vulnerability occured.

For example, enter the date and time since when the vulnerability exists. If the exact time is unknown, enter the best supported estimate and identify it as estimated in the vulnerability description.

（既知の、または推定した、積極的に悪用されている脆弱性の発生日時。例えば、その脆弱性がいつから存在しているか（存在し始めた日時）を入力する。正確な時刻が分からない場合は、根拠のある推定値を入力し、脆弱性の説明欄で推定値であることを明記する、という趣旨。`occured` は原文のままです）

「分からないから空欄」ではなく、「根拠のある推定値と、その根拠」を用意することが求められています。

重大インシデント側では、インシデントの発生日時が9月10日の改訂で72時間必須になっていました（News #10 の確認3）。72時間で必須という扱いは、脆弱性側もこれでそろいました。ただし記入例の書き方は違います。インシデント側は `enter the date and time when the incident began or occurred`（始まった、または発生した日時）、脆弱性側は上のとおり「いつから存在しているか」です。

「発生した日時」が製品の何を指すかは、決まっていません

記入例の `since when the vulnerability exists` からは、悪用が始まった時点ではなく、脆弱性が存在し始めた時点を求めているように読めます。公式FAQの質問13も、`active exploitation occurred`（悪用が起きた）と `the underlying vulnerability existed`（もとの脆弱性が存在していた）を言い分けており、ENISA自身は2つを区別しています。一方、項目名は「悪用されている脆弱性が発生した日時」なので、悪用の開始と読む余地も残ります。製品について、どの出来事の日時を入れればよいかは、Glossaryに書かれていません。

そのため、どちらの読み方になっても推定の根拠を出せるように、記録を用意しておくことになります。ここからは筆者の整理です。以下は `v26a` の定義ではなく、推定の根拠になり得る社内記録の候補です。

脆弱性が存在し始めた時点と読む場合：問題のあるlwIPのコードを含むファームウェアを、いつ作り、いつリリースし、いつ最初に出荷したか。その前提として、どのファームウェアの版にどのlwIPのバージョンが入っているかの対応
悪用が始まった時点と読む場合：攻撃の痕跡をいつ観測したか（機器のログ、顧客からの報告、ネットワーク側の記録など）。ログの保存期間が短い機器では、後からさかのぼるのが難しくなります

例として、News #11 で扱ったMQTTクライアントの問題（CVE-2026-87121）は、lwIP 2.0.1 から 2.2.1 までの全版に該当コードがありました。この件は、2026年9月22日の公表時点でCISAが「既知の悪用はない」としています。あくまで、仮に悪用されている脆弱性として報告する立場になった場合の考え方の例です。その場合、自社のどのファームウェアの版にどのlwIPのバージョンが入っていて、いつ出荷したかをすぐに出せなければ、「存在し始めた時点」の推定値を72時間以内に用意するのは難しくなります。

第14条(2)(b)の条文には無い、SRP側の入力項目です

CRA第14条(2)(b)は、72時間通知の内容を次のように定めています。

unless the relevant information has already been provided, a vulnerability notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability, which shall provide general information, as available, about the product with digital elements concerned, the general nature of the exploit and of the vulnerability concerned as well as any corrective or mitigating measures taken, and corrective or mitigating measures that users can take, and which shall also indicate, where applicable, how sensitive the manufacturer considers the notified information to be;

（関連する情報がすでに提供されている場合を除き、製造者が積極的に悪用されている脆弱性を認識してから72時間以内に、対象製品、悪用と脆弱性の一般的な性質、実施した是正・緩和措置、利用者が取り得る是正・緩和措置についての一般的な情報を、入手できる範囲で提供し、該当する場合は通知した情報の機微性をどう考えるかも示す、という趣旨）

この条文の記載事項に「発生日時」は含まれていません。今回の必須化は、SRP Glossaryが示す入力要件の変更で、第14条(2)(b)の条文が変わったわけではありません。ただし、第14条(10)は、欧州委員会が実施法令で通知の形式と手続を定められるとしています。その採択状況は確認していません。いずれにしても報告はSRPから出すので、実務上はGlossaryの入力要件に合わせて準備することになります。

「認識した日時」の欄は、Glossaryの脚注どおりなら、まだありません

脆弱性を認識した日時の項目（`v26`、項目名 `Date and time when you become aware of the Actively Exploited Vulnerability`）には、脚注 [1] が付いたままです。

[1] This field will be available in the next release of the Platform.

（この項目はプラットフォームの次期リリースで利用可能になる、という趣旨）

この脚注は News #10 でも取り上げました。今回追加された `v26a`（発生日時）には、この脚注が付いていません。Glossaryの記載どおりなら、「いつ発生したか」の欄は72時間で必須になった一方で、「いつ認識したか」の欄はまだ現行リリースに無い、という順序になります。ただし、`v26a` に脚注が無いことから、現行の画面にこの欄が実装済みだとまでは言えません。

法定期限の起点は「認識した時点」です。画面に欄が無い場合でも、認識した時刻は社内でUTCとあわせて記録しておく必要があります。この点は News #9 の確認1（72時間カウンタの起点）とも関係します。

■ 確認2：版番号を変えずに内容が変わったのは、筆者が確認した範囲で2例目です

News #10 は、「公式文書を読んで手順を作るなら、読んだ版を記録し、原文を保存しておく」ことを主題にしました。その後、版番号を変えずに内容が変わる例が2つ続いています。

操作マニュアル（9月17日）：ページの `Last updated`、PDF内の `Version: 1.1`、文書履歴のいずれも変えないまま、PDFの中身が差し替わりました。Secondary ARの閲覧範囲の記載が逆方向に書き換わった件で、News #10 の確認4で訂正しています
Glossary（9月25日）：`Version 1.3` のまま、`Last update` の日付と本文が変わりました。今回の `v26a` です

版番号の記録だけでは、どちらの変更にも気づけません。操作マニュアルは `Last updated` の表示すら変わっていませんでした。社内手順書に記録するなら、文書名・版・更新日に加えて、取得日と、取得した原文そのものが必要です。筆者が今回Glossaryの差分を1行単位で示せたのは、9月24日と25日に取得した原文を手元に残していたからです。

■ 確認3：SRPへの報告とは別に、利用者へ知らせる義務があります

条文

CRA第14条(8)です。

After becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of the product with digital elements, the manufacturer shall inform the impacted users of the product with digital elements, and where appropriate all users, of that vulnerability or incident and, where necessary, of any risk mitigation and corrective measures that the users can deploy to mitigate the impact of that vulnerability or incident, where appropriate in a structured, machine-readable format that is easily automatically processable. Where the manufacturer fails to inform the users of the product with digital elements in a timely manner, the notified CSIRTs designated as coordinators may provide such information to the users when considered to be proportionate and necessary for preventing or mitigating the impact of that vulnerability or incident.

（製造者は、製品のセキュリティに影響する、積極的に悪用されている脆弱性または重大インシデントを認識した後、影響を受ける利用者に、また適切な場合はすべての利用者に、その脆弱性またはインシデントを知らせる。必要な場合は、利用者が影響を緩和するために実施できるリスク緩和策・是正措置も知らせる。適切な場合は、自動処理しやすい構造化された機械可読の形式で行う。製造者が適時に利用者へ知らせない場合、通知を受けた調整役のCSIRTが、比例的かつ必要と判断すれば、その情報を利用者に提供できる、という趣旨）

読み取れること

条文から確定できるのは、次の4点です。

対象は、SRPへの報告と同じ2種類（積極的に悪用されている脆弱性と、重大インシデント）です
知らせる相手は、影響を受ける利用者です。適切な場合はすべての利用者です
知らせる内容は、脆弱性またはインシデントそのものと、必要な場合は利用者が取れる緩和策・是正措置です
形式は、適切な場合は機械可読の形式です

24時間・72時間のような固定の期限は、この項には書かれていません。ただし `in a timely manner`（適時に）という時期の要求はあり、製造者が適時に知らせない場合は、CSIRTが必要かつ比例的と判断すれば利用者へ直接知らせることができる、と定めています。「期限が無いから後回しでよい」とは読めません。第14条は2026年9月11日から適用されています（CRA第71条(2)）。

SRPへの提出は、利用者への通知の代わりになりません

第14条は、SRPへの報告と、利用者への通知（(8)）を別の項で定めています。SRPに期限内に提出しても、(8)の義務は別に残ります。

SRPの提出手順のガイダンスには、通知の目的が次のように書かれています。

The purpose of the notification is to inform the relevant users of the CSIRT Designated as Coordinator (CDaC) so they can review, disseminate and further process it.

（通知の目的は、調整役のCSIRT（CDaC）の関係する利用者に知らせ、確認・配布・処理できるようにすることである、という趣旨）

この `users` は `of the CSIRT Designated as Coordinator` と修飾されていて、第14条(8)の `impacted users of the product with digital elements`（影響を受ける製品の利用者）とは別の言葉です。操作マニュアルも、SRPを `AR, CSIRT, and ENISA users` のための基盤と説明しています。少なくとも、この提出の手順を、製品の利用者への通知の手順として読むことはできません。

これまでの本シリーズでは、News #4 で利用者への情報提供が必要なことに触れましたが、第14条(8)の対象・内容・形式までは確認していませんでした。News #6、News #9、News #10 はSRPへの提出の実務が中心でした。今回、利用者への通知を条文から補います。

lwIP搭載製品では何を準備するか（筆者の整理）

ここからはCRAやENISAの記載ではなく、筆者の整理です。

影響を受ける製品の版を特定できるか：どの製品・どのファームウェアの版に、どのlwIPのバージョンが入っているか。確認1の推定にも使う記録です
その版の利用者までたどれるか：影響する版と、出荷先・導入先・シリアル番号・販売代理店などを結び付ける記録が別に要ります。出荷先を把握していない製品では、個別に知らせることが難しくなります
利用者が取れる緩和策を書けるか：lwIP由来の問題では、修正を含む正式リリースが出ていないこともあります（News #11 の時点でも出ていませんでした）。その場合、利用者側で取れる設定変更や運用上の回避策を示せるかが問われます
機械可読の形式：条文は `where appropriate` としており、形式は指定していません。たとえば、米CISAのアドバイザリが使っているCSAF（セキュリティアドバイザリの共通形式）が1つの例です。どの形式がこの要件を満たすかは、公開文書からは判断できませんでした

どの利用者に、どの時点で、何を知らせる必要があるかは、製品と事案によって変わります。個別の判断は、法務部門・専門家への確認が必要です。

■ 補足：メーカー名を誤って登録した場合（公式FAQの質問32）

公式FAQの質問32（`Updated: 17 September 2026` の版で追加）は、News #10 では追加されたことだけを記録し、中身は扱っていませんでした。要点は次のとおりです。

If you make a mistake when entering the manufacturer name during registration, for example a spelling error, you can register the manufacturer again using the correct name. You do not need to take any further action regarding the incorrectly entered manufacturer. If the incorrectly named manufacturer is inadvertently “Verified” by the relevant CSIRT Designated as Coordinator (CDaC), please contact the CDaC and ask them to reject the incorrectly registered entity.

（登録時にメーカー名を誤って入力した場合、例えば綴りの誤りでは、正しい名前でメーカーを登録し直せる。誤って入力したメーカーについて、追加の対応は要らない。誤った名前のメーカーが、担当のCSIRT（CDaC）によって誤って「Verified」とされた場合は、そのCDaCに連絡し、誤って登録されたメーカーの登録を却下するよう依頼する、という趣旨）

同じ回答は、ARとメーカーの関連付けを外す方法にも触れています。メーカーが「Verified」になっていれば、AR自身で外せます。まだ検証されていなければ、検証が終わるのを待って外すか、CDaCに却下を依頼します。

SRPへの登録と検証の開始は、通知が必要になった時点で行うよう勧められています（News #6 のポイント1）。急いで登録する場面で綴りを誤ることは起こり得ます。ただし、誤った名前のまま提出済みの通知がどう扱われるか、登録し直した後の検証がどうなるかは、FAQには書かれていません。

■ 確認できていないこと

`v26a` の「発生した日時」として、製品についてどの出来事の日時を入れればよいか（脆弱性が存在し始めた時点か、悪用が始まった時点か）
`v26a` の欄が、現行のSRPの画面に実際にあるか。あるとして、72時間通知で未入力だと提出できないのか
`v26a` がGlossaryに追加された正確な日時（9月25日朝の取得分には無く、Wayback Machineにも保存がありません）
CRA第14条(10)に基づく、通知の形式と手続を定める実施法令の採択状況
第14条(8)の「機械可読の形式」として、どの形式が想定されているか
FAQの質問32に従って登録し直した場合、誤った名前で提出済みの通知や、誤って登録したメーカーの登録がどう扱われるか
筆者はSRPの画面を操作していません。実際の入力項目・必須の範囲・画面遷移は未検証です

公式文書は本記事の公開後も更新される可能性が高いです。実務判断の際は、必ず一次情報の最新版をご自身で確認してください。

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

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

本記事が触れているCRAの条文番号（第14条(2)・(8)・(10)、第71条(2)）は、Regulation (EU) 2024/2847 の記載に基づくものです。条文そのものの解釈については一次情報をご確認ください。

引用した英文は原文のままです。日本語の説明は筆者によるもので、公式訳ではありません。「筆者の整理」と明記した箇所は、ENISAが書いている内容ではなく、筆者が公開情報から導いたものです。

■ 最後に

今回確認したのは次の2点です。

SRPのGlossaryが、`Version 1.3` のまま9月25日に改訂され、Glossary上、72時間通知で脆弱性の発生日時（UTC）が必須とされました。正確に分からなければ、根拠のある推定値を入れ、推定だと明記します。製品についてどの時点を入れるかは決まっていないので、「存在し始めた時点」と「悪用が始まった時点」のどちらでも根拠を出せる記録が要ります
CRA第14条(8)により、製造者はSRPへの報告とは別に、影響を受ける利用者へ知らせる必要があります。固定の期限はありませんが、適時に知らせない場合は、CSIRTが必要かつ比例的と判断すれば代わりに知らせることができます

発生日時の推定（存在し始めた時点と読む場合）も、影響を受ける利用者の特定も、どの製品のどの版にどのlwIPが入っているかという記録が出発点になります。利用者の特定には、さらに出荷先までたどれる記録が要ります。報告の期限が動き出してから調べ始めるのでは、間に合わない情報です。

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

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

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

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

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

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

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