CVE-2026-8374

LOWCVSS 8.5 · HIGH

Signal is active with 1 mentions in latest observed window

Immediate actions

  • Track advisory updates for patch or workaround availability

Recommended action window: Monitor and triage in normal cycle

NVD description

Misuse and misconfiguration in Bluetooth communication in SwitchBot Door Lock Series allows an attacker to bypass the electronic lock and access controls via a manipulated communication protocol.

0.0/ 10 priority

Sources & remediation

Weakness type (CWE)
CWE-1204CWE-1240

Priority

LOW

Exploitation

NONE

PoC

NONE

Patch

NONE

Momentum

NONE

Threat summary

  • 1 mentions across 1 observed day

What's happening

  • 1 total mentions across 1 day

Deep dive

Activity timeline1 mentions / 1d
00111Mentions · 2026-10-27: 110-27
Referenced assets3 URLs
By indicator
Full discourse1 post
  • 美濃加茂まむ@superdoccimo

    玄関のスマートロックが、鍵も暗証番号も知らない第三者に、物理的な細工なしで静かに開けられてしまう恐れがあった。日本でも人気の高いSwitchBotのドアロック製品群に見つかった暗号実装の欠陥で、CVE-2026-8374として10月9日に登録され、発見元のNeodyme(ドイツのセキュリティ企業)が10月26日に詳しい解説記事を公開した。 対象はSwitchBotのドアロックシリーズ。CVEの記載では、ロック本体ファームウェア3.4以下、キーパッド2.7以下、アプリ9.2.6以下が影響を受ける。深刻度はCVSS 4.0で8.5(High)で、攻撃にはBluetoothの電波が届く近距離にいる必要がある。SwitchBotはすでに修正版を配布しており、研究者は2026年4月2日に「報告した攻撃は最新版では動かなくなった」と確認している。つまり最新のファームとアプリに更新されていれば問題ないが、更新が行き届いていない個体は残り得る。 仕組みはこうだ。この製品は玄関の外側に置くキーパッドが「開ける・閉める」の判断を行い、室内側のアクチュエータ(実際に鍵を回す装置)にBluetooth Low Energyでコマンドを送る。通信はAES-128のCTRモードで暗号化されているが、CTRモードは中身が改ざんされたかどうかを検知する仕組み(メッセージ認証)を持たない。これがすべての元凶になっている。 CTRモードは、鍵・ノンス・カウンタから作った鍵ストリームを平文にXORするだけの方式で、暗号文の1ビットを反転させると復号後の平文も同じ位置の1ビットだけ反転する。そしてBSides(セキュリティ勉強会)の発表資料によると、施錠コマンドと解錠コマンドは LOCK = 57 0f 4e 01 01 00 00 00 UNLOCK = 57 0f 4e 01 01 00 00 80 で、わずか1ビットしか違わない。つまり暗号文のその1ビットを立てるだけで、暗号化された施錠コマンドが、そのまま有効な解錠コマンドに化ける。この差分マスクは鍵にもノンスにも依存せず、全セッション・全個体で共通なので、一度計算すれば万能の開錠マスクとして使い回せる。しかもキーパッドの施錠ボタンは、すでに施錠済みでも押すたびに暗号化された施錠コマンドを流すので、攻撃者は近くでそれを傍受して差分を当てるだけでよい。 ここを自分でも検証環境(Debian 13、Python 3.13.5、pycryptodome 4.2.0、8 vCPUのLinuxマシン)で再現してみた。上記の8バイトのコマンドとAES-128-CTRを使い、鍵とIVを毎回ランダムに変えた20万セッションすべてで、傍受した施錠コマンドの暗号文に末尾1バイトのマスク(0x80)をXORしただけで、復号結果が正しい解錠コマンドになった(200000件中200000件成功)。鍵もノンスも一切知らずに、である。これは公開された理屈どおりの挙動で、暗号化しているから安全という思い込みが、完全性の検証を欠くと崩れることを端的に示している。実機そのものを開けたわけではなく、公開された仕組みとコマンド列を暗号的に再現した結果である点は明記しておく。 修正パッチにも弱点があった、と研究者は報告している。SwitchBotはコマンドにMD5ハッシュ(コマンドと鍵とIVを連結したもの)の先頭2バイトだけを検証タグとして付ける方式を追加したが、2バイトのタグは取り得る値が65536通りしかない。発表資料によれば、セッション中はIVが固定で、BLEのタイムアウト再送も許されるため、総当たりが現実的になるという。手元の検証環境でも2バイトのタグ空間は65536通りで、正しいタグへの到達に要する試行は平均で3万回強、計算自体は数ミリ秒だった(今回の実行では5万1773回目で一致、約4ミリ秒)。実運用での律速はBluetoothの再送速度であって、暗号強度ではない。 さらに厄介なのが、このパッチが当初キーパッド側のコマンドにしかタグを付けず、スマホアプリから送るコマンドは検証なしのまま残り、ロック側がどちらの相手から来たかを区別しなかった点だ。研究者は、キーパッドの施錠コマンドとアプリの解錠コマンドの差分を取り直し、タグを付けずに送るだけでパッチを回避できたとしている。これも手元で再現したところ、タグなしの偽造解錠コマンドが10万セッションすべてで通った(100000件中100000件成功)。 付随して、キーパッドが使っている鍵フォブ(MIFARE Classic 1K)はとうに解読済みで容易に複製でき、キーパッドの取り外し警報(ホール効果センサー)も強力な磁石で無効化できる、とも報告されている。 この話が示すのは、一部のマニア向けの細かな脆弱性ではなく、玄関の鍵という一番身近なものの安全性だ。AES-CTRの誤用、つまり暗号化はしたが完全性を検証しないという失敗は、OWASPでも頻出の類型で、スマートロックに限らずIoT全般で繰り返されてきた。SwitchBotの対応自体は素早く、そもそも暗号化を試みていた点は他メーカーよりましだという見方もできる。重要なのは利用者側の行動で、いまSwitchBotのロックを使っているなら、本体・キーパッド・アプリのバージョンが修正版に上がっているかを一度確認しておきたい。Neodymeの記事には製品ごとの修正版バージョンが列挙されている。 日本語での詳しい解説は、Web検索で日本語キーワードを複数試した範囲ではまだほとんど見当たらなかった。SwitchBotは日本でも広く使われているだけに、早めに知っておく価値のある話だと思う。 出典 http://neodyme.io/en/blog/switchbot http://cve.org の CVE-2026-8374 BSides(http://bsidesfrankfurt.org)の発表スライド

    00001266
    21.0K followersView on X

Explore more