Aqaraのスマートロックやカメラに乗っ取りの脆弱性、CVE-2026-50083ほか

スマートホーム機器の大手Aqara（アカラ）のクラウド基盤に、ログインなしで他人のスマートロックやカメラを操作できてしまう脆弱性が、まとめて10件公開されました。セキュリティ企業runZeroが調整した協調開示で、CVE番号はCVE-2026-50083からCVE-2026-50091まで連番で割り当てられています。

Aqaraは、Appleの「ホーム」（HomeKit）やMatterに対応したセンサー・カメラ・ハブ・スマートロックを世界190以上の国と地域で販売するブランドで、累計の機器登録は5,000万台を超えます。日本でも2024年2月にAmazonでの直販を開始し、玄関のスマートロックや屋内カメラが手に入る身近なブランドになっています。その「自宅の鍵と目」を預けるクラウドに、無認証で踏み込める穴が空いていた、というのが今回の話です。

先に結論を整理しておきます。今回の脆弱性の多くは、メーカー側のサーバー（クラウド）の作りに起因するもので、修正は2026年4月から6月にかけてメーカー側で進められました。利用者の端末を狙う攻撃が現実に起きたという報告（実際の被害・実証コードの悪用・CISAの悪用確認リストへの登録）は、いまのところありません。それでも、自宅の物理的な安全に直結する機器でこの規模の認証不備が見つかった意味は小さくありません。何が起きていたのか、利用者は何をすればいいのかを順に見ていきます。

公開された10件の概要

研究者のSammy Azdoufal氏が監査し、runZeroのTod Beardsley氏が調整した一連の開示は、全部でCVE-2026-50082〜50091の10件です。今回NVD（米国の脆弱性データベース）で深刻度が高く付いた6件を中心に整理します。なおCVE-2026-50086のCVSS値は、NVDが10.0、開示元のrunZeroが7.5と評価が分かれています。本記事は一次情報であるrunZeroの評価（7.5）を採用し、表にも併記します。

残る4件（CVE-2026-50082の未検証アカウント登録、50087・50088のクロスオリジン設定の甘さ、50089のリダイレクト悪用）は単体の深刻度は中程度ですが、後述する「乗っ取りの連鎖」では重要な部品になります。

今回の核心は、CVE-2026-50083・50084・50085の3つを順につなぐと、正規の利用者でなくても他人のスマートロックやカメラを操作できてしまう点にあります。

CVSSの数字は1件ずつの深刻度ですが、本当の怖さは「無認証で始められる連鎖」が成立していたことにあります。

この穴を誰が狙い、何を持ち去るのか

この脆弱性で一番危ないのは、攻撃の入口に「正規の利用者であること」が一切要らない点です。狙うのは遠い国のハッカーだけではありません。別れた交際相手、付きまといを続けるストーカー、下見をする空き巣、子どもの様子を覗きたい第三者、嫌がらせ目的の元同居人といった、被害者の生活圏にいる人間こそが、この種の「鍵と監視」を握る攻撃の動機を持ちます。彼らが手に入れるのは抽象的な「個人情報」ではありません。玄関の解錠操作そのもの、寝室や子ども部屋に向いた屋内カメラの映像と音声、在宅か不在かが分かる生活リズム、施錠・解錠の履歴です。CVE-2026-50083から50085の連鎖が踏まれた瞬間、見知らぬ端末から自宅の玄関が解錠され、家の中のカメラが他人の画面に映し出されてしまうのです。

奪われた先の被害は、データの漏えいでは終わりません。屋内カメラの映像は、空き巣にとっては間取りと金目の物のある場所を確かめる下見になり、悪意ある相手の手に渡れば脅迫やつきまといの材料になります。施錠・解錠の履歴と在宅パターンを重ねれば、家が無人になる時間帯を正確に狙った侵入が組み立てられます。盗み出されたアカウント情報やトークンはダークウェブで売買され、同じパスワードを使い回している他のサービスの乗っ取りへと横に広がっていきます。物理的な家への侵入と、オンライン上のなりすましが、ひとつの穴から同時に動き出すのが、住宅機器のクラウドが破られたときの特徴です。

そして、この被害の責任は利用者にはほとんど返りません。原因は利用者のパスワードの甘さではなく、メーカーであるAqara（運営元はLumi United Technology）のクラウドの作りそのものにあるからです。住宅設備に近い機器を扱う以上、漏えいが起きれば個人情報保護委員会への報告や利用者への通知、被害者対応や信用の回復にメーカーが直接向き合うことになります。CVSSの数字には現れないこの種のコストは、玄関の鍵と家の中の映像という、お金で取り返しのつかないものに値段を付ける話です。だからこそ、いま自分の設定で打てる手があるかどうかが、その家の安全を分けます。

そもそもスマートロックやカメラは、どう動いているのか

「スマホで玄関の鍵を開ける」と聞くと、スマホと鍵が直接やり取りしているように思えますが、実際は違います。多くのスマートホーム機器は、メーカーのクラウド（インターネット上のサーバー）を経由して動いています。外出先からスマホで「解錠」を押すと、その命令はいったんAqaraのクラウドに届き、クラウドが「この人は正規の持ち主だ」と確認したうえで、自宅の鍵に「開けろ」という指示を送ります。カメラの映像も同じで、クラウドを通して手元のスマホに届きます。

この仕組みの便利さの裏側には、はっきりした弱点があります。クラウドの「この人は正規の持ち主だ」という確認が甘ければ、持ち主でない人の命令も通ってしまう、という点です。家の玄関に頑丈な鍵を付けても、その鍵を遠隔操作する受付係（クラウド）が誰の命令でも聞いてしまうなら、鍵の頑丈さは意味をなしません。今回見つかった脆弱性は、まさにこの「受付係」にあたるクラウドの認証の甘さでした。

同じ構図の事故は、今回が初めてではありません。今回の研究者であるSammy Azdoufal氏は、2026年2月にDJIのロボット掃除機「Romo」を約7,000台、24か国にわたって遠隔操作できる状態を見つけたことで知られています。自分の掃除機をPS5のコントローラーで動かそうとAIコーディング支援の「Claude Code」でクラウドの通信を解析したところ、発行された「認証トークン」が自分を他人の掃除機の正規ユーザーとしても扱ってしまい、他人の機器のカメラやマイクにまで手が届いた、という事案です。今回のAqaraも、根っこは同じ「クラウドのトークンが、本来の持ち主以外にも権限を与えてしまう」設計の問題です。

無認証から機器乗っ取りまでの4ステップ

研究者が示した乗っ取りの流れは、ログインを一切持たない状態から4つのステップで成立します。技術的な要点だけ追います。

ステップ②で発行されるトークンが、今回いちばん象徴的でした。研究者によれば、クラウド側に「test1:123456」という固定の認証情報が埋め込まれており、これを使うと「すべての権限（scope=all）」を持ち、有効期限が2083年まで（約57年間）という事実上無期限のトークンが手に入りました。しかもこのトークンは、利用者がパスワードを変更しても失効しませんでした。ステップ③では、本番APIの署名チェックが任意の開発者IDを受け入れてしまうため、正しい署名を組み立てると「code:2002（受理）」が返ってきます。最後のステップ④では、その署名付きの命令を本番API（CVE-2026-50084）に送るか、あるいは認証を一切要求しないデバッグ用の窓口（CVE-2026-50085）からメッセージ配信の仕組みへ直接命令を流し込むことで、プラットフォーム上のスマートロック・カメラ・ハブ・各種センサーを操作できる、というのが結論です。

個別の脆弱性

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

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

認証基盤に「test1:123456」という固定の認証情報が埋め込まれていた問題です（CWE-798: ハードコードされた認証情報）。誰でもこの組み合わせで、全権限・2083年まで有効・パスワード変更でも失効しないトークンを発行できました。runZeroの勧告では、これが乗っ取り連鎖の「鍵入手」にあたると位置づけられています。

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

本番APIの署名検証が、任意の開発者IDを使った正しい形式の署名を受け入れてしまい、結果として他人のアカウントの機器を操作できた問題です（CWE-862: 認可の欠落）。研究者の実証スクリプトでは、正しい署名で「code:2002（受理）」、誤った署名で「code:302（拒否）」が返ることを確認しています。この1件は、開示時点（6月）でも修正が確認できず「まだ有効」と報告されたもので、6件の中でも特に注意が必要です。

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

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

CVE-2026-50086: 認証なしの暗号・復号窓口（CVSS 7.5、NVDは10.0）

認証基盤が、プラットフォームの署名鍵を使ったAES暗号化・復号を、認証なしで誰でも呼び出せる状態で公開していた問題です（runZeroの勧告）。しかも暗号方式が古いECBモードで、同じ平文が常に同じ暗号文になるため、盗み見たトークンの復号や偽造の足がかりになり得ます。冒頭で触れたとおり、深刻度はrunZeroが7.5、NVDが10.0と評価が割れています。runZeroが示すベクトルは情報の機密性のみに影響する内容（C:H/I:N/A:N）で、本記事は一次情報側の7.5を採用しています。

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

外部サービスとログイン連携する際の「ログイン後の戻り先（redirect_uri）」のチェックが後方一致で甘く、aqara.com.evil.example.com のような攻撃者ドメインを正規と誤認してしまう問題です（NVD、CWE-1289）。利用者がうっかり連携を許可すると、本来は本人だけが受け取るはずの認可コードが攻撃者側に渡り、連携アカウントの乗っ取りにつながります。

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

Android版アプリ（com.lumiunited.aqarahome）が内部で使うライブラリに、AESの暗号鍵が固定で埋め込まれていた問題です（CWE-321: ハードコードされた暗号鍵）。アプリを解析すれば誰でも同じ鍵を取り出せるため、通信の盗み見や偽造の前提が崩れます。6件の中で、利用者の手元（スマホアプリ）に関係する唯一の項目で、対策は後述するアプリの更新が中心になります。

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

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

特に、有効なログインセッションが2,969件もまとめて取得でき、その中にAqaraの社員2名分まで含まれていた点は、認証基盤の作りそのものに穴があったことを物語ります。連番でたどれた顧客管理の添付ファイルが約172万件、しかも9割が実在したという数字も、住所や問い合わせ内容といった個人情報が無防備に近い状態だったことを示しています。

メーカーの対応と、研究者の再検証の食い違い

開示までの流れには、メーカーと研究者の評価が一致していない部分があります。事実関係を時系列で整理します。

← スワイプで移動

食い違っているのは、修正の進み具合についての見方です。Aqaraは4月20日の時点で「指摘27件のうち26件を修正済み」と表明し、研究者に独立した再検証を呼びかけました。一方で研究者が再検証した結果は、確実に修正されたと確認できたのは一部にとどまり、依然として悪用可能なものが複数残っていた、というものでした。特にCVE-2026-50084（署名検証の不備）は、公開時点でも実証スクリプトで「まだ有効」と確認された、と報告されています。メーカーの「直した」という説明と、研究者の「まだ通る」という確認の両方を、現状として並べて受け止めておくのが妥当です。

なお、現時点でこの一連の脆弱性が実際の攻撃に使われたという報告はなく、CISAの「悪用が確認された脆弱性」リストにも登録されていません。修正の多くはクラウド側（利用者から見えないサーバー）で進められているため、利用者がパッチを当てる類の作業は基本的に発生しません。

Aqara製品を使っている人は何をすればいいのか

今回の穴の大半はクラウド側の問題で、利用者の手で塞げるものではありません。それでも、できる備えはいくつかあります。慌てる必要はありませんが、玄関の鍵と家の中の映像に関わる以上、一度は手元の設定を見直しておく価値があります。

なかでも、Androidアプリを使っている人はAqara Homeアプリを最新版に更新しておくのが第一です。これは6件のうち唯一、利用者の手元に関係する項目だからです。パスワードの変更と2段階認証は、今回の件に限らずスマートホーム機器全般で有効な基本対策です。スマートロックを使っている場合は、念のため物理鍵での開錠手段を確保しておくと安心です。

技術的に見ると ── 便利さの裏にある「クラウド集中」のリスク

今回の10件は、個別に見れば「固定パスワード」「署名検証の甘さ」「古い暗号方式」「リダイレクト先の検証不足」といった、いずれもセキュリティの教科書に載っている基本的な不備です。むしろ問題なのは、それらがひとつのクラウドに集中し、しかも本人確認なしで連鎖できる形でつながっていたことです。家庭用のIoT機器は、低価格と素早い機能追加を優先するあまり、認証の作り込みが後回しになりやすい構造的な事情を抱えています。

同じ研究者が2月にDJIのロボット掃除機で示した構図と、今回のAqaraは驚くほどよく似ています。どちらも「クラウドが発行したトークンが、本来の持ち主の範囲を超えて権限を与えてしまう」という、認可（誰が何をしてよいか）の設計ミスです。スマート家電がスマホ単体ではなくクラウド経由で動く以上、機器そのものの暗号化がいくら堅牢でも、クラウドの受付が緩ければ全体が緩みます。利用者にできることは限られますが、エンジニアの視点では、自社サービスでも「発行したトークンの有効範囲」「テスト用エンドポイントの本番混入」「パスワード変更時のセッション失効」を、この機会に棚卸ししておく価値があります。

なお今回の件は、特定のオープンソース部品の欠陥ではなくメーカー独自のクラウド実装の問題のため、ソフトウェア部品表（SBOM）の照合では検知できません。同じ発想で自社のクラウドの認証・認可フローを点検する、という形での横展開が現実的です。

まとめ

スマートホーム機器大手のAqaraのクラウド基盤に、ログインなしでスマートロックやカメラを操作できてしまう脆弱性が10件公開されました。固定パスワードで57年有効のトークンが発行でき、署名検証の不備で他人になりすませ、認証なしのデバッグ窓口から機器へ直接命令を流せる、という連鎖が成立していたのが核心です。修正の多くはメーカー側で進められ、実際の攻撃に使われたという報告は現時点でありません。ただしCVE-2026-50084は公開時点でも有効と報告されており、メーカーの「修正済み」という説明と研究者の再検証には食い違いが残ります。

利用者にできるのは、アプリの更新、パスワードの変更、2段階認証、操作履歴の確認、カメラ設置場所の見直しといった基本の備えです。玄関の鍵と家の中の映像を預ける機器だからこそ、便利さの裏でどこに信頼を置いているのかを、一度立ち止まって確かめておきたい事例です。

参照元

• ▸Sammy Azdoufal - theres-no-place-like-home（研究者の公開資料・PoC・露出データ）
• ▸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
• ▸PR TIMES - Aqaraが日本上陸、Amazon日本で販売開始（Lumi United Technology）
• ▸AV Watch - アップル「ホーム」対応デバイス大手「Aqara」日本上陸
• ▸RNZ - 同研究者によるDJIロボット掃除機7,000台の遠隔操作事案（2026年2月）