cisagov

冷蔵庫がサイバー攻撃されたらしいので、調べてみた !hero-cyberpunk.png - 作成日: 2026-11-05（JST）、最終更新 2026-11-05（一次資料・保存集計を再検証し、推定と断定表現を修正） - 対象期間: 2026-10-11 〜 2026-11-04 - 情報源: 公開報道・公的機関警報・ベンダ声明・セキュリティ企業報告・X上のキーワード検索（末尾「出典」参照。X検索は非網羅） - 読み方: 一次・二次資料で確認した事実、資料に基づく推定、筆者の分析・仮説を区別する。「（推測です）」は特に根拠が限定的な仮説を示す。個別の数値・評価の確度は各節の注記を参照。 --- 1. 要約 本報告の視点: 筆者が気にかかったのは、冷蔵庫という身近な設備が攻撃され、市民生活を支える機能に実害が出たことである。普段その制御器や遠隔保守を意識しない人も、食品の販売や医療を通じて設備の安全に依存している。このつながりを、被害と防御の両面から調べた。 確認された影響: 10月のフランス、11月の欧州各国で、冷蔵設備への不正操作と食品廃棄・設備損傷が報じられた。店舗の商品提供への限定的な影響も確認できる。一方、EFSでは血液製剤の損失・健康被害は報告されず、採血・供給は継続した。広域の食料不足や患者被害まで生じたとは評価しない（具体例と出典は2.5）。 調査結果と限界: Shodanの受動集計では、Danfoss StoreView約960件、XWEB約5,180件の検索結果を確認した。サービス単位の検索件数であり、重複を除いた実機台数や侵害台数は確定できない。攻撃主体、初期侵入経路、既知脆弱性の悪用はいずれも未確定である。 結言: 防御の目的は、食品を安全に保ち、必要なサービスを継続することである。設備と保守経路の把握、独立した温度監視、安全な遮断・復旧を、現場が実行できる態勢にする必要がある。 調査の背景と範囲 筆者は10月末、X上で見かけた「11月3日に向けて備蓄を」という言説をきっかけに、欧州の冷蔵設備攻撃を調べた。当初はX検索の要約も参照したが、検索結果の原記録を本フォルダに保存していないため、投稿の規模や議論の中心は再検証できない。英国の3日分の備えを促す案内と、EUの11月3日公表ガイドラインは公式ページで確認した。公式の備えの案内と攻撃を結びつける証拠は確認できない。話題の重なりは調査のきっかけであり、攻撃との因果関係を示すものではない。調査を進める中で、関心の中心は、身近な設備への攻撃が市民生活の実害につながる仕組みと、その被害を防ぐ条件へ移った。英国政府、欧州委員会。 2. 事実（時系列） !timeline.png 2.1 第1波: 2026-10-11〜12 夜（フランス） | 項目 | 内容 | |---|---| | 被害チェーン | Intermarché、Netto、Coopérative U、Carrefour、Monoprix、E.Leclerc | | 規模（当局） | 約700店（仏財務相 議会答弁、AP）。NYTは400店超 | | 規模（チェーン別・Le Monde集計） | Intermarché/Netto 約300、Coopérative U 約100、Carrefour 80、Monoprix 約30、E.Leclerc 数店 | | 規模（自己申告） | Les Mousquetaires（Intermarché親会社）: 約180店被害、別途100店を緊急切断 | | 温度 | 最高50℃、約6時間（Intermarché 約150店） | | 付随被害 | 一部店舗で機器過熱による火災・溶損 | | 公的対応 | パリ検察が10/12に大規模サイバー攻撃として捜査開始。CERT-FRが同日警報 CERTFR-2026-ALE-012 公開（10/13、10/16更新） | 2.2 第2波: 2026-11-02 未明（多国間） The Hacker News の集約（11/3時点）: | 国 | 事業者 | 被害店舗 | 事業者の説明 | |---|---|---|---| | ベルギー・ルクセンブルク | Delhaize | 数十店 | 「ITインシデント」 | | ベルギー | Carrefour | 15 / 700超 | サイバー攻撃、影響は極めて限定的 | | ベルギー | Intermarché | 10〜15 | 冷蔵庫の問題 | | ベルギー | Spar（Colruyt傘下） | 5 | 冷蔵システムが攻撃された | | ベルギー | IKEA（Mons） | 1 | サイバーインシデント | | スウェーデン | ICA | 少数（数非公表） | サイバー攻撃とは認めず | | スウェーデン | Coop | 6〜7 / 約800 | 無許可で冷蔵設備が改変された | | アイルランド | Musgrave（SuperValu） | 13 / 223 | 1機種に限定されたサイバーインシデント | | エストニア | Selver | 1 | 旧型Danfossシステムへの攻撃 | | オランダ | 食肉店など | 17事業者以上 | Danfossが攻撃と説明 | | フィンランド | Kesko | 小規模数店 | 調査中。中央防護の対象外の機器 | | ポルトガル | Intermarché | 7 | 外部保守会社経由の攻撃（AFP） | | イタリア | Coop（Radenza、シチリア） | 4以上 | 遠隔制御システムへの攻撃（AFP） | - 報道を集計すると合計100店超で、第1波として報じられた数百店より少ない。ただし国・事業者ごとの報告基準が異なる。 - 一部事業者は「旧型」「中央防護の対象外」などと説明した。これは事業者側の説明であり、攻撃者が意図して残存機器を選んだことを示すものではない。 - ベルギー連邦検察が刑事捜査開始。スウェーデンNCSCは北欧・欧州各機関と情報共有中。 2.3 仏血液事業（EFS）事案: 2026-11-01〜02 夜 - EFSの冷蔵設備保守業者 Coolworld の監視・制御システムが侵入され、3地域拠点の冷蔵室が影響。 - 通常−30℃前後の冷凍庫が110℃に設定された（Le Canard enchaîné 11/3報道）。設定値であり到達温度ではない。 - 輸血用の凍結血漿が潜在的に脅威にさらされた。 - EFSの監視・警報システムが異常を迅速に検知し、当直技術者が対応。血液製剤の損失・健康被害はなし。 - EFSはANSSI・保健省と連携中と発表。 2.4 前例（Danfoss 2025年10月ニュースレター） - 2022年にロシアの16店舗、イスラエルの40店舗で AK-SM 800 が攻撃された事例が記録されている。 - 2026年8月下旬、米軍基地少なくとも6か所の冷凍庫が除霜モードに強制された事案（Nextgov 10月報道、Reuters 10/29報道に基づく） 2.5 市民生活への影響と、確認できた範囲 追加調査では、設備被害が商品提供にどう波及したかと、被害を抑えた事例を確認した。 | 観点 | 確認できた内容 | 評価の範囲 | |---|---|---| | 食品の損失 | ベルギーOverijseのProxy Delhaize店主は、生鮮・冷凍商品の廃棄と売上への影響を証言 | 店舗の在庫・営業への実害。地域全体の食料不足を意味しない | | 利用者への影響 | IKEA Monsは、レストランと店舗の商品提供への影響を限定的と説明 | 一部サービスへの支障。全店休業や長期停止とは確認できない | | 回復 | Delhaize広報は11月3日、被害店舗の営業と供給が正常化したと説明 | 当該チェーンの説明。他社・他国の復旧完了を意味しない | | 医療 | EFSの声明を引用した報道では、製剤の退避・保護が行われ、損失・健康被害なし、採血・供給継続 | 保管機能は脅かされたが、患者への実害は報告されていない | 出典: RTLの店主取材・IKEA説明（11月2日）、RTL／BelgaのDelhaize広報取材（11月3日）、EFS声明を引用したBleepingComputer（11月4日）。EFS公式声明のリンク先は今回の閲覧環境では本文を取得できず、この追加確認では声明引用報道に依拠した。 ここで確認できるのは、市民生活を支える設備・在庫・商品提供への実害である。一般市民の健康被害、広域かつ持続的な食料不足、医療の供給停止は、今回確認した資料からは裏付けられない。生活への影響を論じる際は、発生した損失、限定的なサービス支障、未然に抑えられた危険を区別する。 --- 3. 技術的事実 3.1 対象機器 | 機器 | サポート状況 | 備考 | |---|---|---| | Danfoss AK-SM 800 | EOL（2021年5月）。セキュリティ更新なし | 仏第1波の主要被害機種 | | Danfoss AK-SC 355 | 廃止（2016年） | 同上 | | Danfoss AK-SM 800A | 更新提供対象。適用版はメーカーの最新案内で確認 | 既知脆弱性の研究対象。本件の被害を型番・版単位では確認できない | | Copeland XWEB / Dixell XWEB | CERT-FR警報対象 | Dixell は Copeland 傘下ブランド。ベルギーで被害報告 | 3.2 侵入経路（ベンダ・保守業者の説明。公的確定なし） - オランダの被害機器は安全なネットワーク上になく、デフォルトパスワードのままだった（Danfoss広報、NOS）。 - Danfoss は弱点を「古いソフトウェア」とし、未更新顧客が被害を受けたと説明（VTM）。 - ベルギーでは攻撃者は保守業者の基盤ではなく、個別店舗のシステムへ直接侵入した（Sabcobel CEO）。 - Danfoss は初期アクセス経路を公式には確認していない。 - 日時に基づく認証コードの脆弱性はCISAとClarotyで確認できる。ただし、本件の侵入に使われたかは未確認（3.3）。 3.3 既知脆弱性 Danfoss AK-SM 8xxA（CISA ICSA-25-140-03、2025-05-20公開・08-26更新A。発見者 Claroty Team82 Tomer Goldschmidt） | CVE | 種別 | CVSS v3.1 | 対象 | 修正 | |---|---|---|---|---| | CVE-2025-41450 | 認証バイパス（CWE-287）。日時から生成されるパスワード（「code of the day」）による不正アクセス | 8.2（AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:L/A:H） | R4.2未満 | R4.2 | | CVE-2025-41451 | 認証後のOSコマンドインジェクション（アラームメール設定欄） | 7.6 | 4.3.1未満 | R4.3.1 | | CVE-2025-41452 | 認証後のWeb設定の外部制御によるDoS | 5.4 | 4.3.1未満 | R4.3.1 | - 修正版の食い違い（4.2 か R4.3.1 か）はCISA原文で解消: 41450はR4.2、41451・41452はR4.3.1。 - CISA: 「これらの脆弱性を標的とした公知の悪用は報告されていない。攻撃複雑度は高い」（2025-08-26時点）。 - 日時ベースの認証コードの存在と、本件での悪用は別の主張である。伝聞を特定のCVEに結びつける証拠はない。 - 脆弱性の組み合わせによって機器の広範な操作が可能となる場合がある。ただし本件でCVE-2025-41450、CVE-2025-41451またはデフォルト認証情報が使われた事実は確認されていない。 Copeland/Dixell XWEB PRO（CISA ICSA-26-057-10、2026-02-26公開。発見者 Claroty Team82 Amir Zaltzman・Noam Moshe） - 対象: XWEB 300D PRO／500D PRO／500B PRO の 1.12.1 以前。XWEB EVO、旧 XWEB 300/500/3000/5000 は勧告の対象外（脆弱性の有無は不明）。 - 全23件のCVE。うち無認証で到達できるもの: | CVE | 種別 | CVSS v3.1 | |---|---|---| | CVE-2026-21718 | 認証バイパス（CWE-327 脆弱な暗号）→ 無認証RCE | 10.0 | | CVE-2026-24663 | 無認証OSコマンドインジェクション（/libraries/install） | 9.0 | | CVE-2026-25085 | 認証バイパス（CWE-394 認証処理の戻り値の誤処理） | 8.6 | | CVE-2026-22877 | 無認証の任意ファイル読み取り（パストラバーサル） | 3.7 | | CVE-2026-20797 | 無認証のスタックオーバーフロー（DoS、隣接ネットワーク） | 4.3 | - 残り18件（CVE-2026-21389・25111・20742・24517・25195・20910・24689・25109・20902・24695・25105・24452・23702・25721・20764・25196・25037・3037）は認証後のOSコマンドインジェクション、いずれもCVSS 8.0。 - 修正: 「最新版への更新」（Copeland ソフトウェア更新ページ、または機器メニュー SYSTEM → Updates | Network）。修正版の番号は勧告に記載なし。 - CISA: 「これらの脆弱性を標的とした公知の悪用は報告されていない」（2026-02-26時点）。 - 第2波（ベルギー等でXWEBが被害）の8か月前に、無認証RCE（CVSS 10.0）が公開されていたことになる。 悪用の有無（本件との関係） - CERT-FR CERTFR-2026-ALE-012 はCVEを一切引用しておらず、侵入経路も特定していない（「管理インターフェースのインターネット露出は一般にベストプラクティスに反する」とのみ記載）。ANSSI・Danfoss・Copeland も本件での悪用を確認した情報はない（SOCRadar「10/13時点でCVEも侵入経路も未公表」、BleepingComputer「侵害方法の情報なし」）。 - 主要被害機種として報じられた AK-SM 800・AK-SC 355 はEOLである。EOLで既知CVEを要しない侵入経路があった可能性はあるが、デフォルト認証情報が実際に使われたとは確認されていない。 - 独自集計（3.4.1）の画面タイトル・証明書名は製品を推定する手がかりであり、型番・ファームウェア・修正済み状態を確定する証拠ではない。脆弱な機器の残存数は不明。 3.4 インターネット露出の定量データ | 出典 | 時点 | 数値 | |---|---|---| | Claroty（Censys） | 2026-08 | AK-SM 800A 露出 2,765台 | | SOCRadar（Shodan） | 2026-10-13 | Danfoss Web UI 世界4,481件、うちフランス2,898件 | | Censys | 2026-10-11 | Danfoss StoreView 露出ホスト2,991、うち61%（1,825）がフランス | | Censys | 2026-10-14 | 攻撃後3日でフランスは71%減。他国は1,166→966と減少幅小 | 3.4.1 独自集計（Shodan、2026-11-05 JST、6回計測） 方法: Shodan /shodan/host/count とファセット集計のみ。IP一覧の取得、機器への接続、認証試行は行っていない。保存ファイル counts.json〜counts6.json の記録時刻は10:06〜10:48 JST。スクリプトは各回の開始時に時刻を記録するため、最終クエリの終了時刻ではない。 単位は検索に一致したサービス／バナーの件数であり、実機台数ではない。 同一機器の複数ポート、共有証明書、IP変動、検索条件の一致範囲が影響する。after:20/10/2026 と after:29/10/2026 は観測時刻の絞り込みであり、それぞれの期間に存在した全機器の数や、攻撃前後の切断数を示さない。Shodan API仕様 | 製品・検索条件 | 日付指定なし | 10月20日より後の観測 | 10月29日より後の観測 | |---|---:|---:|---:| | StoreView、cloud・honeypot・iiNet名義を除外 | 約2,310 | 約964 | 約515（差引参考値） | | XWEB、cloud・honeypotを除外 | 7,369 | 5,178〜5,179 | 2,520〜2,522 | | pCOWeb、タイトル一致 | 528 | 442 | 未集計 | | Televis Go、タイトル一致 | 39 | 33 | 未集計 | StoreViewの964件は counts6.json の sv_vulns_r16.total、XWEBは counts4.json と counts6.json に対応する。StoreViewの7日相当は780−265＝515だが、除外集合の重なりを照合できない差引参考値である。同日内にも数件の揺れがあり、異なるクエリ結果の厳密な加減算には限界がある。 !exposure-estimates.png 再検証で確認した所見と限界 - 除外条件の影響が大きい。 StoreViewは全件6,801に対し、cloud・honeypot除外後は3,366〜3,370、さらにiiNet名義を除くと約2,310。タグは実機・おとりの完全な判定ではなく、正規機器を除外する可能性もある。 - iiNet名義はノイズの疑いとして除外した。 1,055件と非標準ポートへの分布は保存結果で確認できるが、個々のIPや機器は確認していない。1,055件を1,055アドレスと解釈することも、他社の過去集計が同じノイズを含むと断定することもできない。10月20日以降は、除外前1,579件に対し除外後約964件で、結論がこの仮定に左右される。 - 機種構成・修正状況は確定できない。 同期間のHTTPS絞り込みでは357件中336件の証明書CNが DanfossSM800A だった。一方、別のタイトル検索では同CNが523件あり、検索条件間の整合に未解明な点がある。証明書名は偽装・共有も可能である。「800Aが68%以上」「EOL機は最大3割」「新UIの169台は修正済み」という旧評価は撤回する。 - 証明書の種類数は実機の識別子ではない。 XWEBのHTTPS検索では417件に359種類のフィンガープリントがあり、比率は約1.16。一つの証明書を31件が共有する分布もある。共有や証明書更新を区別できず、これをIP変動による重複率としてHTTP機器全体に適用できない。「XWEB約4,000〜4,500台」「StoreView約900台」というユニーク台数推定は採用しない。 - 観測期間の差は切断率ではない。 フランスの80/443番は日付指定なし416件、10月20日以降141件。非標準ポートは915件と136件。同一時点の検索窓の違いであり、66%・85%の切断を実証しない。また、7日相当の件数が少ないことから実態を一律に2倍へ補正することはできない。 - Censysとの直接比較はできない。 フランス以外のStoreView 687件と、別サービス・別日の966ホストは計測条件が異なるため、「3週間で約3割減」とは評価しない。先行資料の露出減少は、その資料の測定結果として扱う。 - 日本の検索結果は限定的。 StoreViewのタグ除外後3件、XWEBのタイトル一致1件、pCOWebのタイトル一致0件を確認。「冷蔵庫遠隔監視システム」というタイトルは3件あるが、ログイン画面か、同一機器の別サービスか、製品や用途は確定できない。これだけで国内設備の安全性や国産機器の利用割合は判断できない。 本集計が示すのは、冷蔵関連の管理画面らしいサービスが検索可能な状態で残っていることである。侵害の有無、脆弱版の割合、実機台数、対策効果の測定には、追加の識別情報と同一条件の継続観測が必要になる。今回の再検証では新たな機器調査を行わず、保存済みデータの整合性を確認した。 3.5 観測された操作と推定される流れ !attack-flow.png 報道・公的資料で確認された操作: 管理用制御器の設定温度や除霜設定が変更され、食品廃棄や設備損傷が生じた。第1波では一部店舗が最高50℃への変更と約6時間の温度上昇を報告している。すべての店舗に共通する値ではない。 分析上の推定: 公開された管理画面の探索、不正アクセス、制御設定の変更という流れは事案と整合する。ただし、Shodan/Censysの利用、具体的な認証突破手段、攻撃の自動化は個別に確認されていない。攻撃間で同一の露出機器リストが再利用された証拠もない。 マルウェア、ランサムウェア、身代金要求はいずれも公開情報では報告されていない。これらがないことは、侵入経路や実行方式が確定したことを意味しない。 4. 帰属 4.1 犯行声明（2026-11-04） - Z-Pentest Alliance と NoName057(16) が共同で犯行を主張。動画はイタリアRAIが報道。 - NoName057(16) は Danfoss 従業員・顧客のID／パスワード 2,500行超のサンプルを「DB保持の証拠」として公開を主張。 - Z-Pentest は「問題は欧米事業者の長年の怠慢」と主張。 - 声明は Telegram に投稿後、両チャンネルとも削除。 - 動画・認証情報サンプルは独立検証されていない。認証情報を保持しているという主張だけでは、その情報が本件に使われたことや実行主体の同一性は証明できない。 - 10/12・11/2 の攻撃時には同時的な声明がなかった。 4.2 両グループの背景 - Z-Pentest Alliance: 2024年9〜10月に CARR（Cyber Army of Russia Reborn）と NoName057(16) の元メンバーから形成。露出したICS/HMIパネルへの侵入と画面録画の公開を常套手段とし、公開管理画面や弱い認証を狙う手口が報告される。ただし、使用ツール全体や能力の上限を確定するものではない。 - デンマーク国防情報局は2025年12月、2024年の Tureby Alkestrup 浄水場攻撃（VNC経由でHMIに侵入、水圧操作、配管3本破裂、約500世帯影響）を Z-Pentest に帰属。ロシア国家との関係を評価している。DDISの公表文だけでは、本件冷蔵設備攻撃への関与やGRUへの直接的な帰属は確認できない。DDIS公式発表 - Cybleの集計では2025年Q2に38件のICS攻撃とされる（原文・集計単位は今回未再確認）。声明件数と独立確認された侵害件数は区別する。制裁指定の有無・対象名は本再検証では確認していない。 - NoName057(16): DDoS特化で知られる。 - Forescout「Cold Chain, Open Control」: 2026年1月以降、ロシア系グループが冷蔵システムへの攻撃を20件以上声明。最も活発なのが Z-Pentest と NoName057(16)。過去の関心を示す材料だが、今回の再検証でForescout原文と公開時点を直接確認できていないため、「第1波前に文書化済み」とは断定しない。 4.3 対立仮説 - Sekoia はイラン系アクターの可能性を指摘。根拠は露出ICSを狙う実績と、同一機器がイスラエル・米国で過去に攻撃された前例。 - Sekoia は「現時点でロシア語圏グループの関与を示す技術的証拠はない」とBBCに回答。 4.4 公的立場 - ベルギーCCB: 「誰が背後にいるか不明で、特定できない可能性もある」。 - 政府・ベンダいずれも帰属を確認していない。 - Danfoss・Sabcobel・Kitman は仏事案と「同じ手法」と述べているが、手法の共通性は実行主体の同一性を示さない。 4.5 動機（事実と推測の分離） 公開情報から言えるのは、攻撃が破壊的効果を生み、犯行声明が事後に出たことまでである。 備蓄キャンペーンや「11月3日」投稿との連動、国家関与、攻撃者の動機は確認できない。 根拠となる事実: 犯行声明は事後（11/4）、身代金要求なし、破壊的効果が可視的。 推測（複数シナリオ併記）: - 親ロシア派ハクティビストによる継続的OT破壊キャンペーン: Forescoutが記録した声明とZ-Pentestの既往活動は関連性を検討する材料になる。過去事案の犯行声明は10月の攻撃主体を確定する証拠ではない。また、10月の数百店舗規模への拡大は、これまでの声明パターンと異なる。 - 別主体による模倣／複数主体の並行: 手口は公開情報から容易に再構成でき、排除できない。 - イラン系: Sekoia の仮説。技術的証拠は未提示。 - 国家関与の有無: 「わかりません」。 4.6 NoName057(16) の「Danfoss認証情報DB」主張 役割分担（情報取得・拡散 vs 操作実行）か、宣伝への相乗りかは不明。認証情報が仮に本物でも、Danfoss顧客ポータル等の漏洩と、個別店舗のEOL機器へのデフォルトパスワード侵入とは経路が異なり、個別店舗への直接侵入とも両立し得る。入手した認証情報が実際のアクセスに使われた証拠はなく、DB保持の主張だけでは実行主体や侵入経路を裏付けられない。 4.7 声明の信頼度評価 | 要素 | 評価 | 根拠 | |---|---|---| | 手口の一致 | 高 | CERT-FR/ベンダ報告と一致。ただし公開情報から再構成可能 | | 能力の一致 | 高 | デンマーク当局の公式帰属、HMI改ざん実績多数 | | 過去の関心 | 要確認 | Forescoutに言及する二次資料。原文と各声明の日付は未再確認 | | 声明のタイミング | 低〜中 | 攻撃時に声明なし。事後声明は便乗と区別困難 | | 証拠の質 | 低 | 認証情報サンプル未検証・削除済み。侵害機器固有の情報なし | | 公的確認 | なし | Sekoia は技術的証拠なしと明言 | 総合: 犯行を主張する候補であり、未立証。他候補より有力と順位付けできる技術的証拠は確認できない。 --- 5. 分析 5.1 攻撃の性質 報道された実行段階では、冷蔵制御器の正規機能を使った設定変更が被害につながった。これは攻撃者がどの手段で機器へ入ったかを示すものではない。初期侵入経路が公的に確認されていないため、攻撃全体の技術難度や自動化の程度は評価できない。 攻撃が複数店舗に及んだことは広範な実行と整合するが、被害店舗数とShodan/Censysの露出台数を単純に比べて、標的選定や試行方法を推定することはできない。温度設定や除霜の変更自体が正規機能で行われたとしても、初期侵入の難度は別に評価する必要がある。 2.5で整理したように、影響は食品の損失や一部の商品提供に及んだ。設備を利用する市民自身が制御器の更新や保守接続を管理することは難しく、生活上の安全が事業者の設備防護に依存する構造がある。 防御の成否を評価するには、侵入の有無に加え、冷却機能の維持、温度逸脱の検知、保管物の保護、サービスの継続を確認する必要がある。 5.2 第2波の規模差から言えること 第2波の規模縮小は、第1波後に一部の露出が減ったことと整合する。一方、それが防御側の対策によるものか、攻撃者の標的・実行方法の違いによるものかは、公開情報だけでは切り分けられない。残存機器を狙った可能性はあるが、同一リストの再利用を示す直接証拠はない。 5.3 EFS事案の意味 EFS声明を引用した報道では、監視・警報と担当者の対応が製剤保護に寄与したとされる。監視系統が制御系統から技術的に独立していたかは、今回確認した資料では特定できない。独立監視は、この事例から筆者が提言する防御策である。被害対象が食品から輸血用血液製剤へ広がり得ることも示した。一方、EFSが意図的に選ばれたか、保守業者経由で偶発的に到達されたかは、公開情報から判別できない。 5.4 構造的な課題 本件は、機器の脆弱性に加え、設備の所有者・店舗運営者・保守業者の間で資産把握、判断権限、復旧責任が分断されるリスクを示している。 公開情報だけで全事案の根本原因と断定はできない。 - 第三者保守モデルでは遠隔保守経路が必要となる場合がある。本件ではインターネットから到達可能な管理画面が問題となったが、保守モデルが直接露出を常態化させたとまでは確認されていない。 - EOL機器の長期残存（AK-SC 355 は10年前に廃止）。 - 小売側のOT資産管理の課題: ICA・Keskoの「自社ネットワークの外」「中央防護の対象外」という説明は、少なくとも一部設備が中央の防護範囲から外れていた可能性を示す。資産台帳の有無までは公表情報から確認できない。 - 契約上の制約も初動計画で確認すべき事項である。CERT-FRは、保守業者へのデータ送信を切る前に保険契約を確認するよう勧告しているが、契約が実際に各事案の切断を妨げたかは確認されていない。 - こうした責任の分断は、指揮・統制の空白を生むリスクがある。所有者、店舗、保守業者の誰が遮断を決め、誰が食品安全を確認し、誰が復旧を承認するかが平時に定まっていなければ、危機時に命令を実行できない。 5.5 事案から読み取れる防御上の教訓 本件から読み取れるのは、設備の制御を奪われる段階と、保管物が失われる段階の間にも介入の余地があることである。EFSの報道は、監視による発見と、担当者による修復・退避が製剤保護につながったと説明している。ただし、各措置の寄与を定量的に比較できる資料はない。 一方、食品廃棄が生じた店舗では、冷蔵機能への支障が在庫の損失へ進んだ。警報が出たかだけでなく、対応までの時間と代替保管の可否が重要な検証項目になる。具体的な実施事項は7章にまとめる。 MITRE ATT&CKとの対応（ICSを中心とし、探索仮説のみEnterpriseを参照） | 段階 | 技術 | 本件との関係 | |---|---|---| | Reconnaissance（Enterprise） | T1596 Search Open Technical Databases | Shodan/Censysによる列挙の可能性。個別の利用は未確認 | | Initial Access | T0883 Internet Accessible Device、T0812 Default Credentials、T0866 Exploitation of Remote Services | いずれも候補。実際の侵入経路は未確認 | | Impair Process Control | T0836 Modify Parameter、T0831 Manipulation of Control | 設定温度・除霜設定の変更として報告 | | Inhibit Response Function | T0878 Alarm Suppression | 本件での確認なし | | Impact | T0879 Damage to Property、T0826 Loss of Availability | 設備損傷や機能停止に対応する候補。個別事案の裏付けに応じて適用 | T1596はEnterpriseのReconnaissanceに属する。T0880 Loss of Safetyは安全システム機能の侵害を扱い、食品安全への一般的な危険と同義ではないため、本件の確認済み技術から除外した。MITRE T1596、MITRE T0880 コラム：戦術の目で読む、冷蔵設備へのサイバー攻撃 私は以前から、戦術の考え方をサイバーセキュリティに持ち込み、ツール作りにも生かしてきた。今回の事案も、攻撃者と防御者の行動を整理する手がかりとして、いくつかの戦術概念に重ねて読める。ただし、以下は公開情報からの類推であり、攻撃者の実際の計画や意図を示すものではない。 攻撃側：弱点を突き、効果が出る機能を使う。 報道で確認されたのは、冷蔵制御器の設定や除霜機能が不正に操作されたことだ。マルウェアを使わず、設備が元から備える機能を利用して温度を変えた点は、戦術上の「敵の強みや仕組みを逆用する」発想を連想させる。管理画面が外部から到達可能だった機器や、古い機器が関係したとの説明もあるが、本件の初期侵入経路は確定していない。したがって「攻撃者は偵察後、脆弱な後方を狙った」といった作戦像までは断定できない。 守る側：前線は店舗、守る対象は補給の流れ。 陸戦では部隊の戦闘力を保つ補給が重要になる。今回の冷蔵設備も、食品や血液製剤を安全な状態で届ける流れを支える。制御器を守ることは目的の一部で、温度逸脱を早く見つけ、商品を退避させ、代替保管を確保し、供給を続けることまでが防御になる。EFSでは監視・警報と担当者の対応により製剤が保護され、食品廃棄が生じた店舗では、設備の異常が在庫損失まで進んだ。防御の成否は、侵入を防げたかだけでなく、補給・供給への影響をどこで止めたかでも見る必要がある。 指揮の要点：霧の中でも任務を止めない。 初期侵入経路や攻撃者が分からなくても、温度と製品の安全は待ってくれない。まず何を守るかを決め、現場が安全に遠隔接続を制限できる権限を明確にする。SOCや設備担当など役割の違う人が同じ状況を見て、温度、設定変更、警報、保守記録を突き合わせる。上位の責任者は目的と復旧条件を示し、具体的な操作は設備を知る現場に委ね、実測値で効果を確かめる。この考え方は、任務を共有し現場に判断の余地を残す「任務型指揮」と響き合う。任務型指揮の歴史的な背景には、1806年のイエナ・アウエルシュタットでの敗北後に進んだプロイセン軍改革があると米陸軍大学出版局は解説している。ただし、軍隊の指揮原則を企業や保守現場へそのまま移せるという意味ではない。Army University Pressの解説 この事案を戦術になぞらえる意味は、攻撃者を軍隊扱いすることではない。限られた情報の中で、どこが弱点となり、何を守れば被害を抑えられ、誰に判断を委ねるべきかを考えるために、戦術の道具立てを借りることにある。冷蔵設備の先には生活がある。その現実から逆算して、技術と人の動きを一緒に設計したい。 6. 結論 結言: サイバー攻撃の影響は、日常の設備を通じて、市民生活を支える機能にも及ぶ。本件では冷蔵制御器の不正操作が食品廃棄・機器損傷につながり、血液製剤の保管も脅かされた。守るべきものは、その先にある食品の安全と医療を支える機能である。そのために、設備の責任者が保守経路を含む状況を把握し、安全な遮断、独立監視、代替手段、復旧確認を実行できる態勢を整える必要がある。 6.1 結論として言えること - 物理的影響: 冷蔵制御器の設定変更が食品廃棄・機器損傷につながり、血液事業の設備にも危険が及んだ。マルウェアが報告されなくても、正規の制御機能の不正利用は現実の被害を生む。 - 不確実性: 初期侵入経路、攻撃主体、各波の関係は確定していない。犯行声明や機器の露出数を、個別攻撃への帰属・侵害の証明として扱わない。 - 防御上の教訓: 資産・遠隔保守経路の掌握、設定値と実測値の独立監視、安全な遮断・復旧手順を組み合わせる。EFSの報道は監視・警報と担当者の対応が被害抑止に寄与し得ることを示す。 市民に設備防護の責任を負わせることはできない。設備を運用する組織と保守業者が、利用者の生活への影響を踏まえて対処する責任を担う。責任者が任務・権限・連絡体制を整え、現場が異常を伝え、安全に対応できるようにすることが、以下の提言の目的である。 6.2 調べてみて、気になったこと 今回調べながら考えたのは、「この設備が止まったとき、誰の生活に何が起きるか」ということだった。冷蔵庫の向こうには、食品や血液製剤があり、それを必要とする人がいる。サイバー攻撃を普段意識しない人の生活も、こうした設備の安全に支えられている。 気になったのは、ネットワーク上の異常と、現場で起きる異常が別々に扱われてしまう可能性だ。通信や認証の記録だけでなく、温度の推移、設定変更、現場の警報を重ねることで、何が起きているのか見えやすくなる。ログを見る人と設備を見る人が、すぐに話せることも大切だと思う。 そして、原因が分かるまで待てない場面がある。攻撃者を調べている間にも、庫内の温度は変わり、食品や製剤の状態は悪くなり得る。誰が遠隔接続を止める判断をするのか、誰が保管物の安全を確認するのか。その役割が曖昧だと、異常を見つけても対応につながらない。 あらかじめ守るものと判断の基準を共有し、具体的な処置は設備に詳しい人の知識を生かす。そのうえで、実測温度やサービスの状態を見て、対応が効いたか確かめる。技術的な対策と、それを実行できる人や連絡体制を合わせて考える必要があると感じた。 身近な冷蔵庫の話を追っていたら、いつの間にか「生活を支える設備を、誰がどう守るのか」という話になっていた。そこが、この事案を調べてみて一番考えさせられたところだ。 --- 7. 推奨アクション 7.1 防御（事業者向け） !response-flow.png 以下は個別設備の保守手順ではなく、全社で共有する優先順位である。人命・食品安全と冷蔵機能を守り、遠隔操作経路を閉じ、現況を確認してから復旧する。設備ごとに遮断の安全性が異なるため、中央は最低基準と判断権限を示し、現場責任者・保守業者と協調して実行する。 公的機関の指針（CERT-FR・スウェーデンNCSC） 原文確認: 表題「Incident de sécurité ciblant les contrôleurs à distance des installations de réfrigération」。初版10/12、10/13「他の標的機器を追加」（Copeland xweb・Dixell xweb を追加）、10/16「推奨事項を更新」。対象は「Danfoss AK-SC系」「Danfoss AK-SM系」「Copeland xweb」「Dixell xweb」（個別型番の記載なし）。CVEの引用なし、侵入経路の記載なし、件数は「多数（nombreuses）」とのみ。「攻撃キャンペーンはおそらく継続中」と明記。Dixell仏法人の「XWEB監視装置の安全な利用のための推奨事項 v1.0」（2026-10、PDF）へのリンクあり。 未侵害機器: 1. インターネットから到達不能にする（公開IP上の機器を含む）。切断前に保険契約を確認。 2. 除霜スケジュールを含む全設定を点検。 3. 安全なVPNまたは保護ネットワーク経由でのみアクセス復旧。緊急措置としてFWで保守業者IPをフィルタ（恒久策ではない）。 4. メーカーのベストプラクティスに従う（ファームウェア更新、Danfossはセキュリティレベル Strict、デフォルトパスワード変更）。 侵害済み機器: CERT-FRは外部公開の停止後、Danfoss機器の再起動、または工場リセットと再設定を挙げる。安全と証拠保全を確認し、機種に適した手順を保守担当者と実施する。同警報は、更新のないEOL機器を公開したままでは再侵害の危険が高く、リセットだけで解決しないと警告する。交換は本報告の提言であり、CERT-FRの直接の指示ではない。 スウェーデンNCSC: 接続機器の棚卸し、接続要否の判断、残す機器の更新と多層防御。 Danfoss のセキュリティアドバイザリページには11/3時点で本件の記載なし。 実施と完了確認: 上記の措置に担当者と期限を割り当てる。外部からの到達制限、設定の正常性、実測温度、警報の作動を確認して記録する。EOL機器は保護された運用とサポート対象機器への置換を計画する。初動の具体的な順序は7.2に示す。 7.2 日本の現場に置き換えた発見・初動 結言: ネットワークにつながる冷凍機やポンプなどの「IT機器ではない設備」は、サイバー攻撃がまず運転異常や安全上の警報として見えることがある。日本の現場では、ネットワーク監視だけに頼らず、設備の指示値・実測値・警報・現場の観察を照合して異常を見つけ、施設責任者が安全を優先して対処する必要がある。 経済産業省の工場向けガイドライン案は、障害原因が直ちにサイバー攻撃と判明するとは限らないため、機器アラート、計測値、指示値の通常と異なる挙動を監視し、セキュリティ部門と連携する条件・手順をあらかじめ定める考え方を示している。IPAも、制御システムでは攻撃の防御だけでなく、兆候の検知と対応が重要としている。経産省ガイドライン案、IPA「産業用制御システム向け侵入検知製品等の導入手引書」 発見の手がかり - 制御値と実測値の食い違い: 冷蔵庫なら、設定温度に対する実測温度、除霜スケジュール、扉・圧縮機の状態を確認する。設定値の急変と庫内温度の上昇が重なれば、保守作業・故障・不正操作を含む異常として扱う。 - いつもと違う運転や警報: 深夜の設定変更、予定外の除霜、複数設備の同時変化、警報の停止・欠落、再起動の反復などを、通常の運転記録と比較する。 - 独立した計測と現場の気づき: 制御器の表示だけで判断せず、独立温度計・別系統の警報、作業員や保守員の目視・異音・異臭・過熱の報告を突き合わせる。現場の異常報告をIT部門へつなぐ窓口を明確にする。 - 保守アクセスの記録: 保守用VPNや遠隔監視の接続元、利用アカウント、接続時刻、操作対象、設定変更履歴を確認する。通常の保守予定や承認記録と照合し、機器に負荷をかけない受動的な監視を基本とする。 初動の順序 1. 安全と事業影響を確認する。 施設長・工場長などの現場責任者が、人員の安全、食品・製品の品質、設備の継続運転への影響を把握する。制御盤や機器の電源を一律に落とさず、メーカー・保守員と安全な手動運転や代替設備の有無を確認する。 2. 不正な遠隔操作を止める。 安全な手順を確認したうえで、疑わしい外部遠隔接続を遮断または制限する。機器ログ、設定、接続記録、温度推移、現場状況は時刻を付けて保存し、証拠保全と安全確保を両立する。 3. 影響範囲を見極める。 同じ機種、同じ保守業者、共通の遠隔接続先を使う設備・拠点へ確認を広げる。製品や血液製剤など品質・健康に関わるものは、組織の安全・品質手順に従い隔離や出荷停止を判断する。 4. 指揮系統を一本化する。 現場運転、施設管理、情報セキュリティ、保守業者、品質・安全担当の責任者と連絡先を明確にし、共通の状況図で未確認設備、異常値、遮断、製品隔離、復旧可否を共有する。攻撃と断定できなくても、異常の段階で定めた基準に従いセキュリティ担当へ連絡する。 5. 確認してから復旧する。 認証情報・設定・ファームウェア・遠隔接続経路を点検し、必要に応じて再設定・更新・機器交換を行う。現場で実測値と警報の正常性を確かめ、保護された経路に限定して段階的に接続を戻す。 個人が施設設備に直接できる操作は限られる。異常な温度、警報、臭い、音、表示に気づいた場合は、機器を独断で操作せず、施設の責任者・管理会社・保守窓口へ時刻と観察内容を伝える。対処の実務は、設備の安全要件と所管分野の手順に従う。 7.3 CTI・追跡指標 - 帰属は「Z-Pentest/NoName057(16)（自己申告・未確認）、対立仮説イラン系（Sekoia）」と併記し、確度を分けて記録。 - 追跡: (a) 認証情報サンプルの実在アカウント照合報告、(b) 米軍基地事案の機種特定、(c) Z-Pentest 新チャンネル再開と過去動画との整合、(d) 同種攻撃の再発（特に医療・物流のコールドチェーン）、(e) CVE-2025-41450／CVE-2026-21718／CVE-2026-24663／CVE-2026-25085 のCISA KEV登録・公開PoC出現（CISA勧告の「悪用報告なし」は各勧告の公表・更新時点の記載。11月5日時点のKEV・PoCの網羅確認は未実施）。 - Z-Pentest の常套手段（HMI改ざんの画面録画、警報無効化）を検知設計に反映。 - 情報の確度と対応上の意味を分けて報告し、帰属仮説が変わっても露出低減・独立監視・復旧確認の優先順位を保つ。 7.4 研究上の接点 - 「サードパーティ保守経由のOT露出」の典型事例として記録価値あり。日本国内の小売・食品倉庫・薬局にも同型の露出が存在する可能性（未確認）。 - ハニーポット研究では、実機と偽装サービスの識別が課題となる。今回の集計でも疑わしいサービス群を除外したが、実態は未確認であり、既存のおとりの規模を実機台数として扱わない。 - 国内調査では、今回の欧州製品の検索条件で捉えられない機器をどう識別するかが課題となる。「冷蔵庫遠隔監視システム」のタイトル3件は製品特定の手がかりにとどまる。 - Z-PentestのTTP（露出HMI・VNC・デフォルト認証・画面録画）は、防御設計で想定する脅威像の一つとして参照できる。 --- 8. 未解明事項・注意点 再検証（2026-11-05）: CERT-FR原文、CISA公式CSAF、Claroty研究、Shodan仕様と保存集計、MITREの技術定義、DDIS発表、英国・EUの備えの案内を照合した。被害・復旧は2.5の取材報道を参照。全出典の全記述を検証済みという意味ではない。EFS声明本文、BBC経由のSekoia発言、Forescout原文、過去の米軍基地事案、機種別EOL日付、X検索原記録は今回直接再確認できておらず、未確認事項として残る。 - 初期アクセス経路はベンダ・保守業者の説明のみで、公的確定なし。CERT-FR警報はCVEも経路も記載していない。Danfoss／Copeland の既知CVE（3.3）はいずれも本件での悪用未確認。 - 被害店舗数は集計主体により幅がある（自己申告 vs 当局）。 - 一部事業者は「ITインシデント」「技術的問題」と表現し、サイバー攻撃と明示していない。 - 犯行声明の動画・認証情報サンプルは未検証。 - 独自集計（3.4.1）のハニーポット判定はShodanのタグ・ポート分布・AS登録情報に基づく受動的判定で、個々のホストへの接続確認はしていない。証明書からユニーク台数を算出する旧推定は、共有・更新を区別できないため撤回した。 - Danfoss露出機1台にTLS証明書CN「poc-takeover.invalid」が設定されていた。第三者による乗っ取り実証の痕跡の可能性があるが未確認。 - 「72時間備蓄」呼びかけと攻撃を結びつける直接の情報は確認できず、本報告では因果関係を論じない。 --- 9. 出典 公的機関 - CERT-FR, CERTFR-2026-ALE-012 (2026-10-12, 更新10/13・10/16、原文確認済み): cert.cyber.gouv.fr - INCIBE-CERT: incibe.es - Swedish NCSC: ncsc.se - UK Cabinet Office, “Households encouraged to take small, simple steps to stay prepared in an emergency” (2026-10-22): gov.uk - European Commission, “EU Preparedness Union Strategy to prevent and react to emerging threats and crises” (2025-03-26): ec.europa.eu - European Commission, “Commission takes new steps to prepare Europeans for growing crisis risks” (2026-11-03): civil-protection-humanitarian-aid.ec.europa.eu - EU External Action Service, “Stronger EU crisis response: Exercise EU Integrated Resolve 2026” (2026-10-19): eeas.europa.eu - 経済産業省「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン（案）第1版」: meti.go.jp - IPA「産業用制御システム向け侵入検知製品等の導入手引書」: ipa.go.jp X上の動向 - GrokによるXキーワード検索（2026-10-20〜11-04、英語・フランス語・ドイツ語・オランダ語。網羅調査ではなく、反応数は検索時点の参考値） - @EU_Commission, “Prepared citizens. A more resilient Europe.” (2026-11-03): x.com 技術・分析 - The Hacker News (2026-11-03): thehackernews.com - The Hacker News (2026-10): thehackernews.com - Claroty Team82: blog.claroty.com - Infosecurity Magazine (Censys): infosecurity-magazine.com - hard2bit: hard2bit.com - Rocket Boys（日本語、CVE含む）: rocket-boys.co.jp - Cyble (hacktivist ICS 2025): cyble.com - RISI (Denmark attribution): risidata.com - CISA, ICSA-26-057-10（Copeland XWEB and XWEB Pro、23 CVE）: cisa.gov （CSAF原文: github.com/cisagov/CSAF/blob/develop/csaf_files/O… - CISA, ICSA-25-140-03（Danfoss AK-SM 8xxA Series, Update A）: cisa.gov （CSAF原文: github.com/cisagov/CSAF/blob/develop/csaf_files/O… - Danfoss Security Advisories: danfoss.com - Dixell France, Recommandations pour une utilisation sécurisée des superviseurs XWEB v1.0 (2026-10, 未読): dixell.fr - SOCRadar（CVE表・CERT-FR要約）: socradar.io - BleepingComputer (2026-10-12): bleepingcomputer.com - Danfoss, StoreView Web 製品ページ（対応機種 AK-SM 800 G08.045以降／AK-SM 800A）: danfoss.com - Danfoss, AK-SM 800A User Guide SW 5.0.x（内蔵UI＝StoreView Web）: assets.danfoss.com - ipinfo / BigDataCloud, AS329360 iiNet Connect Pty Ltd（ZA, AFRINIC, 102.210.48.0/22）: ipinfo.io - Danfoss, AK-SC 255/355 Phase out（AK-SC 355 EOL 2016-10-31）: files.danfoss.com - 独自集計: Shodan count API、2026-11-05 10:06〜10:48 JST（各回の開始記録）（counts.json〜counts6.json、スクリプト shodan_refrigeration_survey*.py） - 陸上自衛隊教育訓練研究本部、樋口俊作「『指揮の要訣』に見る陸上自衛隊の指揮の出発点－『指揮の要訣』100年を迎えて－」（1968年版『野外令第1部』の引用・解説）: mod.go.jp 報道 - RTL Info（2026-11-02、店主取材・IKEAの商品提供への影響）: rtl.be - RTL Info／Belga（2026-11-03、Delhaizeの営業・供給正常化）: rtl.be - BleepingComputer（2026-11-04、EFS声明引用・製剤保護と事業継続）: bleepingcomputer.com - CNBC (2026-11-02): cnbc.com - ABC News (2026-11-02): abcnews.com - Al Jazeera (2026-11-03): aljazeera.com - BBC via Yahoo (EFS, Sekoia): yahoo.com - franceinfo (EFS): franceinfo.fr - cyberattaque.org (EFS/Coolworld): cyberattaque.org - cyberattaque.org (Z-Pentest claim, Forescout): cyberattaque.org - Cybernews (claim): cybernews.com - dev.ua (claim, deletion): dev.ua - To Vima (France context): tovima.com

Reading CISA's KEV due dates against BOD 26-04's Table 1 in Python On 10 June 2026 CISA stopped giving every entry in its Known Exploited Vulnerabilities (KEV) catalog the same kind of deadline. BOD 26-04, which revoked BOD 22-01 (the directive that created the catalog), sets federal civilian agencies a remediation timeline from four questions. Is the asset publicly exposed? Is the CVE in the KEV? Can an adversary automate every step of the exploit? Does exploitation give partial or total control? The answers come out as 3 days, 3 days plus forensic triage, 14 days, 60 days, or "fix on system upgrade". The KEV JSON still carries one dueDate per CVE, plus a newer forensicTriage field. Three of the four inputs to the table are public: the directive says CISA publishes KEV status, Automatable and Technical Impact for every CVE ID "through services such as the Vulnrichment Program". So I wanted to know two things. Is the catalog's single date just the table read with "publicly exposed: yes"? And can you compute it yourself from public data? Mostly yes. The exceptions are the useful part. Everything below ran on 5 November 2026 against catalog version 2026.11.04 (1,768 entries), with the Python standard library only. Table 1 as data The directive publishes Table 1 only as images. Here it is as a dict, in the directive's row order: import collections, json, pathlib, time, urllib.error, urllib.request from datetime import date # BOD 26-04 Table 1, keyed (publicly exposed, in the KEV, automatable, technical impact) TABLE_1 = { (True, True, True, "total"): "3 days & forensic triage", (True, True, True, "partial"): "3 days", (True, True, False, "total"): "3 days & forensic triage", (True, True, False, "partial"): "14 days", (True, False, True, "total"): "3 days", (True, False, True, "partial"): "14 days", (True, False, False, "total"): "14 days", (True, False, False, "partial"): "60 days", (False, True, True, "total"): "3 days & forensic triage", (False, True, True, "partial"): "14 days", (False, True, False, "total"): "14 days", (False, True, False, "partial"): "14 days", (False, False, True, "total"): "60 days", (False, False, True, "partial"): "60 days", (False, False, False, "total"): "Fix on system upgrade", (False, False, False, "partial"): "Fix on system upgrade", } For anything already in the catalog, "in the KEV" is always yes, so only eight rows matter, four per exposure value. The directive also says the timelines "are dynamic as facts change": take a server off the internet and its row changes. A catalog entry has one date for every agency's every asset, so at best it can match one exposure value. Getting CISA's SSVC values Vulnrichment is a public GitHub repository, cisagov/vulnrichment, holding CVE records with CISA's own Authorized Data Publisher container added. Files sit under the year and a thousands bucket, so CVE-2024-27834 lives at 2024/27xxx/CVE-2024-27834.json. The decision values are in the container whose shortName is CISA-ADP, as a metric of type ssvc whose options are a list of one-key dicts: RAW = "https://raw.githubusercontent.com/cisagov/vulnrichment/develop" CACHE = pathlib.Path("vulnrichment-cache") CACHE.mkdir(exist_ok=True) def record_path(cve_id): _, year, num = cve_id.split("-") return f"{year}/{num[:-3]}xxx/{cve_id}.json" def fetch_record(cve_id, ref="develop"): cached = CACHE / f"{cve_id}.{ref[:12]}.json" if cached.exists(): return json.loads(cached.read_text()) url = f"https://raw.githubusercontent.com/cisagov/vulnrichment/{ref}/{record_path(cve_id)}" try: with urllib.request.urlopen(url, timeout=20) as r: body = r.read() except urllib.error.HTTPError as e: if e.code == 404: return None raise cached.write_bytes(body) time.sleep(0.2) return json.loads(body) def ssvc(record): for adp in record["containers"].get("adp", []): if adp["providerMetadata"].get("shortName") != "CISA-ADP": continue for metric in adp.get("metrics", []): other = metric.get("other", {}) if other.get("type") == "ssvc": opts = {} for option in other["content"]["options"]: opts.update(option) opts["timestamp"] = other["content"]["timestamp"] return opts return None For CVE-2024-27834, an Apple entry added to the catalog on 4 November, that returns Exploitation active, Automatable no, Technical Impact partial, with a timestamp of 2026-11-04T20:14:40Z. Comparing every entry added since 10 June Download the catalog first: curl -sS -A "Mozilla/5.0" -o kev.json \ https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json Then read each entry's due date as a gap in days, look up its SSVC values, and ask Table 1 what the "publicly exposed: yes" row says: kev = json.load(open("kev.json")) since = date(2026, 6, 10) groups = collections.Counter() mismatches = [] total = 0 for e in kev["vulnerabilities"]: added = date.fromisoformat(e["dateAdded"]) if added < since: continue total += 1 gap = (date.fromisoformat(e["dueDate"]) - added).days triage = e.get("forensicTriage") opts = ssvc(fetch_record(e["cveID"])) auto, impact = opts["Automatable"] == "yes", opts["Technical Impact"] expected = TABLE_1[(True, True, auto, impact)] ok = gap == int(expected.split()[0]) and triage == ("Yes" if "forensic" in expected else "No") if not ok: mismatches.append(e) groups[(opts["Automatable"], impact, gap, triage)] += 1 print(f"catalog {kev['catalogVersion']}: {total} entries added since {since}") print(f"match the publicly-exposed row: {total - len(mismatches)}, mismatch: {len(mismatches)}") for (auto, impact, gap, triage), n in groups.most_common(): print(f" automatable={auto:<3} impact={impact:<7} catalog: {gap:>2} days, forensicTriage={triage} x{n}") The e.get("forensicTriage") is deliberate. CISA's published schema lists eight required fields per entry, and forensicTriage is not one of them. It describes the field as "'Yes' if this vulnerability requires forensic triage per BOD 26-04". Every entry in the 4 November file has it (1,671 No, 97 Yes), but a parser that indexes it directly is relying on something the schema does not promise. The output: catalog 2026.11.04: 151 entries added since 2026-06-10 match the publicly-exposed row: 114, mismatch: 37 automatable=no impact=total catalog: 14 days, forensicTriage=No x17 automatable=yes impact=total catalog: 3 days, forensicTriage=No x11 automatable=yes impact=partial catalog: 14 days, forensicTriage=No x6 automatable=no impact=total catalog: 3 days, forensicTriage=No x2 automatable=yes impact=partial catalog: 3 days, forensicTriage=Yes x1 114 of 151 is a strong majority. The 37 fall into three shapes and one stray. Seventeen entries are not automatable with total control, and the catalog gives 14 days. The exposed row for that pair says 3 days and forensic triage. Fourteen days is what the table gives the not publicly exposed row. But 37 other entries with the same SSVC pair got 3 days and triage, so no single exposure assumption explains the catalog. Six entries are automatable with partial control, and the catalog gives 14 days. Again the not-exposed row, where the exposed row says 3 days. Thirteen entries have the right 3 days but forensicTriage set to No while SSVC says total control. Eleven of those thirteen were added in June. The first Yes anywhere in the catalog is on an entry added 25 June, so the early June entries may predate CISA using the field. That is an inference from the dates; I found nothing that says so. One entry is automatable with partial control and has forensic triage set to Yes. Its 3 days are right; the table asks for triage only with total control. The values move after the entry is added Thirteen of the 37 mismatches have an SSVC timestamp later than the KEV dateAdded, which means CISA edited the decision after the entry went in. The repository's git history shows what the values were on the day. GitHub's REST API allows 60 unauthenticated requests an hour, enough for thirteen files: def ssvc_history(cve_id): url = ("https://api.github.com/repos/cisagov/vulnrichment/commits" f"?path={record_path(cve_id)}&per_page=100") req = urllib.request.Request(url, headers={"User-Agent": "kev-check"}) with urllib.request.urlopen(req, timeout=20) as r: commits = json.load(r) for c in reversed(commits): opts = ssvc(fetch_record(cve_id, ref=c["sha"])) yield c["commit"]["committer"]["date"][:16], opts["Automatable"], opts["Technical Impact"] prev = None for when, auto, impact in ssvc_history("CVE-2015-5477"): if (auto, impact) != prev: print(when, auto, impact) prev = (auto, impact) 2026-10-08T18:17 yes partial 2026-11-04T00:17 yes total CVE-2015-5477 is an ISC BIND bug from 2015 that CISA added on 8 October with a 3-day due date and no forensic triage. On 8 October its record said automatable, partial control: row 2, 3 days, no triage. The catalog was right on the day. On 4 November the technical impact became total, and today's Table 1 answer for it would add forensic triage. The catalog published later that day still says No. Two more mismatches clear up the same way: CVE-2015-3246 and CVE-2026-48710 were both "not automatable, partial" when added (row 4, 14 days, which is what the catalog says) and were re-rated later. Five of the thirteen histories have a change committed on 1 October, which looks like a batch re-assessment. The other ten still do not match even with the values from the day. CVE-2026-42018, for example, was automatable with partial control when added and got 14 days, where the exposed row says 3. So, as far as public data lets me check: the catalog's dueDate usually equals Table 1 read as "publicly exposed: yes", it is fixed when the entry is added, and Vulnrichment keeps moving afterwards. For a minority of entries the date encodes something I cannot reproduce from public data. I am not calling those errors. CISA may weigh things that never reach Vulnrichment, and I compared against the values I could see. Computing your own deadline instead The directive binds federal civilian agencies only. For everyone else the KEV date is a signal. If you patch anything, Table 1 is still a decent triage rule because it asks about your asset, which the catalog cannot know. This is the function I would keep: def timeline(cve_id, publicly_exposed, in_kev=True): opts = ssvc(fetch_record(cve_id)) if opts is None: return "no CISA SSVC record yet" key = (publicly_exposed, in_kev, opts["Automatable"] == "yes", opts["Technical Impact"]) return TABLE_1[key] for exposed in (True, False): print("CVE-2026-34486", "exposed" if exposed else "internal", "->", timeline("CVE-2026-34486", exposed)) CVE-2026-34486 exposed -> 3 days CVE-2026-34486 internal -> 14 days CVE-2026-34486 is an Apache Tomcat entry added on 4 August. The catalog gives it one date, 3 days, which is the right answer for a Tomcat that faces the internet and 11 days earlier than the table asks for one that does not. In a real inventory, in_kev should come from the catalog file rather than a default, and the result should be recomputed whenever the SSVC timestamp changes. What this does not show - I compared against Vulnrichment values as of 5 November, plus git history for thirteen files. I did not trace the history of the other 138. - The catalog's dueDate is one date per CVE. The directive's deadline depends on each asset's exposure and starts at whichever comes first, the KEV addition or the agency finding the bug on its own asset. - KEV inclusion means CISA has evidence of exploitation. The entries give no date or victim for it, and nothing here says which bugs are being exploited this week. - Table 1 came from the image on the directive page, typed in by hand. Check the dict against the image before you rely on it. Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

Your Microsoft 365 subscription is current. Are your security settings? CISA’s ScubaGear helps assess configurations against its security baselines. Ask your IT team: When was our last check, what changed, and who owns the gaps? github.com/cisagov/ScubaGear/releases/tag/v2.0.0 t.co

Cisco ASA/FTD CVE-2026-76418: Actively Exploited SSL VPN DoS with Secondary Authentication 1. Basic Information - Advisory: Cisco Secure Firewall Adaptive Security Appliance and Secure Firewall Threat Defense Software Remote Access SSL VPN Tunnel Denial of Service Vulnerability - Publisher: Cisco - Published: 2026-10-28T19:15:00Z - Source: Cisco - Related Sources: BleepingComputer - Related Sources: SecurityWeek - Related Sources: CISA KEV catalog data - Associated Malware: None specified - Associated Threat Groups: None specified - Associated CVEs: CVE-2026-76418 - Affected Products: Cisco ASA, Cisco FTD, SSL VPN/WebVPN - Severity: high 2. Executive Summary Cisco has confirmed active exploitation of CVE-2026-76418, a vulnerability where crafted requests to SSL VPN tunnel groups using secondary authentication cause ASA and FTD devices to reload, and has released fixed software. The issue warrants high priority because unauthenticated attackers can disrupt firewall and VPN availability, exploitation has been confirmed, and no complete workaround is available. 3. Attack Flow Attack Flow 1. An unauthenticated attacker sends a crafted request to an SSL VPN login endpoint meeting the affected conditions. 2. A logic error in secondary authentication processing leads to a null pointer dereference, causing the device to reload and resulting in a denial of service. A successful VPN login is not required. 4. Attacker Position and Execution Location - An unauthenticated attacker with network access to the SSL VPN interface. 5. Victim and Administrator Perspective Victim - Observed as a sudden disconnection from the VPN. Administrator - Observed through reloads, crash info logs, and availability alerts. 6. Conditions for Success and Failure Conditions for Success - Exploitation requires a vulnerable ASA or FTD release, a reachable SSL VPN login service, SSL VPN enabled on at least one webvpn interface, and secondary authentication in an applicable tunnel group. If tunnel-group-list enable is configured, administrators must check all tunnel groups, including DefaultWEBVPNGroup; the device is affected if any applicable group uses secondary authentication. If the group list is disabled, the device remains affected when DefaultWEBVPNGroup uses secondary authentication. Conditions for Failure and Mitigations - Update to the fixed release for the applicable version series. For example, the first fixed releases are ASA 9.20.4.50 for the ASA 9.20 series and FTD 7.4.9 for the FTD 7.4 series. Verify other series using Cisco advisories and the Software Checker. - There is no complete workaround; updating is required. If secondary authentication is not used on DefaultWEBVPNGroup, disabling tunnel-group-list enable serves as a temporary mitigation. Removing secondary authentication when it is used on DefaultWEBVPNGroup lowers authentication strength, so an impact assessment is required. 7. Impact of Successful Exploitation - Degradation of firewall and VPN availability. 8. Observable Logs Inference: The following are candidate logs to investigate within your organization. Availability depends on log collection, retention settings, and product visibility, and does not imply that all items were recorded in primary sources. - Email: None available - Proxy / SWG / DNS: None available - Endpoint / EDR: Collect device-side crash information, reload reasons, and webvpn configurations. General EDR platforms may not capture these items. - Identity / IdP: None available - SaaS / Cloud: None available - Network: Review SSL VPN requests immediately preceding the reload. 9. Attack Success Determination Inference: The following is an internal determination criterion and does not imply that primary sources observed all stages of success. - Attack Attempt Observed (Success Unconfirmed): Criteria: Even if the arrival of a crafted request is confirmed, the occurrence of a reload or denial of service must be verified separately. Denial of service affects availability and does not constitute follow-on compromise. Target: VPN 10. Investigation Playbook Inference: Internal investigation procedure. - Trigger: Unexpected reload, crash info logs - Initial Checks: Verify target product version, exposure scope, time synchronization, and log retention. - Endpoint: Preserve target device configurations, processes, files, and reboot history. - Identity and Cloud: Verify administrator authentication and API operations. - Follow-on Activity: Track subsequent internal connections, credential usage, configuration changes, and outbound traffic. - Containment: Assess availability and business impact, then restrict access, apply fixed versions, and perform recovery. Do not treat denial of service alone as evidence of credential theft; if separate evidence of compromise exists, investigate and respond to that evidence. - Assessment Categories: Distinguish request receipt from a confirmed denial-of-service outcome, and cross-reference configurations, request timestamps, crash information, and reload reasons. Do not conclude exploitation from a reload alone; consult Cisco TAC if necessary. 11. Defense and Detection Ideas - Single Events: Detect crash signatures immediately following SSL VPN requests. - Timeline Correlation: Correlate request bursts with availability loss. - Hunting: Inventory tunnel groups utilizing secondary authentication. - Logging Gaps: Encrypted request contents may not be visible. - Priority Controls: Prioritize patching, high availability setups, and VPN exposure inventories. 12. Facts, Inferences, and Hypotheses Facts - Cisco describes the issue as a logic error in secondary authentication handling, classified as CWE-690 with a CVSS v3.1 score of 8.6. CISA KEV data notes it as a null pointer dereference resulting from an unchecked return value. - Unauthenticated attackers can trigger device reloads without requiring successful VPN logins. - Exploitation requires a vulnerable ASA or FTD release, a reachable SSL VPN login service, SSL VPN enabled on at least one webvpn interface, and secondary authentication in an applicable tunnel group. If tunnel-group-list enable is configured, administrators must check all tunnel groups, including DefaultWEBVPNGroup; the device is affected if any applicable group uses secondary authentication. If the group list is disabled, the device remains affected when DefaultWEBVPNGroup uses secondary authentication. - Cisco acknowledged active exploitation in October 2026, but threat actors, targets, incident counts, and IOCs have not been publicly disclosed. - There is no complete workaround; updating is required. If secondary authentication is not used on DefaultWEBVPNGroup, disabling tunnel-group-list enable serves as a temporary mitigation. Removing secondary authentication when it is used on DefaultWEBVPNGroup lowers authentication strength, so an impact assessment is required. - CISA added CVE-2026-76418 to the KEV catalog on October 29, 2026, confirming active exploitation of this denial-of-service vulnerability, which does not indicate remote code execution or credential theft. Inference - Inference: Do not assume reloads are attacks without verifying preceding requests and crash information. Hypothesis No additional hypotheses. Unconfirmed items are noted in Unknowns and Limitations. 13. MITRE ATT&CK Mapping | ID | Technique | Confidence | Basis | |---|---|---|---| | T1499.004 | Application or System Exploitation | high | Device reload and service disruption caused by crafted requests. Code execution has not been confirmed. | 14. Unknowns and Limitations - Threat actors, targets, incident counts, and request IOCs are unknown. 15. Impact on SOCs and Organizations Inventory SSL VPN implementations using secondary authentication and update them to fixed releases. 16. Summary by Role - SOC: Correlate requests immediately preceding reloads with crash information. - Administrators: Verify webvpn configurations and apply updates. - Users: Follow alternative access procedures during VPN outages.

WordPressの脆弱性「wp2shell」を狙った攻撃の観測 1. はじめに 三菱電機の木原です。 三菱電機　情報技術総合研究所では、製品開発時のセキュリティ対策にフィードバックする目的で、複数種類のハニーポットを設置・運用しています。 今回はIoT家電を標的としたサイバー攻撃を観測するハニーポット「IoT家電ハニーポット」で観測した中で、2026年7月に公表された深刻度の高いWordPress[1]の脆弱性「wp2shell」を標的としたとみられるパケットに着目した分析結果をご紹介します。 2. wp2shellとは wp2shellは、2026年7月に公表されたWordPressコアの2つの脆弱性（CVE-2026-63030[2]：CVSS v3.1スコア9.8、CVE-2026-60137[3]：CVSS v3.1スコア5.9-いずれもWPScanによる評価）を組み合わせた攻撃チェーンで、認証なしの状態からリモートコード実行に至る可能性がある、深刻度の高いものです。 さらに、WordPressのプラグインではなく、本体（コア）の脆弱性であることから、影響範囲も広いと考えられます。 CVE-2026-63030は、WordPressに実装されている、複数のREST APIリクエストを1つのHTTPリクエストで処理できるBatch API（/batch/v1）の脆弱性です。この脆弱性を悪用すると、Batch APIで処理の宛先の取り違え（ルート混同）が起き、本来適用されるべきパラメータのサニタイズを回避できてしまいます。 CVE-2026-60137は、WP_Queryのauthor__not_inパラメータのサニタイズが適切でないことによる、SQLインジェクションの脆弱性です。ただし、通常はREST API側で入力がサニタイズされるため、標準構成のWordPressコア単体では悪用されにくいものです。 この2つを組み合わせると、CVE-2026-63030でサニタイズを回避した入力がCVE-2026-60137のSQLインジェクション脆弱性の悪用に使われ、結果として認証なしでリモートコード実行に至る可能性が指摘されています[2][4]。 続いて、wp2shellに関連するニュースの時系列を以下に示します。 | 日付（日本時間） | 出来事 | | ---------- | ------------------------------------------------------- | | 2026年7月18日 | WordPressによる修正版のリリース[5] | | 2026年7月18日 | CVE（CVE-2026-63030[2]、CVE-2026-60137[3]）が公開（NVDに掲載） | | 2026年7月19日 | PoCの公開が報じられる[4][6] | | 2026年7月22日 | CISAのKEV（Known Exploited Vulnerabilities）カタログに掲載[7][8] | | 2026年7月22日 | IPAが注意喚起[9] | | 2026年7月23日 | JPCERT/CC WeeklyReport掲載[10] | ※日付は全て日本時間に換算しています。 日本時間2026年7月18日（米国時間7月17日）に本脆弱性は明らかになり、CVE情報の公開（NVD掲載）とWordPressによる修正バージョンの公開が行われました。影響を受けるバージョンと修正後のバージョンは以下のとおりです[2][3][5]。 | 系列 | 影響を受けるバージョン | 影響を受ける脆弱性 | 修正後のバージョン | | ---- | ----------- | ----------------------------- | --------- | | 7.0系 | 7.0.0～7.0.1 | CVE-2026-63030、CVE-2026-60137 | 7.0.2 | | 6.9系 | 6.9.0～6.9.4 | CVE-2026-63030、CVE-2026-60137 | 6.9.5 | | 6.8系 | 6.8.0～6.8.5 | CVE-2026-60137のみ | 6.8.6 | 6.8系はCVE-2026-63030の影響を受けないため、2つを組み合わせた攻撃チェーン（wp2shell）が成立するのは6.9系と7.0系です。なお、6.8より前のバージョンはどちらの脆弱性の影響も受けません[5]。 公表翌日の7月19日にはPoCの公開が報じられ、さらに3日後の22日には積極的に悪用されている脆弱性として、KEVカタログにも掲載されました。 同じく22日にはIPAが注意喚起を行い[9]、23日にはJPCERT/CCのWeeklyReportでも取り上げられています[10]。 3. 観測結果概要 続いて、当社が運営しているハニーポットで観測された、wp2shellを狙ったと思われるパケットの観測結果をご紹介します。なお、当社のIoT家電ハニーポットでは、WordPressは稼働していません。 観測期間は脆弱性が公表された2026年7月18日0時0分から9月30日23時59分までの75日間です（全て日本時間）。本期間で観測したパケットのうち、HTTPのPOSTリクエストにbatch/v1、batch%2Fv1（スラッシュをURLエンコードしたバージョン）、Batch/v1（Bが大文字のバージョン）、Batch%2Fv1（大文字＆エンコード有）の4種類いずれかの文字列が含まれているパケットの総数は119件でした。なお、本記事では、HTTPリクエスト1件を1パケットとして数えています。 これら119件について、観測件数の推移を以下の図に示します。 !Pasted image 20261028153921.png 上図より、7月21日に最初のパケットが観測されていることがわかります。パケットを受信した正確な時刻は7月21日21時4分であり、これは、wp2shellがKEVに掲載された時刻（KEVカタログデータの更新時刻[8]より、日本時間7月22日0時12分）の約3時間前にあたります。 また、8月22日に、119件中78件のパケットが集中していました。さらに、9月25日・28日にも再び観測されています。 続いて、パケットの内容を分析した結果を下表に示します。 | 日付 | 件数 | 送信元の国 | 送信元IPの種類 | パターン | | ---- | --- | ------ | -------- | ------------ | | 7/21 | 1 | シンガポール | ホスティング | ① 同一リクエストの観測 | | 8/9 | 1 | ブルガリア | ホスティング | ① 同一リクエストの観測 | | 8/18 | 1 | 中国 | ホスティング | 中身が空のリクエスト | | 8/20 | 1 | ブルガリア | ホスティング | ① 同一リクエストの観測 | | 8/22 | 78 | アメリカ | ホスティング | ② 自動化ツール | | 8/30 | 2 | ブルガリア | ホスティング | ① 同一リクエストの観測 | | 9/25 | 14 | ブルガリア | ホスティング | ② 自動化ツール | | 9/28 | 21 | オランダ | ホスティング | ② 自動化ツール | HTTPリクエストの内容を確認すると、7月21日・8月9日・20日・30日に観測されたパケットは、リクエストのURLとボディが同一でした。そのため、パターン①と置きます。 また、8月22日の78件は送信元IPアドレスが全て同一であり、リクエストの挙動から①とは異なるパターンと考えました。9月25日・28日の計35件は、送信元IPアドレスこそ8月22日と異なるものの、リクエストの内容が8月22日のものと類似していました。そのため、これらをまとめてパターン②と置きます。 8月18日に観測された1件のパケットは、/?rest_route=/batch/v1宛てのPOSTリクエストで、User-Agentがwp2shell-rce/1.0と、wp2shellを悪用するRCE用ツールであると名乗るものでした。ただし、リクエストのボディは空のJSONで、パターン①・②のいずれにも該当しなかったため、本記事では詳しい分析を割愛いたします。 :::note warn なお、今回観測した通信には、実際の悪用（リモートコード実行）につながるペイロードは含まれておらず、研究者やセキュリティベンダーによる脆弱性確認のスキャンが含まれている可能性があります。実際に、wp2shellを狙ったスキャンの中に、正当なセキュリティスキャンが含まれていたという報告もあります[11]。 ::: ここからは、パターン①・②について、さらに掘り下げていきます。 4. パターン①：同一リクエストの観測 パターン①に該当するのは、7月21日・8月9日・20日・30日に観測された計5件のパケットです。これら5件は全て、/batch/v1宛てに送られていました。 POST /index.php?rest_route=/batch/v1 HTTP/1.1 リクエストのボディも5件全てで同一で、以下の内容でした（読みやすくするため整形しています）。 { "requests": [ { "method": "POST", "path": "http:///x" }, { "body": { "requests": [ { "method": "GET", "path": "/wp/v2/posts" } ] }, "method": "POST", "path": "/wp/v2/posts/1" }, { "method": "POST", "path": "/batch/v1" } ] } このリクエストは、Batch APIのリクエストの中にさらに別のリクエストを入れ子にしたものです。1つ目の脆弱性であるCVE-2026-63030を悪用して、本来行われるはずの入力の検証（サニタイズ）を回避することを狙ったものとみられます。 入れ子の中身は投稿一覧の取得（GET /wp/v2/posts）という、通常は認証なしでも行える無害なリクエストです。また、GETリクエストはBatch APIでは指定できない仕様になっています[12]。以上より、このリクエストは、情報を盗むことが目的ではなく、本来は受け付けられないはずのGETが処理されるかどうか、つまり脆弱性の有無を確認するためのリクエストと考えられます。 また、8月9日に観測された1件のパケットでは、User-AgentがMozilla/5.0 (compatible; checker) wp2shell/CVE-2026-63030となっており、wp2shell（CVE-2026-63030）の確認用ツール（checker）を名乗る文字列が含まれていました。このことからも、パターン①はwp2shellの脆弱性の有無を確認するためのリクエストであると考えられます。 さらに、5件のパケットのうち8月9日・20日・30日に観測された4件は、IPv4アドレスの上位24ビットが同一で、国情報も全てブルガリアのため、同一の送信者が数日に分けてパケットを送信してきた可能性があります（ただし、ホスティング事業者などでは同じ/24のアドレス帯が複数の利用者に割り当てられている場合もあるため、断定はできません）。 5. パターン②：自動化ツールによる攻撃 パターン②に該当するのは、8月22日・9月25日・28日に観測された計113件のパケットです。送信元IPアドレスは日ごとに異なりますが、いずれもホスティングサービスのIPでした。 まずは、最も多くのリクエストが観測された8月22日の攻撃について、詳しく見ていきます。 8月22日の攻撃について、同じ送信元からの通信をパケットキャプチャで前後も含めて確認したところ、HTTPリクエストは計86件（POST 78件、GET 8件）あり、約30秒の間に次の3つのフェーズで進んでいました。 | フェーズ | 経過時間 | リクエスト数 | 内容 | | ---- | ------ | -------- | ------------------ | | 1 | 0～27秒 | POST 78件 | 入口（/batch/v1）の探索 | | 2 | 27～29秒 | GET 6件 | WordPressかどうかの確認 | | 3 | 29秒 | GET 2件 | SQLインジェクションが通るかの確認 | !Pasted image 20261028133102.png 攻撃自動化ツールの可能性 8月22日の攻撃は、上の表から読み取れる以下の2点から、人の手作業ではなく自動化されたツールによるものと考えられます。 - リクエストの速さ：86件のリクエストが約30秒の間に送られていました。特にフェーズ1では、78件のPOSTを約27秒で送っています。 - フェーズ間の切り替えが速い：フェーズ1からフェーズ3までが途切れることなく続き、フェーズ2・3は合計約2～3秒で終わっていました。人が応答を見て次の手を判断している場合では、さらに時間がかかるはずです。 ここから、各フェーズの詳細な内容をご紹介します。 フェーズ1：入口（/batch/v1）の探索 最初のフェーズでは、/batch/v1へのPOSTリクエストを、URLの書き方を変えながら繰り返し送っていました。使われていた書き方は以下の11種類です。 | No. | URL | 書き方の特徴 | POST件数 | | --- | ------------------------------------- | ------------------------------------- | ------ | | 1 | /index.php?rest_route=/batch/v1 | rest_routeを使う形（index.phpあり） | 7 | | 2 | /index.php?rest_route=%2Fbatch%2Fv1 | No.1のスラッシュを%2Fにエンコード | 7 | | 3 | /?rest_route=%2Fbatch%2Fv1 | rest_routeを使う形（index.phpなし）＋エンコード | 7 | | 4 | /?rest_route=/batch%2Fv1 | 一部のスラッシュだけをエンコード | 7 | | 5 | /?rest_route=/batch/v1 | rest_routeを使う形（index.phpなし） | 8 | | 6 | /wp-json/batch/v1 | wp-jsonを使う形（標準のURL） | 7 | | 7 | /wp-json/Batch/v1 | 大文字・小文字の違い | 7 | | 8 | //wp-json/batch/v1 | スラッシュの重複 | 7 | | 9 | /wp-json/batch/v1/ | 末尾のスラッシュ | 7 | | 10 | /blog/wp-json/batch/v1 | /blog/配下に設置されている場合 | 7 | | 11 | /wordpress/wp-json/batch/v1 | /wordpress/配下に設置されている場合 | 7 | | | 合計 | | 78 | 最初に/?rest_route=/batch/v1を1回送ったあと、この11種類を同じ順番で7周（計77件）、約0.3秒間隔で送っていました。 WordPressのREST APIは/wp-json/～と?rest_route=～のどちらかをURLに指定することで利用できますが、/wp-json/～はパーマリンクが無効なサイトでは使えません[13]。そのため、設定に依存しない?rest_route=～の形もあわせて試していると考えられます。また、WordPressはサブディレクトリに設置されることもあるため[14]、/blog/や/wordpress/配下のURL（No.10、11）も試していると考えられます。 一方、エンコード（No.2〜4）、大文字・小文字の違い（No.7）、スラッシュの重複（No.8）、末尾のスラッシュ（No.9）のようなURLのバリエーションは、文字列の一致でブロックするWAFの検知をすり抜けるためと考えられます。実際にwp2shellについては、すぐにアップデートできない場合の暫定策として、/wp-json/batch/v1と?rest_route=/batch/v1をWAFでブロックする方法が紹介されています[6]。 また、リクエストのボディは全て{"requests":[]}という、中身が空のバッチリクエストでした。つまり、このフェーズではまだ攻撃は行っておらず、「入口があるかどうか」を応答から確認しているだけとみられます。 さらに、User-Agentは最初の6周がWebブラウザ（Chrome 120）を装ったもので、最後の1周だけWordPress/6.4.3に変わっていました。User-Agentを変えることで、応答が変わるかを確かめていた可能性があります。 フェーズ2：WordPressかどうかの確認 入口の探索が終わると、次はGETリクエストで以下のURLにアクセスしていました。 | No. | URL | アクセス先 | | --- | --------------------- | ------------- | | 1 | /wp/v2/posts/999999 | REST APIの投稿取得 | | 2 | /wp-login.php | ログイン画面 | | 3 | /feed/ | フィード | | 4 | /wp-json/ | REST APIのトップ | | 5 | / | トップページ | | 6 | /index.asp | 5のリダイレクト先 | ログイン画面やREST APIのトップ、フィードなど、WordPress独自のURLにアクセスし、対象が本当にWordPressであるか、REST APIに到達できるかを確認していると考えられます。 ただし、No.1の/wp/v2/posts/999999は、本来のREST APIのURL（/wp-json/wp/v2/posts/<id>[15]）とは異なり、先頭の部分が欠けていました。そのため、このリクエストは不完全であり、実際は通りません。 考えられる原因として、フェーズ1でハニーポットがBatch APIへのリクエスト11種類全てに401 Unauthorizedを返したことで、ツールがREST APIの入口を特定できず、不完全なURLのままフェーズ2に進んだ可能性があります。 なお、No.6の/index.aspは、ハニーポットがNo.5のトップページへのアクセスにリダイレクトを返したため、そのリダイレクト先にアクセスしたものとみられます。WordPressを狙ったURLではありません。 フェーズ3：SQLインジェクションが通るかの確認 最後のフェーズでは、CVE-2026-60137のSQLインジェクションが通るかを確認しようとしたとみられるリクエストを2件送っていました。 1件目は、投稿ID（999999）を指定したURLに、author_exclude・orderby・per_pageの3つのパラメータを付けたリクエストです。 GET /wp/v2/posts/999999?author_exclude=1&orderby=none&per_page=5 author_excludeは「指定した投稿者の投稿を除外する」ためのREST APIのパラメータで[15]、投稿一覧の取得（/wp-json/wp/v2/posts）で指定した場合に、WordPressの内部でCVE-2026-60137の脆弱性があるWP_Queryのauthor__not_inに渡されます。この1件目は、2件目の応答と比べるための基準となる、無害なリクエストと考えられます。 2件目は、同じauthor_excludeパラメータにSQL文を埋め込んだリクエストです。悪用を避けるため、SQL文の部分は省略して示します。 GET /wp/v2/posts/999999?author_exclude=1)［SQL文（省略）］&orderby=none&per_page=500 リクエストの詳細に関しては安全のため割愛しますが、1件目の応答を基準として、2件目の応答に違いが現れるかどうかで、SQLインジェクションが通るかどうかを確認しようとしているとみられます。 しかし、フェーズ3のリクエストは、通常のREST APIの処理では意図どおりに動きません。author_exclude・orderby・per_pageは投稿一覧の取得（/wp-json/wp/v2/posts）用のパラメータで[15]、投稿1件の取得用のURL（/posts/<id>）では使われません。また、投稿一覧の取得に送った場合でも、orderby=noneやper_page=500はREST APIの入力検証で拒否されます。 これらの値は、入力検証を経ずにWP_Queryへ直接渡れば受け付けられるものです。つまりフェーズ3は、CVE-2026-63030で入力検証を回避することを前提とした作りと考えられます。しかし、実際にはBatch APIを経由せずに直接送られていたため、脆弱なバージョンのWordPressに送られた場合でも、SQLインジェクションは成立しないと考えられます。このように、2章で示した攻撃チェーンの形になっていないことから、ツールの実装が不完全である可能性があります。 9月25日・28日の攻撃 9月25日・28日にも、8月22日と同じツールによるものとみられる通信を観測しました。送信元IPアドレスと国情報は8月22日とは異なりますが、以下の点が8月22日と一致していました。 - フェーズ1で試すURLの種類と、送る順番 - リクエストのボディ（{"requests":[]}）とUser-Agent 一方で、どちらの日も/batch/v1へのリクエストはフェーズ1の2周目の途中（9月25日は14件、28日は21件）で終わっており、フェーズ2・3のリクエストは観測されませんでした。 どちらの日も、送信件数は14件・21件と異なるものの（ネットワーク応答速度の違いが原因として考えられます）、最初のリクエストから約29秒で送信が止まっていました。また、8月22日の攻撃も約30秒で終了しています。件数ではなく時間で打ち切られていることから、ツールの処理全体に約30秒の時間制限がある可能性があり、9月25日・28日の攻撃はフェーズ1の途中で時間切れとなり、フェーズ2・3に進まなかったと推測されます。 6. まとめ 今回は、当社のハニーポットで観測された、wp2shellを狙ったと思われる通信について、分析結果をご紹介しました。 今回の観測で興味深かった点として、CVEの公表から4日足らずで、KEVへの掲載よりも前に、当社のハニーポットでもwp2shellを狙ったとみられる通信が観測されたこと、また攻撃の自動化が行われているとみられる点が挙げられます。さらに、WordPressが動作していない当社のIoT家電ハニーポットにもパケットが届いていることから、広範囲にスキャンを行いターゲットを探索している様子もうかがえます。 このように、CVE公表からスキャン観測までの期間は短く、また広範囲なターゲット探索がみられることから、脆弱性に対する迅速な対応や、APIエンドポイントのセキュリティ対策がより重要になってくると思われます。 当社では、引き続きハニーポットを用いた観測を行い、こちらで観測・分析結果をご紹介する予定です。 ご質問やコメントもお待ちしております。 参考文献 [1] WordPress.org, wordpress.org [2] NVD, "CVE-2026-63030 Detail", 2026年7月17日（現地時間）, nvd.nist.gov [3] NVD, "CVE-2026-60137 Detail", 2026年7月17日（現地時間）, nvd.nist.gov [4] セキュリティ対策Lab, 「WordPress 本体で危険度の高い脆弱性 wp2shell-サイバー攻撃への悪用が発生(CVE-2026-63030,CVE-2026-60137)」, 2026年7月19日, rocket-boys.co.jp [5] WordPress.org, "WordPress 7.0.2 リリース", 2026年7月18日, ja.wordpress.org [6] BleepingComputer, "WordPress Core "wp2shell" RCE flaws get public exploits, patch now", 2026年7月18日（現地時間）, bleepingcomputer.com [7] CISA, "CISA Adds Four Known Exploited Vulnerabilities to Catalog", 2026年7月21日（現地時間）, cisa.gov [8] CISA, "Known Exploited Vulnerabilities Catalog"（catalogVersion 2026.07.21）, cisagov/kev-data, github.com/cisagov/kev-data/blob/bc9dbb256ec16f37… [9] IPA, 「WordPressの脆弱性対策について(CVE-2026-60137、CVE-2026-63030：wp2shell)」, 2026年7月22日, ipa.go.jp [10] JPCERT/CC, 「Weekly Report 2026-07-23号」, 2026年7月23日, jpcert.or.jp [11] Wiz, "Exploitation in the Wild of wp2shell", 2026年7月20日, wiz.io [12] Make WordPress Core, "REST API Batch Framework in WordPress 5.6", 2020年11月20日, make.wordpress.org [13] WordPress Developer Resources, "Routes and Endpoints", developer.wordpress.org [14] WordPress Developer Resources, "How to install WordPress", developer.wordpress.org [15] WordPress Developer Resources, "Posts", developer.wordpress.org

CISA's ScubaGear v2.0 now says risky AI agents shall be blocked, and that control needs Entra P2 plus Agent 365 or M365 E7. Small business tenants get agents long before they get that license, so what are you doing in tenants that will never buy E7? github.com/cisagov/ScubaGear/releases/tag/v2.0.0

La Cybersecurity and Infrastructure Security Agency (CISA), añadió el 26 de octubre de 2026 tanto CVE-2026-109618 como CVE-2026-109619 (PHP2Shell), a su catálogo oficial Known Exploited Vulnerabilities (KEV). github.com/cisagov/kev-data/blob/develop/known_ex… CISA dice que existen evidencias de explotación real de las dos vulnerabilidades. Esto es nuevo para CVE-2026-109619, porque hasta ahora la evidencia era sólo en cadenas de corrupción de memoria asociadas a CVE-2026-109618. Pero (siempre hay un pero 😆), el catálogo KEV no publica los detalles técnicos que justificaron añadir las dos CVE. Por tanto, no podemos afirmar que exista explotación de ambas CVE contra PHP-FPM. Seguimos esperando alguna prueba de que PHP2Shell se pueda explotar en FPM en producción.

Uppercase the path, skip the auth gate: an unauthenticated nginx bypass in CISA's Malcolm (GHSA-7j32-cf27-cp6h) TL;DR - What: Malcolm — the free network-traffic-analysis suite built by CISA and Idaho National Laboratory — shipped an nginx reverse-proxy config where one route's matcher was case-insensitive but its redirect was case-sensitive. Requesting that route in any non-lowercase casing (/IDDASH2ARK/…) slipped past the redirect and fell through to an unauthenticated proxy_pass, in one of two proxied locations that never got the auth include. - Impact: an unauthenticated network caller reaches the Arkime full-packet-capture backend, and because that same location forwards a client-supplied X-Forwarded-User header un-overwritten — the exact header Arkime is configured to trust as the logged-in user — the caller arrives with a forged, auto-provisioned identity. Rated Moderate 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N). - Fixed in v26.08.0, advisory GHSA-7j32-cf27-cp6h, credited to me as reporter. CVE-2026-107336 lists me as finder. Why you should care Malcolm is a free, full-packet-capture and network-traffic-analysis suite, developed by CISA in collaboration with Idaho National Laboratory for network security monitoring. Its front door is an analyst web UI on 443; behind that sits Arkime, the engine that stores and serves captured sessions and PCAP. For a tool whose entire job is to hold captured network traffic, the auth gate on the front proxy is the security boundary. So when one route quietly falls off that gate, "unauthenticated" doesn't mean a marketing page is exposed — it means an anonymous caller is talking to the packet store. The setup Malcolm's front nginx gates its proxied routes by include-ing a runtime auth file (nginx_auth_rt.conf, which in the shipped default resolves to HTTP basic auth). Most proxied locations include it; two did not. That include does two jobs at once: it demands credentials, and it overwrites X-Forwarded-User with the authenticated user so a client can never forge it. The /iddash2ark/ route is different by design. The "Dashboards → Arkime shortcut" at /iddash2ark/ was only ever meant to hand you a 302 redirect to the real, gated /arkime/sessions?expression=…. It didn't need its own auth, because a redirect leaks nothing. That assumption is where it goes wrong. The bug # nginx/nginx.conf (v26.07.1) location ~* /iddash2ark/(.*) { # ~* = CASE-INSENSITIVE match ... rewrite ^.*/iddash2ark/(.*) $forwarded_scheme://$host/arkime/sessions?expression=($1) redirect; # case-SENSITIVE (no (?i) modifier) proxy_pass $arkime_protocol://arkime; # fall-through target: unauthenticated ... include /etc/nginx/nginx_proxy_forward_headers.conf; # NOT the auth include } Two directives disagree about case. The location ~* matcher is case-insensitive, so /IDDASH2ARK/x enters the block. But the rewrite pattern ^.*/iddash2ark/(.*) has no (?i) modifier, so it is case-sensitive and does not match the uppercase path. No 302 is issued, and nginx falls through to the next thing in the block: a bare proxy_pass to Arkime. This location includes only the header-forwarding file, not the auth file. The request reaches the backend with no credentials checked. (/dashboards/app/extracted-files/ had the same case mismatch and the same missing include; the maintainer fixed both together.) Then the confused deputy. The header file this location does include sets X-Forwarded-For/Host/Proto/... but never touches X-Forwarded-User. On every gated route, the auth include overwrites that header with the authenticated user; here nothing overwrites it, so whatever the client sends survives. And Arkime is configured to trust it: # arkime/etc/config.ini (v26.07.1) userAuthIps=::,0.0.0.0/0 userNameHeader=x-forwarded-user userAutoCreateTmpl={"userId": "${this["x-forwarded-user"]}", ... "enabled": true, ... "webEnabled": true, "headerAuthEnabled": true, ... "packetSearch": true, ...} userNameHeader=x-forwarded-user means Arkime reads the logged-in username straight out of that header; userAuthIps=::,0.0.0.0/0 trusts every IPv4 peer (and nginx is the peer); and the auto-create template provisions that user on the fly with packet search enabled. So the attacker doesn't merely reach the backend unauthenticated — they get to choose who they arrive as. !Diagram: the case-mismatch auth bypass in Malcolm, step by step The "aha" The location matcher was case-insensitive, but the redirect meant to neutralize the request was case-sensitive — so changing one letter to uppercase slipped the request into a route that never had an auth gate, carrying a username the backend had been told to trust. Proof of concept (benign) I didn't need the full suite for this — the bug lives entirely in Malcolm's own nginx config. I stood up a minimal nginx from the verbatim, unmodified shipped config fragments of tag v26.07.1, in front of a tiny stub that just echoes the method, path, and headers it receives (no Arkime logic reimplemented, nothing weaponized). Everything local, synthetic, no live or third-party system touched. The run went over plain HTTP on localhost; this is the recorded output: # [1] positive control: GET /arkime/ (no creds) HTTP/1.1 401 Authorization Required # [2] inverse control: GET /iddash2ark/x (exact lowercase, no creds) HTTP/1.1 302 Moved Temporarily Location: http://127.0.0.1/arkime/sessions?expression=(x) # [3] the bypass: GET /IDDASH2ARK/x (uppercase, no creds, X-Forwarded-User: forged-admin) HTTP/1.1 200 OK ARKIME_STUB_HIT method=GET path=/IDDASH2ARK/x x-forwarded-user='forged-admin' x-forwarded-roles=None authorization=None The last request reached the backend unauthenticated, with the forged header passed through un-overwritten. Mixed case (/IdDaSh2Ark/y) behaves identically, and the raw request URI (path + query) is forwarded verbatim, so the caller controls exactly what Arkime receives. Honest boundary: I confirmed the bypass and the forged, un-overwritten identity reaching the backend. I did not stand up a real Arkime instance to confirm which session/PCAP responses it serves under that prefix. That's why the score sits at Moderate 6.5 (C:L) and not higher — the foothold is proven, the depth of the data read isn't, and I'd rather under-claim than over-claim. (Before the PoC I had it at 7.5, assuming a full data read. I filed it at 6.5 because that read wasn't confirmed.) The fix Shipped in v26.08.0 (2026-08-25), tracked in cisagov/Malcolm#1081. The maintainer's fix does three things. It makes the rewrite case-insensitive with the inline (?i) modifier, so the matcher and the rewrite agree. It deletes the dead proxy_pass and its forwarding headers, so the location can only ever redirect and nothing reaches Arkime through it. And it adds the auth include as a backstop. The location as shipped in v26.08.0: location ~* /iddash2ark/(.*) { include /etc/nginx/nginx_auth_rt.conf; set $forwarded_scheme $scheme; if ($http_x_forwarded_proto = 'https') { set $forwarded_scheme https; } rewrite (?i)^.*/iddash2ark/(.*) $forwarded_scheme://$host/arkime/sessions?expression=($1) redirect; } The same change went into /dashboards/app/extracted-files/ and into the read-only profile (nginx_readonly.conf), where the /iddash2ark/ block was byte-identical. A week later the maintainer fixed a third location of the same shape, /dashboards/app/netbox/ (#1107). Takeaways 1. A case-insensitive location ~* paired with a case-sensitive rewrite is a bug, not a style choice. If a matcher and the directive meant to act on the match disagree about case, requests can enter the block and skip the action — here, skip the redirect that was the only thing standing between an anonymous caller and an unauthenticated proxy_pass. 2. Per-location auth is a checklist, and checklists have gaps. Here two "harmless redirect" locations also carried a proxy_pass and skipped the include. A redirect-only location shouldn't have a proxy_pass at all, and a default-deny backstop — a server-level auth_request that every location inherits — means one forgotten include isn't a total bypass. 3. Never honor a forwarded identity header on a path that isn't behind the auth that sets it. X-Forwarded-User is only trustworthy if something upstream guarantees it. The moment a route forwards it without overwriting it, it's attacker input — a textbook confused deputy. Disclosure timeline - 2026-08-13 — found during a source review of Malcolm's nginx config. - 2026-08-17 — reproduced locally against the shipped v26.07.1 config. - 2026-08-19 — reported privately via GitHub's private vulnerability reporting. - 2026-08-20 — advisory GHSA-7j32-cf27-cp6h published by the maintainer, crediting me as reporter. - 2026-08-25 — fix released in v26.08.0. - 2026-10-08 — CVE-2026-107336 published. This is distinct from Malcolm's earlier nginx-RBAC advisories about URI normalization and percent-encoding, which have a different root cause. This one is the case-sensitivity mismatch on the /iddash2ark/ location plus an un-overwritten forwarded identity header. Credit / CTA If you run nginx with per-location auth, this is a five-minute grep worth doing today: look for ~* matchers paired with case-sensitive rewrites, and for any proxy_pass location missing your auth include. Two directives that disagree about case are enough to open a door. Reported by me. Comments and corrections welcome. --- Santosh Kumar Puppala — AI/ML Platform Architect and security researcher (multiple CVEs; creator of Norviq). GitHub: @Santoshkumarpuppala

これを機にCISAのSigmaルール提供はじまるのかな？ cisagov/SIGMA_Rules

PHP2Shell Sigma rule from CISA github.com/cisagov/SIGMA_Rules/blob/develop/CISA_…