Aqaraの危険性と安全性。脆弱性18件の一覧と機種ごとの現状

Aqara（アカラ）の製品には、いま公開されている脆弱性が18件あります。2026年6月にクラウド側の10件（CVE-2026-50083ほか）、2025年12月にハブとカメラ側の8件（CVE-2025-65290ほか）です。数はNVD（米国の脆弱性データベース）でaqaraを検索した結果と一致します。

クラウド側の10件のうち4件は、順につなぐとログインなしで他人のスマートロックやカメラに命令を送れる、という内容でした。研究者はCVE番号が付いた10件を含む27件をAqaraへ報告し、2026年4月20日に自分で確かめ直しています。その結果は7件が塞がれ、9件はまだ通り、9件は判断がつかない、というものでした。一方でAqaraは公開日に「これは本番から切り離した試験環境の話で、実際の利用者の機器や情報には届かない」という声明を出しました。両者の言い分は今も一致していません。

実際の攻撃に使われたという報告は、2026年8月20日時点でもありません。米国CISAが公開している「悪用が確認された脆弱性」の一覧（同年8月19日版）にも、Aqaraの項目は1件も入っていません。

公開された脆弱性18件の一覧

まず2026年6月に公開されたクラウド側の10件です。「深刻度」の欄には2つの数字が並びます。左が報告を取りまとめたrunZero社と研究者が付けた値、右がNVDが2026年7月9日から10日にかけて独自に付け直した値です。同じ番号でも、見る側によって評価が3ポイント以上ずれているものがあります。

「塞がれた」は、研究者が2026年6月11日の公開資料に自分でそう書いている項目です。逆にCVE-2026-50084は、正しい形の署名を送ると受理を表す応答（code:2002）が返り、誤った署名だと拒否（code:302）が返る、という差が公開日にも残っていた、と記録されています。CVE-2026-50091については、Aqaraは修正済みと回答しましたが、鍵はアプリと機器の中に焼き込まれているため、サーバー側の修正では入れ替えられません。研究者は「アプリと機器の更新が同時に配られない限り確認できない」としています。

深刻度の数字は、どこの誰が付けたものかを見ないと読み違えます。CVE-2026-50086がその例で、runZeroは勧告の本文に7.5と書きながら、CVEの登録記録には10.0という指標値を登録しています。7.5と10.0はどちらも報告側の数字で、NVDが独自に付けた値は9.8です。上の表では、報告側は勧告本文の値、NVDは独自評価の値をとっています。

ハブとカメラ側の8件（2025年12月公開）

クラウドの話より半年前に、機器そのものを調べた別のグループが8件を公開しています。ジョージ・メイソン大学のJunming Chen氏ら4名による報告で、CVE-2025-65290からCVE-2025-65297までが割り当てられました。GitHubの脆弱性データベースではAqaraで検索すると、この8件と2026年の10件があわせて18件並びます。この8件にはNVD独自の評価が付いておらず、下の表の深刻度は米国CISAが記録に追加した値です。

研究グループが実際に動作を確かめた版は、カメラハブG3のファームウェア4.1.9_0027、ハブM2の4.3.6_0027、ハブM3の4.3.6_0025です。ファームウェアとは、機器の中に入っている本体側のソフトのことです。

2026年2月に追記された追試の結果では、機種によって対応の進み具合が分かれています。研究グループの報告は、いちばん深刻なCVE-2025-65294（説明書にない遠隔操作の口）について次のように分類しています。

• 後の安定版で口が消えていた機種: E1、G3、M1S2、M1S22、M2PoE、M3
• 試した範囲では残っていた機種: G2H Pro、G4、H1、M1S、M2、P3、およびエアコン用機器1種

Aqaraは2025年10月10日に「ハブM2とM3はファームウェアV4.3.8を8月28日に配信、カメラハブG3は対応版を10月20日に配信」と回答しています。ただし研究グループは同年10月27日に「追試は通らなかった」と記し、どの版で直ったのかを問い合わせたが返答が無かったとしています。機種ごとに版番号の付け方が違うため、「この版以上なら大丈夫」と言い切れる対応表にはなっていません。

Aqaraはどこの国の会社か

Aqaraはブランド名で、作っているのはLumi United Technology Co., Ltd.（緑米聯創、中国・深圳）です。日本語版サイトの最下部にも「Copyright © 2026 Lumi United Technology Co., Ltd.」と出ます。アプリの配信元も、Google Playが「Shenzhen Aqara Software Service Co., Ltd.」、App Storeが「Aqara Software Service Co.,Ltd.」で、深圳の会社です。

では自分のデータがどの国のサーバーに置かれるのか。ここは、はっきりしません。日本語版のプライバシーポリシーを2026年8月20日に読みましたが、書いてあるのはウェブサイトのクッキーとアクセス記録の話で、機器や利用者の情報をどの国のサーバーに保管するのか、国外へ移すのかについての記載はありません。Aqara Homeアプリはアカウントを作るときに国と地域を選ぶ作りになっていますが、それがどのサーバーに対応するのかも公表されていません。

今回の脆弱性が中国の会社だから起きた、という筋の話ではありません。指摘されたのは固定パスワード、署名の確認漏れ、古い暗号方式、戻り先の確認不足といった、どの国の会社でも起こる基本的な不備です。それでも「どこに預けているのか分からない」という状態自体が、玄関の鍵と室内の映像を扱う機器では判断材料になります。

自分の機器が対象かどうかを確かめる

アプリの版数

CVE-2026-50091で名指しされているのは、Android版 Aqara Home 6.0.0（内部名 com.lumiunited.aqarahome）です。研究者が取り出したのは、このアプリに入っている liblumidevsdk.so という部品に固定で書かれた暗号鍵で、部品の作成日は2025年9月4日でした。

2026年8月20日に確認した配信中の版は、iPhone・Androidとも6.3.9です（App Storeは8月6日公開、Google Playは8月3日更新）。監査を受けた6.0.0から3つ上の世代になります。ただし、更新履歴にCVE-2026-50091を直したという記述はなく、鍵が入れ替わったかどうかは外からは分かりません。入れ替えるにはアプリと機器の両方を同時に更新する必要があり、研究者もそこは確認できていないと書いています。それでも更新自体は他の不具合対応も含むので、最新版にしておく意味はあります。

なお、Aqaraは「AES鍵は数年前にやめており、いま出荷している製品には入っていない。研究者が挙げているのは8年前の販売終了品だ」と反論しています。これに対し研究者は、鍵を取り出したファイルが2025年9月作成のアプリに入っていた点を挙げて反論しています。

日本で売られている機種はどうか

2026年8月20日時点で日本語版サイトに載っている機種と、上記の報告に名前が出てくるかどうかを並べます。

「出てこない」は「安全だと確かめられた」という意味ではありません。研究グループが手元で調べた機種に入っていなかった、というだけです。逆に、日本語版サイトに今も載っているM2ハブとスマートビデオドアベルG4は、追試で「試した範囲では残っていた」側に分類されています。この「残っていた」は、研究グループが試した範囲では後の版でも口がふさがれていなかった、という意味です。つまりこの2機種については、本体のソフトを最新にしても解消したとは確認されていません。報告に出てくるM1S・M1S2・M1S22・M2PoE・H1・P3・G2H Proのほうは、日本語版サイトの一覧には載っていません。

型番が似ていても別物です。たとえばスマートカメラG3ハブと現行のカメラハブG350、スマートビデオドアベルG4とドアベルカメラG400・ドアベルハブG410は、それぞれ違う製品です。G3ハブは名前のとおりカメラでもハブでもあるため、日本語版サイトではハブとカメラの両方の一覧に出てきます。

一方、2026年6月に公開されたクラウド側の10件は、機種によらず全員が対象です。Aqaraのクラウドを通して動く機器は、ハブでもカメラでも鍵でも同じ経路を使うためです。

Aqara製品を使っている人がいまやっておくこと

クラウド側の不備は、利用者の手では塞げません。機器のファームウェアを更新しても、CVE-2026-50082からCVE-2026-50090までは直りません。それでも手元で効くことがいくつかあります。上から順に、効き目が大きいものです。

上2つは、報告した研究者本人が利用者向けに書いている内容です。ただし研究者が挙げているのはApple Homeの例で、Matterについては書いていません（Matterでの操作もAqaraのクラウドを通らない点は同じです）。2つ目は日本で売られている機種にも当てはまります。スマートロックJ200は本体がThread（機器どうしが直接つながる無線の規格）とBluetoothでつながり、Matter（メーカーをまたいで機器をつなぐ共通規格）に対応しているため、Aqaraのハブを置かずにApple Home・Google Home・Alexa・SmartThings・Home Assistantから直接使えます。Apple Homeの中で完結する操作は、Aqaraのクラウドを経由しません。ただし公式サイトの注記のとおり、つなぐ相手側にThread対応の機器が要ります。Apple HomeならHomePodやApple TVがそれにあたります。

ただし、外出先からの操作や通知、映像の保存など、Aqara Homeアプリでしかできない機能を使っている場合は、その分だけクラウドを通ります。どこまで手放せるかは使い方によります。

スマートロックそのものが危ないのか

今回の10件は、鍵の金具やモーターが破られた話ではありません。破られたのは、外出先から「開けて」と指示を出したときに、それを受け取って本物の持ち主かどうかを判断する側です。多くのスマートホーム機器は、スマホと機器が直接やり取りしているわけではなく、いったんメーカーのクラウドを経由します。そこの受付が誰の指示でも通してしまえば、鍵そのものがどれだけ頑丈でも意味をなしません。利用者がパッチを当てられないのも、直す場所が自分の家ではなくメーカーのサーバーだからです。

この構図はAqara固有のものではありません。同じGitHubの脆弱性データベースをSwitchBotで引くと4件が並びます。いちばん新しいのは2025年11月26日公開のCVE-2025-64983で、スマートテレビドアホンのファームウェア2.01.078より前の版が対象です。動作確認用の機能が有効なまま残っていて、同じネットワークにいる相手から機器にログインされ得る、という内容でした。こちらは自動更新が配信されています。件数の多い少ないで安全性は測れません。調べた人がいる製品ほどCVEは増えます。

判断の分かれ目になるのは、その鍵がクラウドを通さずに使えるかどうかと、クラウドが止まったときに家に入れるかどうかです。Matter対応でローカルの操作ができる機種を選び、物理鍵の逃げ道を残しておけば、クラウド側で今回のような話が起きても影響は「外出先から操作できない」で止まります。

ログインなしで機器に届くまでの4段階

研究者が示した流れは、アカウントを1つも持たない状態から4つの手順で成立します。それぞれの手順は個別に成立することが確認され、実際の利用者の機器に対して通しで実行することは行われていません。

手順②で出てくる通行証が、今回いちばん象徴的でした。クラウド側に「test1:123456」という固定の認証情報が残っており、これを使うとすべての権限つき・有効期限2083年9月（約57年間）という、事実上期限のない通行証が手に入りました。しかもこの通行証は、利用者がパスワードを変えても失効しません。手順③では、本番の窓口の署名確認が任意の開発者IDを受け入れてしまうため、正しい形の署名を組み立てると受理の応答が返ります。手順④では、その署名つきの命令を本番の窓口に送るか、認証を一切求めないデバッグ用の窓口から機器あてのメッセージ配信の仕組みへ直接流し込むことで、スマートロック・カメラ・ハブ・各種センサーへ命令が届きます。

6件それぞれの中身

深刻度が高く付いた6件について、何が問題だったのかを個別に見ます。

CVE-2026-50083: 57年間有効の鍵を生む固定パスワード

ログインを取り仕切る仕組みに「test1:123456」という固定の認証情報が埋め込まれていた問題です（CWE-798、ソフトに直接書き込まれた認証情報）。誰でもこの組み合わせで、全権限つき・2083年まで有効・パスワードを変えても失効しない通行証を発行できました。runZeroの勧告では、これが連鎖の「鍵入手」にあたると位置づけられています。研究者は公開までに塞がれたと記しています。

CVE-2026-50084: 他人になりすませる署名検証の不備

本番の窓口（open-cn.aqara.com）の署名確認が、任意の開発者IDを使った正しい形式の署名を受け入れてしまい、他人のアカウントの機器を操作できた問題です（CWE-862、権限確認の欠落）。10件のうち、公開日の時点でも研究者が「まだ通る」と記録した唯一の連鎖部品です。この窓口はAqaraが開発者向けに公開しているもので、Google Home・Alexa・HomeKitとの連携でも使われる、と研究者は指摘しています。

CVE-2026-50085: 認証なしのデバッグ窓口

開発・検証用のはずのデバッグ用窓口が認証を一切求めずに公開されており、ここを通すと機器あてのメッセージ配信の仕組みへ命令を直接送り込めました（CWE-306、重要な機能の認証欠落）。調査時点で、この窓口には18,537件の本番リクエストの記録が残っていたとされ、試験用の口が実運用に使われていた様子がうかがえます。研究者は公開までに塞がれたと記しています。

CVE-2026-50086: 認証なしの暗号・復号窓口

ログインを取り仕切る仕組みが、プラットフォームの署名鍵を使った暗号化と復号を、認証なしで誰でも呼び出せる状態で公開していた問題です（runZeroの勧告）。しかも古いECBという方式で、同じ内容が常に同じ暗号文になるため、盗み見た通行証の復号や偽造の足がかりになり得ます。4月20日の再検証では、暗号化と復号の往復が成立することが改めて確認されています。

CVE-2026-50090: 認可コードを横取りする転送先チェックの甘さ

外部サービスとログイン連携するときの「ログイン後の戻り先」の確認が後ろ一致で甘く、aqara.com.evil.example.com のような攻撃者側のドメインを正規と誤認してしまう問題です（NVD、CWE-1289）。利用者がうっかり連携を許可すると、本来は本人だけが受け取るはずの許可証が攻撃者側に渡ります。4月20日の再検証でも通ったと記録されており、上の対策表の1つ目が直接ここに効きます。

CVE-2026-50091: スマホアプリに埋め込まれた暗号鍵

Android版アプリ6.0.0が内部で使う部品に、AESの暗号鍵が固定で埋め込まれていた問題です（CWE-321、ソフトに直接書き込まれた暗号鍵）。アプリを分解すれば誰でも同じ鍵を取り出せるため、通信の盗み見や偽造を防ぐ前提が崩れます。この鍵はカメラの認証、機器の初期登録、内容の暗号化に使われており、しかも全利用者・全ブランドで同じものだと研究者は書いています。

公開された「数字」が示す露出の広さ

研究者の公開資料には、実際にどれだけの情報やアカウントが外から見える状態だったかが数で記録されています。攻撃に悪用されたという話ではなく、無防備だった範囲を示す数字です。

有効なログインセッションが2,969件まとめて取得でき、その中にAqara社員2名分の稼働中のものまで含まれていた点を、研究者は「試験環境の話」という説明への反証として挙げています。試験環境に実在社員の稼働中セッションは入らない、という理屈です。フォーラムの利用者検索は、報告後も塞がれないまま人数が増え続け、公開時点で210,287人になっていました。

メーカーの説明と研究者の再検証の食い違い

開示までの流れを時系列で整理します。

← スワイプで移動

Aqaraは4月20日に、指摘27件のうち26件を一覧表にして「すべて修正済み」と回答し、研究者に独立した再検証を呼びかけました。研究者が同日に確かめ直した結果は、7件が修正済み、9件がまだ通る、9件は判断がつかない、というものでした。一覧表から漏れていた1件は、Aqaraの利用者フォーラムが認証なしで利用者を検索できる状態になっていた件で、修正済みとも未対応とも書かれていません。

そして公開日の2026年6月11日、Aqaraの情報セキュリティ責任者Leon Yao氏が声明を出します。要点は、研究者が機器を操作できたのは本番から完全に切り離された試験環境であり、そこには実際の利用者のデータがなく、その環境から実際の機器やアカウントには届かない、実際の利用者の安全・プライバシー・機器のセキュリティへの影響は確認されていない、というものでした。個別の反論も3点あります。機器の操作については「その環境の機器は操作できない」、本番の窓口については「利用者の承認がなければアカウントにも機器にも触れない」、埋め込まれた暗号鍵については「AES鍵は数年前にやめており、対象は8年前の販売終了品だ」。

研究者はこれに3点で反論しています。第一に、署名の検証が生きている窓口open-cn.aqara.comはAqaraが開発者向けに公開している本番の窓口であり、Google Home・Alexa・HomeKitとの連携でも使われていること。第二に、取得できたログインセッションにAqara社員2名分の稼働中のものが含まれていたこと。第三に、Aqara自身が4月20日に26件を「修正済み」と書面で回答している以上、6月11日の「試験環境の話」という説明とは両立しないこと。どちらの言い分が正しいかを外から確かめる手立ては、いまのところありません。

2026年8月20日時点で、研究者の公開資料は6月11日以降更新されていません。Aqaraからの追加の声明も見つかりませんでした。実際の攻撃に使われたという報告もなく、米国CISAの「悪用が確認された脆弱性」一覧（8月19日版・1,671件）にもAqaraの項目はありません。

更新履歴

• 2026年8月20日: 2025年12月に公開されたハブ・カメラ側の8件（CVE-2025-65290〜65297）を追加。GitHubの脆弱性データベースをAqaraで検索して把握した。
• 2026年8月20日: CVE-2026-50086の深刻度の記述を訂正。以前は「NVDが10.0、runZeroが7.5」としていたが、10.0と7.5はどちらも報告側の数字で、NVD独自の値は9.8だった。
• 2026年8月20日: NVDが2026年7月9日から10日に付け直した深刻度を全10件に併記。CVE-2026-50084は9.6から6.5へ、CVE-2026-50090は9.3から6.1へ下がり、CVE-2026-50085は8.6から9.8へ上がっている。
• 2026年8月20日: 研究者が2026年4月20日に行った再検証の内訳（7件修正済み・9件はまだ通る・9件は判断がつかない）と、番号ごとの状況を一覧に追加。
• 2026年8月20日: Aqaraが公開日に出した声明（試験環境の話であるという主張と、3点の個別反論）と、それに対する研究者の反論を追加。
• 2026年8月20日: Aqara Homeアプリの版数を更新。監査対象は6.0.0、2026年8月20日時点の配信版はiPhone・Androidとも6.3.9。
• 2026年8月20日: フォーラム利用者数を194,654人から公開時点の210,287人へ更新。
• 2026年8月20日: 「どこの国の会社か」「日本で売られている機種はどうか」「Apple Home・Matterでクラウドを通さずに使う」の3点を追加。
• 2026年8月20日: 攻撃者像を推測する節と、他社サービスの点検を促す節を削除。この記事にたどり着く読者の疑問と対応していないため。
• 2026年6月13日: 初版公開。

参照元

• ▸Sammy Azdoufal - theres-no-place-like-home（研究者の公開資料。再検証の内訳、Aqaraの声明と反論、露出データ）
• ▸Chapoly1305/myCVEReports - Aqara Undocumented Remote Execution（CVE-2025-65294。機種別の追試結果）
• ▸GitHub Advisory Database - aqara の検索結果（18件）
• ▸NVD - aqara のキーワード検索（18件、深刻度の再評価を含む）
• ▸runZero Advisory - Aqara Hardcoded OAuth Credentials（CVE-2026-50083）
• ▸runZero Advisory - Aqara Production API Access（CVE-2026-50084）
• ▸runZero Advisory - Aqara Board IoT Debug API（CVE-2026-50085）
• ▸runZero Advisory - Aqara Unauthenticated AES Oracle（CVE-2026-50086）
• ▸NVD - CVE-2026-50083 ／ 50084 ／ 50085 ／ 50086 ／ 50090 ／ 50091
• ▸NVD - CVE-2025-65294 ／ 65295 ／ 65297（ハブ・カメラ側）
• ▸CISA - 悪用が確認された脆弱性の一覧（2026年8月19日版で確認。Aqaraの項目なし）
• ▸Aqara 日本語版サイト - 製品一覧 ／ スマートロック J200 ／ プライバシーポリシー
• ▸JVN#67185535 - SwitchBot製スマートテレビドアホンに利用可能なデバッグ機能が存在している脆弱性（CVE-2025-64983）