2026年9月から10月にかけて、ブックオフ、ミスターマックス、ディップ「バイトル」、第一興商、コミューニティー基盤「Commune」など、国内で大規模な情報漏洩が相次ぎました。「またか」と感じた方も多いのではないでしょうか。
そんな中、情報通信研究機構（NICT）が2026年10月13日、こうした相次ぐ情報漏洩の「共通の入り口」になり得る攻撃手法を特定し、注意喚起を公表しました。名付けられた名前は「A2B攻撃」。この記事では、A2B攻撃とは何か、なぜアプリ自体に問題がなくても情報が漏れてしまうのか、そして企業が何を点検すべきかを整理します。
A2B攻撃とは何か
A2B攻撃（App-to-Backend Attack）とは、攻撃者が一般に公開されているスマートフォンアプリ（主にAndroidアプリ）を解析し、アプリが通信するバックエンドサーバの接続先やAPIの仕様を調べたうえで、その情報をもとにサーバを狙う攻撃手法です。NICT傘下の脅威情報分析チーム「LETTICE」が特定し、命名しました。
攻撃の流れは次の3段階です。
- 一般に公開されているアプリを入手し、解析（逆コンパイルなど）する
- アプリが通信するサーバの接続先や、APIの通信仕様を特定する
- 得られた情報をもとに、バックエンドサーバへ的を絞った攻撃を実行する
同様の手口は、Androidアプリに限らずiOSアプリやWebサービスでも起こり得るとされています。
なぜ「アプリ自体に問題がなくても」情報が漏れるのか
A2B攻撃の最も重要なポイントは、アプリそのものに脆弱性がなくても被害が起こり得るという点です。NICTは「サーバ側の認証やアクセス権限の確認、入力内容の検証などに不備があれば、不正アクセスや個人情報の漏えいにつながる恐れがある」と説明しています。
つまり、アプリの脆弱性診断だけを行い「問題なし」と判断していても、その裏側で動くサーバのほうに不備が残っていれば、A2B攻撃の標的になり得るということです。
LETTICEが挙げている、悪用されやすい4種類の脆弱性は次の通りです。
| 脆弱性 | 概要 |
|---|---|
| IDOR／BOLA（アクセス権限不備） | IDなどを指定するだけで、本来アクセスできないはずの他人のデータが閲覧・操作できてしまう |
| SSRF（サーバーサイドリクエストフォージェリ） | サーバーに本来許可されていない内部ネットワークへのリクエストを行わせる |
| RCE（リモートコード実行） | 外部から任意のコードをサーバー上で実行されてしまう |
| SQLインジェクション | 入力値の検証不備を突いて、データベースへの不正な命令を実行されてしまう |
これらは目新しい脆弱性ではなく、以前からWebアプリケーションの脆弱性診断で指摘されてきた古典的な項目です。A2B攻撃が新しいのは、脆弱性そのものではなく、「公開されているアプリを解析すれば、攻撃対象のAPIや仕様を効率よく洗い出せる」という攻撃の起点・効率化の部分にあります。
相次ぐ情報漏洩との関係
ここで注意したいのは、NICTは特定の企業名や事案を名指しして「A2B攻撃が原因だった」と確定しているわけではないという点です。あくまで「相次ぐ情報漏洩事案の原因の一つである可能性」として、攻撃手法の存在と対策の必要性を注意喚起するものです。
とはいえ、直近のCSRIの報道を振り返ると、公開アプリやオンラインサービスを起点とした大規模な情報漏洩が相次いでいたことは事実です。
- ブックオフに不正アクセス、最大約643万件の会員情報漏えいか
- ミスターマックス、最大173万人分の会員情報流出
- ディップ「バイトル」に不正アクセス、最大388万件のメールアドレス漏えいか
- 第一興商、個人情報約872万件漏えいの恐れ
- 交流サイト基盤「コミューン」不正アクセス、約30万7000会員に影響
これらの事案一つひとつがA2B攻撃によるものと確認されたわけではありませんが、「公開されたアプリ・サービスを起点に、裏側のサーバーが突破される」という構造は共通しています。これは、以前の記事「一つの侵入が何十社にも波及する――サプライチェーン経由の情報漏洩が急増する理由」で取り上げた、委託先・基盤経由の漏洩とも根っこの部分でつながるテーマです。どちらも「自社の対策だけでは完結しない」領域にリスクがある、という共通点があります。
また、NICTはAIの活用によってアプリ解析や脆弱性探索が効率化され、攻撃がより多くのシステムに広がる可能性も指摘しています。この点は、以前の記事「攻撃にも防御にも偽情報にも――AIが顔を出し始めたセキュリティの現場」で整理した「AIが攻撃の量と速度を底上げしている」という流れとも一致します。
事業者が今すぐ点検すべきこと
LETTICEは、事業者向けに次の3つの対策を提示しています。
- 侵害の確認：自社が公開しているAPI・サーバを棚卸しし、アクセスログから不審なアクセスや情報の不正取得の形跡がないか確認する。
- 脆弱性の点検：IDOR／BOLA、SSRF、RCE、SQLインジェクションを重点的に点検する。
- 暫定的な緩和策：不要なAPIの停止、アクセス制限の強化、認証情報の無効化・再発行、監視体制の強化を行う。
特に中小企業にとって重要なのは、「自社アプリの画面や機能に問題がないか」だけでなく、「そのアプリが裏側でどんなAPIを呼び出し、そのAPIがどこまで厳格にアクセス権限を確認しているか」まで含めて点検することです。アプリの見た目のテストだけでは、A2B攻撃のリスクは見えてきません。
よくある質問
Q. A2B攻撃は誰が特定したのですか？
情報通信研究機構（NICT）傘下の脅威情報分析チーム「LETTICE」が特定し、2026年10月13日に注意喚起として公表しました。
Q. 自社のアプリが安全かどうか、どう確認すればよいですか？
アプリ単体の診断だけでなく、アプリが通信するバックエンドAPIについて、IDOR／BOLA（アクセス権限不備）、SSRF、RCE、SQLインジェクションの4種類を中心とした診断を行うことが推奨されます。自社での判断が難しい場合は、セキュリティ専門事業者への相談が現実的です。
Q. iOSアプリやWebサービスなら安全ですか？
いいえ。NICTは、同様の手口がAndroidアプリに限らずiOSアプリやWebサービスでも起こり得るとしています。OSやプラットフォームを問わず、公開されているクライアント（アプリ・Webフロントエンド）とバックエンドサーバの関係がある限り、リスクは共通して存在します。
まとめ
A2B攻撃が示すのは、「アプリをきちんと作ったから安全」という発想だけでは不十分だということです。アプリは公開された瞬間、攻撃者にとっての「裏側のサーバーを知るための手掛かり」にもなり得ます。自社が公開しているアプリ・APIの棚卸しと、バックエンド側の認可・入力検証の点検を、今のうちに進めておくことをお勧めします。