CVE-2026-74232・74233|Zbtlink 2 種のインプラント確認手順

  • URLをコピーしました!
目次

はじめに

2026 年 8 月上旬、Zbtlink(深圳市智博通電子)製ルーターに ENDLESSDOORS と名付けられたインプラントが組み込まれていた件が公開されました。その調査の延長線上で、2026 年 8 月 27 日に VulnCheck が新たに 2 種のインプラントを公開しています。CVE-2026-74232/SPEAKINGSTONE と CVE-2026-74233/DARKLANTERN の 2 件です。

本記事は前報の続報として、この 2 件に対象を限定します。CVE-2026-66747/ENDLESSDOORS の仕組み、Zbtlink 製品の OEM 供給、日本国内での影響、調達上の注意点については、『中国製ルーターのバックドアと Zbtlink 20 機種の確認手順』で整理していますので、背景を確認したい場合はそちらをご覧ください。

この記事でわかること
  • CVE-2026-74232/SPEAKINGSTONE と CVE-2026-74233/DARKLANTERN の違い
  • 通信方向の違いが影響確認の手順を変える理由
  • CVE ごとの対象機種と、Advisory と CVE Record で異なるバージョン表記の読み方
  • 203 台・392 台という観測値が示していないこと
  • 自組織での確認フロー、IoC、暫定対策と機器交換の判断基準

先に結論を示します。今回の 2 件は通信方向が逆であるため、自組織で確認すべきポイントが異なります。DARKLANTERN はインターネット側から UDP/9992 へ到達できる場合に問題となる待ち受け型で、SPEAKINGSTONE はルーター側から UDP/10000 で外部の C2 サーバーへ接続する外向き通信型です。つまり、NAT やインバウンド遮断で守られている環境でも、SPEAKINGSTONE 側は成立し得ます。

また、執筆時点で今回の 2 件に対応する修正済みファームウェアと、Zbtlink による正式な説明はいずれも確認できていません。パッチ適用を待つ前提ではなく、通信の遮断、隔離、機器交換までを含めた判断が必要になります。

CVE-2026-74232・74233 で確認された 2 種のインプラント

VulnCheck の報告によれば、今回の 2 種は米国の販売業者から購入した Deep Orange 製の 3G/4G/LTE ルーターから見つかっています。同社はこの機器を ZBT-WE826-T2 のホワイトラベル品と特定しており、搭載ファームウェアが 2019 年ビルドで ENDLESSDOORS を含まない一方、別の 2 種のインプラントが動作していたとしています。

2 種はいずれも Nim で実装され、UDP で通信し、inetdetect という接続監視用のバイナリーから起動されると報告されています。前報の ENDLESSDOORS を含めると、Zbtlink 系ファームウェアでは世代の異なる 3 種のインプラントが報告されたことになります。

参考: VulnCheck「Chinese Implants in the Supply Chain」
“This is a surveillance implant with root access to every device it runs on.”
(これは、動作するすべての機器に対して root 権限を持つ監視用インプラントです)
https://www.vulncheck.com/blog/zbt-darklantern-speakingstone

CVE の採番元(CNA)はいずれも VulnCheck で、CVSS v4.0 は 9.3、CVSS v3.1 は 9.8 と評価されています。ベクターは 2 件とも CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N で、ネットワーク経由・権限不要・ユーザー操作不要という点が共通します。一方で CWE は分かれており、CVE-2026-74232 は CWE-506(組み込まれた悪意あるコード)と CWE-300(エンドポイント以外からアクセス可能なチャネル)、CVE-2026-74233 は CWE-321(ハードコードされた暗号鍵の使用)と CWE-78(OS コマンドインジェクション)が割り当てられています。

SPEAKINGSTONE と DARKLANTERN の比較

比較軸CVE-2026-74232CVE-2026-74233
VulnCheck による名称SPEAKINGSTONEDARKLANTERN
プロセス/サービス名yunmgrdinfosrvd
通信方向ルーターから外部への外向き通信インターネット側からの待ち受け
プロトコル/ポートUDP/10000(送信先)UDP/9992(待ち受け)
インターネットからの直接到達性不要必要
認証上の問題暗号化・認証がなく、接続先が正規の C2 かを検証できないハードコードされた値による照合と、全ゼロ MAC による回避
攻撃者が実行できる操作root 権限でのコマンド実行、PPPoE 認証情報の取得、DNS ハイジャックリストの操作、リバース SSH の開閉、バックアップ C2 の変更root 権限でのコマンド実行、機器情報の取得
主な確認方法UDP/10000 の外向き通信と C2 ドメインへの名前解決WAN 側から UDP/9992 への到達性
観測状況シンクホールへ 392 台が接続(2026 年 8 月 21 日時点)インターネット公開 203 台が応答(2026 年 8 月 18〜21 日)
修正状況修正済みファームウェアは示されていない修正済みファームウェアは示されていない
VulnCheck KEV掲載は確認できない掲載

どちらも root 権限での操作につながる点は共通です。危険度そのものを比べるより、自組織の構成でどちらの経路が成立し得るかを先に切り分けると、確認作業を絞り込めます。

外向き通信型の SPEAKINGSTONE(yunmgrd、UDP/10000)

SPEAKINGSTONE は yunmgrd というサービスとして動作し、設定された C2 サーバーへ UDP/10000 でビーコンを送信します。ビーコンには型番、ファームウェアバージョン、MAC アドレス、SSID、LAN 側 IP アドレス、稼働時間などが含まれ、機器の識別情報がまとまって送出されると報告されています。

VulnCheck の解析対象機では、C2 として ac-link[.]com が設定されており、深圳のアリババクラウドのアドレスである 47.107.224[.]89 へ解決されたとされています。同社は、このドメインと IP アドレスが ENDLESSDOORS の調査でも確認されたものと同一である点を指摘しています。

通信設計上の問題として、通信が暗号化されておらず、ルーター側に接続先の正当性を検証する仕組みがないことが挙げられています。VulnCheck は、通信経路上の第三者がこのチャネルを乗っ取り得ると評価しています。解析対象機では外向きメッセージが 1 バイトの XOR で難読化されていたものの、すべての機器で同じ処理が行われるわけではなく、C2 からの受信メッセージは常に平文であるとされています。

プロトコルが対応する操作として、VulnCheck は次を挙げています。

  • root 権限での任意コマンド実行
  • WAN 側 PPPoE のユーザー名とパスワードの取得
  • DNS ハイジャックリストの書き込みと読み出し
  • リバース SSH トンネルの開閉と、使用中のポート番号の取得
  • バックアップ C2 サーバーのアドレス変更
  • 機器情報を含む登録ビーコンの送信

DNS ハイジャックとリバース SSH が含まれる点は、影響確認の範囲を広げます。ルーター配下の端末が意図しない名前解決結果を受け取っていた可能性と、外部から機器へ直接ログインされていた可能性の両方を考える必要があるためです。

待ち受け型の DARKLANTERN(infosrvd、UDP/9992)

DARKLANTERN は infosrvd というサービスとして UDP/9992 で待ち受けます。VulnCheck は、解析対象機の既定のファイアウォール設定で、インターネット上の任意の送信元から UDP/9992 への通信が許可されていたと報告しています。出荷時設定のまま WAN 側へ接続すると、この待ち受けポートが外部から到達可能になります。

扱われるパケットは 2 種類とされています。情報取得用のプローブに対しては、型番、ファームウェアバージョン、MAC アドレス、稼働時間などの識別情報を応答します。もう一方のコマンドパケットでは、ペイロードがシェルコマンドとして渡される実装になっていると報告されています。

受け入れ判定にはハードコードされた値を使ったチェックと、機器自身の MAC アドレスとの照合が用いられます。ただし CVE Record の記載どおり、全ゼロの MAC アドレスを指定すると照合を回避できる実装が含まれており、認証としては機能していないと評価されています。結果として、認証されていない攻撃者が root 権限で任意コマンドを実行できるとされています。

なお応答に使われる UDP ポートについては、一次情報の中でも記載が分かれています。VulnCheck のブログ本文と公開されたスキャナーは UDP/8897 を前提としていますが、同社が公開した Suricata ルールのうちコマンド出力を検知するものは UDP/8898 を対象としています。どちらか一方へ統一できる根拠は確認できませんでした。

監視ルールを自組織で組む場合は、UDP/8897 と UDP/8898 の両方を対象にしておくと取りこぼしを避けられます。

影響機種とファームウェア

対象機種は CVE ごとに異なります。2 件を合わせた一覧で照合すると、実際には対象外の CVE まで自組織の対応範囲へ含めてしまうため、CVE 単位で確認することをおすすめします。以下の表は CVE Record が affected として明示しているファームウェアビルドです。

CVE-2026-74232/SPEAKINGSTONE の対象

ベンダー型番ファームウェア
ZbtlinkL3_V2_83.0.0.4.528
ZbtlinkWE826-T219.1101
ZbtlinkZBT-76281.0.0.2.007
ZbtlinkZBT-ZBT76211.0.0.3.001
MoreQuickMQAC-76201.0.0.2.000
MoreQuickMQAC-7620A1.0.0.2.000
MoreQuickMQAP-76201.0.0.2.000
MoreQuickMQAP-7620A1.0.0.2.000
MoreQuickMQAP-76281.0.0.2.000
ベンダー不明AP5221.0.0.2.014
ベンダー不明AP76283.0.0.4.380
ベンダー不明APG721B19.0809
ベンダー不明HC5661A3.0.0.4.380
ベンダー不明HK3001.0.0.2.032
ベンダー不明MAP-N101.0.0.2.044

MoreQuick は、VulnCheck が解析対象機のファームウェアを開発した中国の OEM として挙げている企業です。Zbtlink ブランドの製品だけを確認対象にすると、MoreQuick 名やベンダー不明として登録されている型番を見落とす可能性があります。

CVE-2026-74233/DARKLANTERN の対象

ベンダー型番ファームウェア
ZbtlinkWE132619.1101
ZbtlinkWE2426-C19.1112
ZbtlinkWE35719.1101
ZbtlinkWE592619.1101
ZbtlinkWE5926-EC_QP20.0516
ZbtlinkWE5926-WD19.1101
ZbtlinkWE826-Q19.1101
ZbtlinkWE826-T219.1101
ZbtlinkWE826-WD19.1101
ZbtlinkWF3526-P19.051
ZbtlinkWG10819.1101
ZbtlinkWG352619.1101
ベンダー不明CTN720-W119.1101
ベンダー不明LF-154119.1101
ベンダー不明MT7620N19.1101
ベンダー不明WRC120.0622

WE826-T2 は 2 件の CVE の双方に登場します。この機種を使用している場合は、待ち受け型と外向き通信型の両方を確認対象にすることになります。

Advisory と CVE Record のバージョン表記の差異

影響範囲の表記は、参照する一次情報によって異なります。執筆時点で確認した内容は次のとおりです。

VulnCheck Advisory

「記載されたバージョン以下」という上限つきの範囲として表示されています。たとえば WE826-T2 は 19.1101 以下が対象という形式です。

CVE Record

各型番につき個別のファームウェアビルドだけが affected として登録され、それ以外の既定状態は unknown になっています。範囲指定ではなく点の指定です。

VulnCheck ブログの実地観測表

DARKLANTERN については、CVE Record にないビルドも「実際に観測された」ものとして列挙されています。WE1326 の 18.1218 と 19.0717、WE2426-C の 19.0412 から 19.1112 までの複数ビルドなどが該当します。

3 者の表記が一致していないため、次の点に注意が必要です。一覧にない、または記載より新しいバージョンであることだけを理由に、対象外と判断できません。CVE Record の unknown は「影響を受けない」ではなく「状態が不明」を意味します。また、いずれの Advisory にも修正済みファームウェアのバージョンは示されていないため、更新すべき目標バージョンを一次情報から特定できない状況です。

逆に言えば、対象一覧との照合はスクリーニングとしては有効でも、それだけでは判断を確定できません。次に説明する通信経路の確認と組み合わせることをおすすめします。

203 台・392 台という観測結果の読み方

報道では 203 台と 392 台という数字が取り上げられています。いずれも VulnCheck の観測値ですが、測定方法が異なり、どちらも侵害台数ではありません。

DARKLANTERN のインターネットスキャン

VulnCheck は 2026 年 8 月 18 日から 21 日にかけて、22 か国で 203 台のインターネット公開インスタンスを特定したと報告しています。応答した機器は 16 種類の型番を自己申告しており、解析対象となった ZBT-WE826-T2 に限られない点が示されました。

同社は、これらが比較的古い機種であり、解析対象機のファームウェアも 2019 年ビルドであることから、DARKLANTERN の導入時期としては末期を捉えている可能性が高く、実際の導入台数はより多かったはずだと評価しています。

SPEAKINGSTONE のシンクホール

SPEAKINGSTONE には、プライマリ C2 が設定されていない場合に接続するバックアップ C2 ドメインがハードコードされています。VulnCheck は解析時点でこのドメインが未登録だったことを確認し、自ら取得してプロトコルを再実装したサーバーを立ち上げるシンクホールを構築しました。

2026 年 8 月 21 日時点で 392 台の固有の機器が接続し、そのうち 390 台が中国、83 パーセントが China Mobile のネットワーク上、304 台が CMCC で始まる SSID を発信していたとしています。さらに 363 台が L3_V2_8 という単一の型番で、ファームウェアは 3.0.0.4.528 と自己申告しました。最も長いもので 2 年近く継続して接続していた機器があるとも報告されています。

ここで重要なのは、バックアップドメインへ接続するのはプライマリ C2 が設定されていない機器に限られるという点です。プライマリ C2 は執筆時点でも稼働しているとされており、SPEAKINGSTONE を搭載した機器の全体像は不明です。

203 台が示すこと

調査期間中に、情報取得用プローブへ応答したインターネット公開インスタンスの数です。侵害された台数でも、DARKLANTERN を搭載した機器の総数でもありません。

392 台が示すこと

バックアップ C2 ドメインへビーコンを送った機器の数です。プライマリ C2 を利用する機器は含まれず、影響機器全体の台数でも、第三者による侵害が確認された台数でもありません。

VulnCheck KEV、CISA KEV、SSVC の違い

悪用状況を判断するときは、参照先ごとに意味が異なる点を区別してください。執筆時点で確認できた状態は次のとおりです。

参照先何を示すか今回の状態
VulnCheck KEVVulnCheck が独自基準で管理する既知悪用脆弱性のデータベースCVE-2026-74233 の Advisory に掲載表示あり。CVE-2026-74232 では確認できない
CISA KEVCISA が管理する既知悪用脆弱性カタログ。BOD 26-04 に基づく対応義務は FCEB 機関が対象執筆時点で確認した範囲では、ENDLESSDOORS を含む 3 件とも未掲載
CISA Vulnrichment の SSVCCISA-ADP が付与する意思決定用の評価値2 件とも Exploitation: poc、Automatable: yes、Technical Impact: total(2026 年 8 月 27 日記録)
インターネットスキャンの応答サービスが公開され、応答したことDARKLANTERN で 203 台
シンクホールへの接続機器がインプラントを搭載し、ビーコンを送っていることSPEAKINGSTONE で 392 台

SSVC の Exploitation における poc は、分析時点で公開された概念実証が存在することを示す区分です。サービスが応答したこと、シンクホールへ接続したこと、概念実証が公開されていることは、いずれも第三者による侵害が確認されたことを意味しません。社内報告で「悪用が確認された」と表現すると、実態より強い判断につながります。

一方で、DARKLANTERN は認証が機能していない待ち受けサービスであり、SSVC でも Automatable が yes、Technical Impact が total と評価されています。悪用の確認有無にかかわらず、到達性がある構成では優先的に扱うのが妥当です。

自組織での影響確認と初動対応

通信方向で変わる確認ポイント

対象バージョンとの照合だけでは判断を確定できないため、通信経路からの確認を併用します。確認する対象は、インプラントの種類によって次のように分かれます。

DARKLANTERN の確認

WAN 側から UDP/9992 へ到達できるかを確認します。境界ファイアウォールやキャリア側でインバウンドが落ちていれば、外部からの直接到達は成立しません。ただし、同一セグメント内や VPN 経由の到達性は別に評価する必要があります。

SPEAKINGSTONE の確認

UDP/10000 の外向き通信と、C2 ドメインへの名前解決を確認します。DNS サーバーのクエリーログ、ファイアウォールの許可・拒否ログ、NetFlow、IDS/IPS のログが確認先になります。NAT の内側でも成立するため、インバウンド遮断を理由に対象外とはできません。

両方に共通する確認

実行中のプロセス名、関連ファイルとパス、ファイルハッシュ、DNS や PPPoE などの設定値、機器のログを確認します。管理権限があり、安全に確認できる機器に限って実施してください。

機器上での確認コマンドは、対象ファームウェアで利用できるかどうかが機種ごとに異なります。一般的な OpenWrt の手順がそのまま通用するとは限らないため、実施前にベンダー資料で確認することをおすすめします。

影響確認フロー

手順
対象機器を棚卸しする

Zbtlink 名の製品だけでなく、MoreQuick 名の製品、OEM/ホワイトラベル品を含めて洗い出します。海外拠点、店舗、車載、仮設回線などで導入されたセルラー CPE は、資産管理台帳から漏れやすいため注意してください。

手順
型番とファームウェアを CVE ごとに照合する

本記事の CVE 別の表と突き合わせます。一覧にないバージョンは、対象外ではなく状態不明として扱ってください。

手順
WAN 側から UDP/9992 への到達性を確認する

境界ファイアウォールのポリシー、キャリア側の制約、機器自身のフィルター設定を確認します。確認対象は自組織で管理権限を持つ機器に限定してください。

手順
UDP/10000 の外向き通信と C2 通信を確認する

DNS、ファイアウォール、NetFlow、IDS/IPS のログから、公開された C2 ドメインへの名前解決と UDP/10000 の外向きセッションを探します。ログの保持期間の範囲でさかのぼって確認してください。

手順
プロセス、ファイル、ハッシュを確認する

管理権限があり、業務影響なく確認できる機器に限って実施します。後述の IoC に挙げたプロセス名、ファイルパス、SHA-256 ハッシュが確認の起点になります。

手順
該当または判断不能の機器を隔離する

業務ネットワークから切り離し、当該機器の LAN 側を信頼済みネットワークとして扱わない構成へ変更します。判断が付かない機器も、同様に扱うことをおすすめします。

手順
設定の改変と認証情報の流出を調査する

DNS 設定、PPPoE の認証情報、リバース SSH の有効化状態、管理者アカウントやポート転送などの管理設定について、想定外の変更がないかを確認します。流出の可能性がある認証情報は変更を検討してください。

手順
機器交換を含めて恒久対応を判断する

信頼できる修正版を確認できない場合は、更新を待つ選択肢が成立しません。交換に必要な期間と費用を見積もり、暫定的な遮断を継続する期間とあわせて判断します。

確認に使う IoC

VulnCheck が公開した指標を、どちらのインプラントに関係するかが分かる形で整理します。

区分種別
SPEAKINGSTONEC2 ドメインwww.ac-link[.]com(プライマリ)
SPEAKINGSTONEC2 ドメインwww.findmyipaddr[.]com(バックアップ、現在は VulnCheck のシンクホール)
SPEAKINGSTONEIP アドレス47.107.224[.]89
SPEAKINGSTONEUDP ポート10000(外向き)
SPEAKINGSTONEプロセス名yunmgrd
SPEAKINGSTONE関連ファイル/tmp/yunclient.conf
SPEAKINGSTONESHA-256b77811db4d218c65670a6c9a5b33c30ff81c6d779e15d658643138771178a818
DARKLANTERNUDP ポート9992(待ち受け)、8897 または 8898(応答)
DARKLANTERNプロセス名infosrvd
DARKLANTERNSHA-2567e2e036fec2fe7ab4bbd43978d9296563894c92a112f5ac2f39957f12108e245
両方に関連関連ファイル/etc/exec/cmd、/tmp/info.txt
起動元プロセス名inetdetect
起動元SHA-256ae6c356f1f09260b859f84d994ef8423540a6c0bdf98510d86b85834283e4926

ドメインと IP アドレスは変更される可能性があります。ログでヒットしなかったことだけを根拠に、対象外と判定できません。型番とファームウェアの照合、通信経路の確認と組み合わせて判断してください。

www.findmyipaddr[.]com は VulnCheck が取得してシンクホールとして運用しています。このドメインへの通信を検知した場合、攻撃者の C2 と通信しているのではなく、SPEAKINGSTONE を搭載した機器が自組織内に存在することを示します。

VulnCheck は防御目的で Suricata ルールと YARA ルールも公開しています。Suricata 側は UDP/9992 宛のプローブとコマンド、コマンド出力の応答、C2 ドメインへの DNS クエリー、UDP/10000 のビーコンなどを検知対象としており、YARA 側は yunmgrdinfosrvd のバイナリー特徴を対象としています。ルール全文は VulnCheck ブログ末尾の Appendix で公開されています。

あわせて DARKLANTERN の応答確認用スキャナーも公開されていますが、利用する場合は自組織で管理権限を持つ機器だけを対象にしてください。インターネット上の第三者の機器へ向けた確認は行わないでください。

暫定対策と恒久対応の区別

修正版が示されていない状況では、まず被害の成立条件を落とす暫定対策から着手することになります。検討できる内容は次のとおりです。

  • インターネット側から UDP/9992 への到達を遮断する
  • UDP/10000 の外向き通信を監視し、必要に応じて制限する
  • 公開された C2 ドメインへの名前解決と通信を監視・遮断する
  • 対象機器を業務ネットワークから隔離する
  • 対象機器の LAN 側を信頼済みネットワークとして扱わない
  • DNS、PPPoE、SSH、管理設定の改変有無を確認する
  • 流出の可能性がある認証情報の変更を検討する

ただし、これらはいずれも通信経路を塞ぐ対策であり、ファームウェア内のコンポーネント自体が取り除かれるわけではありません。遮断を解除すれば、同じ状態へ戻ります。

信頼できる修正版を確認できない場合、この問題は通常のパッチ管理では完結しません。機器そのものを信頼できるかどうかというデバイストラストとサプライチェーンの課題として扱い、機器交換を含めた判断が必要になります。交換の判断材料としては、対象機器が担っている業務の重要度、隔離を継続した場合の運用負荷、代替機の調達期間が挙げられます。

3 種のインプラントが示すデバイストラストの問題

ENDLESSDOORS を含めると、Zbtlink 系のファームウェアでは世代の異なる 3 種のインプラントが報告されたことになります。個別の脆弱性としてではなく、機器の出所を信頼できるかという観点で捉える必要が出てきました。

確認作業で難しいのは、ブランド名だけでは対象を絞り込めない点です。VulnCheck は、同じプラットフォーム向けに独自ファームウェアを開発している MOFI Network の例を挙げ、同社のイメージには 3 種のいずれも含まれていなかったと報告しています。つまり、同一ハードウェアであってもファームウェアの出所によって結果が変わります。判断材料はブランドではなく、型番とファームウェアです。

製造元を推定する手掛かりとしては、MAC アドレスの OUI が利用できます。VulnCheck は解析対象機の MAC アドレスが 78:A3:51 で始まり、これが ZBT へ割り当てられたブロックであると指摘しています。The Hacker News は 2026 年 8 月 28 日に IEEE の登録データベースで確認し、78:A3:51 と F8:5E:3C の 2 ブロックが同社へ割り当てられていると報じました。二次情報にあたるため、実務で使う前に IEEE の登録内容で再確認することをおすすめします。

OEM 供給の広がりや、日本国内での流通経路と調達上の注意点については、前報の Zbtlink 20 機種に関する記事で整理しています。

ベンダーの説明が及ぶ範囲

Zbtlink は公式サイトで、2026 年 8 月 5 日に公開された調査報告について声明を出しています。ただしその内容は、ENDLESSDOORS に関係する rctl コンポーネントを対象としたものです。

参考: Shenzhen Zbt Electronics 公式声明
“This component has never been used for unauthorized access.”
(このコンポーネントが不正なアクセスに使われたことはありません)
https://www.zbtlink.com/pages/zbt-router-firmware-download-announcement

この声明では、対象モデルの販売停止と該当ファームウェアの公開停止、rctl の問題を解消する更新版の開発について説明されています。今回の yunmgrd と infosrvd を対象とした説明ではありません。執筆時点で、この 2 件に対する Zbtlink の公式声明は確認できませんでした。したがって、「Zbtlink はバックドアという評価を否定している」と包括的に書くことはできません。

一方で VulnCheck が今回の 2 件をインプラントと評価する根拠は、実装内容そのものにあります。認証も暗号化も持たない C2 チャネル、PPPoE 認証情報の取得機能、DNS ハイジャックリストの操作機能、リバース SSH トンネルの開閉機能が確認されたという点です。同社は、こうした機能が保守用ツールの説明では成り立たないと述べています。

ここで注意したいのは、「中国製だから危険」という一般化に落とし込まないことです。判断の根拠は製造国ではなく、特定のファームウェアで確認された具体的な実装と通信設計にあります。同じ ZBT プラットフォーム上でも、独自ファームウェアではインプラントが確認されなかった例が報告されている点が、その裏付けになります。

まとめ

CVE-2026-74232/SPEAKINGSTONE と CVE-2026-74233/DARKLANTERN は、いずれも root 権限での操作につながる一方、通信方向が逆であるため確認手順が分かれます。対象一覧との照合だけでは判断を確定できず、通信経路の確認と組み合わせる必要があります。修正版が示されていない現時点では、遮断と隔離を暫定策としつつ、機器交換までを視野に入れた判断が現実的です。

  • 2026 年 8 月 27 日に公開された Zbtlink 製ルーターの 2 件の CVE
  • 待ち受け型の DARKLANTERN と外向き通信型の SPEAKINGSTONE という通信方向の違い
  • UDP/9992 の到達性と UDP/10000 の外向き通信という確認ポイントの分離
  • Advisory の上限表記と CVE Record の個別ビルド指定という影響範囲の差異
  • 203 台と 392 台はいずれも観測値であり、侵害台数ではないこと
  • VulnCheck KEV への掲載と CISA KEV 未掲載という参照先ごとの違い
  • 修正版が確認できない状況での隔離、侵害調査、機器交換を含む判断

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ(ネットワーク・サーバ・クラウド・セキュリティ)の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus(取得から20年以上)/ VCAP-DCA / Azure Solutions Architect Expert

▶ 運営者プロフィール(詳細)

目次