カテゴリー: SQAT® Security 瓦版

投稿日:

AI時代のA2B攻撃対策 ―アプリ診断で確認したいAPIの安全性

Share
AI時代のA2B攻撃対策 ―アプリ診断で確認したいAPIの安全性アイキャッチ画像

アプリのセキュリティを確認するとき、接続先のAPIまで同じ範囲で確認できているでしょうか。公開アプリを解析して接続先のサーバーを狙うA2B攻撃や、AIを利用した攻撃に関する報告を受け、アプリとAPIを一体で検証する重要性が高まっています。本記事では、公開された調査結果を整理し、企業が診断の依頼内容と運用体制を見直すための観点を考えます。

A2B攻撃で問われるアプリとサーバーの関係

国立研究開発法人情報通信研究機構（NICT）の脅威情報分析チームLETTICEは、2026年10月13日、公開Androidアプリの解析結果を利用して接続先のバックエンドサーバーを攻撃する手法を、A2B攻撃（App-to-Backend Attack）として公表しました*1。アプリ本体に脆弱性がなくても、サーバー側の認証・認可や入力値の検証に不備があれば、情報漏洩につながり得るとしています。

NICTは、同様の問題がAndroidアプリに限らず、iOSアプリやWebサービスのバックエンドAPIでも発生する可能性があると指摘しています。アプリの種類にかかわらず、接続先のサーバーが不正な要求を適切に拒否できるかを確認することが重要です。

APIは、アプリがサーバーに情報の取得や処理を依頼するための窓口です。事業者が想定する画面操作だけを確認しても、その窓口に直接届く要求への安全性までは説明できません。公開したアプリから通信の仕組みを知られた場合に、サーバーがどこまで自力で不正な操作を拒否できるか。その確認が必要になります。ここで、A2B攻撃という経路と、AIという支援手段は分けて捉える必要があります。A2Bという名称が指すのは、アプリの解析情報をバックエンドへの攻撃に利用する関係です。AIの利用が確認されたかどうかは、別に証拠を確かめるべき論点です。

AIの悪用について公表資料から分かること

一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）は10月15日、攻撃元サーバーの調査で、攻撃者がAIを利用して既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことを確認したと報告しました*2。Androidアプリの配布ファイルであるAPKの解析と、関連APIの脆弱性を調べた痕跡も紹介しています。さらにGMOサイバーセキュリティ byイエラエ株式会社は10月19日、日本企業に対する侵害事案の攻撃元インフラで、自律型ペネトレーションテストシステムARTEXの利用を確認したと公表しました*3。同社は調査対象の範囲を限定して記述しています。

また、CrowdStrikeは10月7日、韓国の金融機関を狙った活動に関係するインフラから、ARTEXの設定ファイルやAIツールのセッション履歴などを確認したと報告しています*4。さらにCrowdStrikeは10月29日、攻撃グループ「VAPOR PANDA」がARTEXを利用し、世界の200以上の組織を標的にした活動を報告しました*5。複数の組織に対する並行した侵入活動が確認されており、AIを利用した攻撃の規模拡大を示す事例といえます。ただし、これは国内のA2B攻撃とは別の調査結果です。

これらは、AIを使った攻撃を企業が現実の対応課題として扱う根拠になります。ただし、日本の不正アクセス全体に占める割合を示す統計ではありません。また、同じツールが使われたことだけで、各報告を同一の攻撃者による活動と結び付けることもできません。企業への示唆として考えたいのは、アプリやAPIの仕様を読み解く作業にAIが使われることで、個々のシステムを調べる負担が下がる可能性です。その場合、独自の仕様であることや、接続先が目立たないことを、安全性の根拠にし続けるのは難しくなります。これは公表された観測を踏まえた本稿の考察であり、攻撃時間の短縮率や被害の増加率を実測したものではありません。

AIを利用した攻撃と、Webアプリケーションの診断・監視については、こちらの記事でも解説しています。あわせてぜひご覧ください。
「AIエージェントを悪用したECサイト攻撃 ―カード情報窃取の報告から考える対策」

診断済みという説明に確認範囲を添える

A2B攻撃への備えとして、まず確認したいのは過去の診断報告書と依頼仕様です。アプリ本体、通信先のAPI、認証後に利用できる機能のうち、どこまでが対象だったのか。対象外となった機能や、その後に追加・変更された処理が残っていないか。診断の有無に加え、確認した範囲と時点を説明できる状態にすることが出発点です。

例えば、会員が自分の予約情報を確認するサービスを考えてみます。ログインできることと、その会員が対象の予約情報を閲覧してよいことは、別の確認です。認証では利用者本人であることを確かめ、認可では、その利用者にどの操作を認めるかを判断します。この例は説明のための仮定であり、今回の被害事例を再現したものではありません。

「OWASP API Security Top 10 2023」では、「オブジェクトレベルの認可不備（Broken Object Level Authorization：BOLA）」が最も重要なリスクの一つとして挙げられています。利用者がログイン済みでも、アクセスするデータごとに権限を確認する必要があります。診断を依頼する際には、画面の動作確認だけでなく、複数の利用者や役割の間でデータへのアクセスが適切に分離されているかも、確認項目に含めたいところです。また、NICTとJPCERT/CCは、認可不備に加え、SSRFやSQLインジェクションなどの脆弱性にも注意を呼びかけています。APIの診断では、利用者ごとのアクセス権限だけでなく、入力値の検証や外部への通信処理、不正な大量アクセスへの対策も確認する必要があります。

図：アプリから業務データまでの診断と運用の確認範囲

アプリから業務データまでの診断と運用の確認範囲の図
出典：国立研究開発法人情報通信研究機構（NICT）脅威情報分析チーム LETTICE、OWASP Foundation「API1:2023 Broken Object Level Authorization」「API9:2023 Improper Inventory Management」「Logging Cheat Sheet」をもとに弊社作成。
※個別事案の再現や攻撃成功率を示す図ではありません。権限管理を中心に示し、入力値検証など他の確認項目は省略しています。

認証と認可の違いや、予約情報へのアクセス制御については、skyticketの不正アクセス事例を取り上げた記事でも解説しています。あわせてぜひご覧ください。
「skyticketで約1,464万件の情報流出 ―3つの不正アクセス経路から考えるWebサービスのセキュリティ対策」

接続先の一覧を担当部署の境界で分断しない

APIの棚卸しでは、現在のアプリが利用する接続先だけを集めても十分とは限りません。OWASPは、管理が不十分な旧バージョンや不要な公開APIをリスクとして挙げ、APIの稼働環境、バージョン、アクセスを認める範囲などの管理を推奨しています。

この指摘を実務に落とし込むなら、APIの一覧に担当者、取り扱うデータ、診断日、停止できる条件を結び付ける方法が考えられます。アプリ開発会社は接続先を知っていても、サーバー運用会社は旧版APIを止めてよいか判断できない、といった状態を避けるためです。こうした管理項目は、本稿からの運用上の提案です。委託しているシステムについても、診断の責任範囲と修正の責任範囲を突き合わせます。重要なのは、担当を決めるだけでなく、対象外や未確認の箇所が残ったときに、誰が追加確認を手配するかまで決めておくことです。新しいAPIを追加する際にも、この一覧を更新する手順を組み込めます。

監視の記録を対応の判断につなげる

予防の点検と併せて、運用中に何を記録し、どう調査するかも確認します。OWASPの「Logging Cheat Sheet」は、利用者、操作対象、操作内容、結果といったアプリケーション固有の情報が、インフラのログだけでは得られない場合があると説明しています。この観点から、利用者と対象データの関係、通常と異なる取得量、権限の拒否状況などを追跡できるか検討します。ただし、記録を増やすためにパスワードやアクセストークンをそのまま保存するのは避け、必要な情報と保護方法を設計する必要があります。

さらに、異常を検知した後の連絡先や、APIの利用制限を決める担当者を、サービス運営側と共有しておきます。停止による業務影響を誰が評価するかも事前に決めておけば、調査の着手後に責任範囲の確認から始めずに済みます。監視を契約している場合も、APIの業務上の異常まで監視対象に含まれるかを確認したいところです。

AI時代の対策を具体的な確認事項に変える

A2B攻撃とAI悪用の報告を受け、企業は公開アプリから把握できるAPIと、これまで安全性を確認してきた範囲を照合する必要があります。未確認のAPIや機能があれば、認証・認可、入力値検証などの点検を進め、運用中の監視体制も見直すことが重要です。診断を依頼する際には、アプリ本体だけでなく、接続先のAPIやバックエンドサーバーも対象に含まれているかを確認してください。公開アプリとサーバーを一体で捉え、継続的に安全性を検証することが、A2B攻撃への備えにつながります。

【関連記事】
国内で相次いだ不正アクセス事例と、AI時代に企業が確認すべき対策を紹介しています。
「国内で相次ぐ情報漏洩・不正アクセス｜焼肉きんぐなど14事例とAI時代の対策」

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

skyticketで約1,464万件の情報流出 ―3つの不正アクセス経路から考えるWebサービスのセキュリティ対策

Share
skyticketで約1,464万件の情報流出アイキャッチ画像

旅行比較予約サイト「skyticket」を運営するアドベンチャーは2026年10月9日、顧客情報の流出に関する3件の不正アクセスを公表しました。さらに10月16日には、第2報として一部利用者のクレジットカード情報等の流出を発表しています。 発生した場所も、対象情報も一様ではありません。企業の対策に生かすには、個々の事案を分けて理解し、管理機能と利用者向け機能の双方で、アクセス制御が適切かを確認する必要があります。

※本記事は2026年10月16日時点までで確認できる公表資料に基づき作成しています。

【続報】skyticketの不正アクセスで新たな情報流出が判明

2026年10月30日の第3報では、銀行口座情報の流出や、過去のバックアップに保存されていた情報への影響が明らかになりました。追加調査で判明した内容と、企業が見直すべき情報管理のポイントを解説します。
▶ 続報記事「skyticket不正アクセス第3報」はこちら

約1,464万件の情報流出と3つの不正アクセス事案

10月16日の第2報では、サーバーへの不正アクセスにより、最大6,140名分のクレジットカード情報等が流出したことも判明しました。公式発表が整理した3つの経路と対象件数は下図の通りです。

図：skyticketの3つの不正アクセス経路と情報流出の概要

skyticketの3つの不正アクセス経路と情報流出の概要
出典：株式会社アドベンチャーの2026年10月9日および10月16日公表資料をもとに弊社作成
※約413万件は約1,464万件の内数です。第2報で判明したクレジットカード情報（最大6,140名分）はサーバー事案に関する追加情報です。3事案では件数の単位や調査状況が異なるため、合計を被害人数として扱うことはできません。

自社への教訓を考える際も、これらを一つの原因で説明しないことが重要です。管理機能からアクセスできる範囲と、利用者へ個人情報を返す機能のアクセス制御は、それぞれの担当者と仕様を確認する必要があります。

利用者が確認したい流出情報と注意点

同社は10月9日の発表でクレジットカード番号の流出を否定していましたが、10月16日の第2報で内容を訂正しました。2017年2月から2018年6月までに「skyticketプレミアム」の会費支払いに利用されたクレジットカード情報が、最大6,140名分流出したことが判明しています。対象にはカード番号、名義人名、有効期限が含まれますが、セキュリティコードは含まれていません。また、会員特典である「ベネフィット・ステーション」の会員ID、氏名、パスワードの流出も確認されています。同社は対象者にクレジットカードの利用明細の確認を求めるとともに、会員には公式サイト・アプリでのパスワード変更と、同じパスワードを使う他サービスでの変更を呼びかけています。

企業側の通知でも、どの情報が対象で、利用者に何をしてほしいのかを結び付けて伝える必要があります。氏名や連絡先、予約内容が対象であれば、単に「不審なメールに注意」とするだけでなく、問い合わせ先と確認方法を案内する方が、利用者は行動に移しやすくなります。

ハッシュ化されたパスワードも 流出後の対応が必要

パスワードのハッシュ化は、入力された文字列を一定の処理でハッシュ値に変換して保存し、元のパスワードをそのまま持たないための仕組みです。ただし、ハッシュ値が外部へ出た場合に、パスワードが絶対に判明しないことを意味するわけではありません。攻撃者がパスワードの候補からハッシュ値を計算して照合する攻撃に対し、解析を困難にする仕組みが重要です。

OWASPは、パスワード保存に適した方式や処理コストの設定、利用者ごとに異なるソルトの使用などを説明しています。ソルトとは、同じパスワードでも同じハッシュ値になりにくくするために加える値です。本件の発表では方式や具体的な設定までは示されていないため、解析の容易さを断定することはできません。企業が保管方法を点検する際は、「ハッシュ化しているか」という確認だけで終えないことが大切です。方式、設定値、ソルトの扱いを確認し、漏えい時に利用者へ変更を求める手順まで整えておきます。パスワードの安全な保存方法と、流出時の対応手順を併せて整備することが重要です。

認証と認可を分けて 予約情報へのアクセスを確認する

今回のバス予約ページの問題から、Webサービスの担当者が再確認したいのが認証と認可の違いです。認証は「誰であるか」を確認する処理、認可は「その情報や操作を許可してよいか」を判断する処理です。ログインできた利用者であっても、他人の予約情報を閲覧できていいわけではありません。

OWASPは、必要最小限の権限、原則としてアクセスを拒否する設計、リクエストごとの権限確認を推奨しています。URLが推測しにくいことや、画面にリンクが表示されないことだけを、アクセス制御の代わりにはできません。利用者と対象データの関係を、サーバー側で判断する設計が必要です。自社サービスの点検では、予約完了画面、マイページ、明細のダウンロード、APIなど、個人情報を返す機能を対象にします。未ログインの状態だけでなく、別の利用者として操作した場合や、権限を変更した後の状態も確認します。これは本件でAPIや別利用者の権限に問題があったと断定するものではなく、認可の確認を自社へ広げるための観点です。

公開アプリの解析情報を利用してバックエンドサーバーを狙うA2B攻撃については、関連記事「AI時代のA2B攻撃対策 ― アプリ診断で確認したいAPIの安全性」で解説しています。

管理機能の先にあるデータも 守る範囲に含める

今回の発表は、管理機能に使われた製品や具体的な操作方法を明らかにしていません。公表されていない製品や攻撃手法を、原因として推測することは適切ではありません。[1]企業側は、自社の管理機能からアクセスできるデータを確認するとよいでしょう。業務担当者に必要な操作、アプリケーションが必要とする接続権限、運用保守のための権限を区別し、それぞれが目的を超えて広がっていないかを点検します。必要最小限の権限は、画面の利用者にも、バックエンドの接続にも適用すべき考え方です。

第2報では、2018年7月にクレジットカード情報を自社サーバーで保管しない方式へ移行した際、会費支払いに関する記録（ログ）が削除されずに残っていたことが明らかになりました。このログは今回の不正アクセスで取得され、暗号化されたカード情報とともに、暗号化に用いる情報も不正に取得されていたため、情報が読み取られるおそれがあるとされています。この事案は、システム変更時に不要となったデータの削除状況や、ログに含まれる機密情報の管理を確認する重要性も示しています。

弊社が2026年10月8日に公表した提言でも、公開Webサービスの脆弱性修正、設定の適正化、認証・権限管理の徹底に加え、対策の実効性を継続的に確認することの重要性を指摘しています。新機能のリリース前だけでなく、運用中の変更がアクセス範囲を広げていないかを確かめることが重要です。

ブロードバンドセキュリティ（BBSec）「国内で相次ぐ不正アクセスを受け、
BBSecが公開Webサービスの基本対策の再点検を提言」（2026年10月8日）（https://www.bbsec.co.jp/news/20261008.html）

Webアプリケーション・APIの脆弱性を診断で確認

自社でログインできることは確認していても、許可されない操作が拒否されることまで十分に検証できているでしょうか。BBSecの「Webアプリケーション脆弱性診断」は、外部から動的に検証し、攻撃の入口になり得る問題の検出を支援します。開発時の確認に加えて、運用中のシステムにも定期的に活用できます。診断を検討する際は、顧客向けの画面だけでなく、業務管理機能、個人情報を返すAPI、利用者の役割ごとのアクセス範囲を伝えることが大切です。どの機能と権限の組み合わせを検証するかは、個別の対象や業務要件に合わせて調整します。さらに設計段階から見直したい場合には、要件定義・設計のレビューや開発標準の整備を支援する「Shift Leftコンサルティング」もご活用いただけます。

個人情報の収集・管理・提供に関わる各機能を横断的に確認することが、セキュリティ対策の抜け漏れを防ぐ第一歩です。自社のWebサービスでどこまで点検できているかを整理し、重要な情報を扱う範囲から具体的な検証につなげていきましょう。

【参考情報】

公開日：2026年10月20日
更新日：2026年11月9日

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

Siemens Software Centerの脆弱性が攻撃に悪用 ― DLLサイドローディングとClickFixの手口

Share
Siemens Software Centerの脆弱性が攻撃に悪用 ― DLLサイドローディングとClickFixの手口アイキャッチ画像

Siemensは2026年10月19日、Siemens Software Centerの脆弱性「CVE-2026-110936」が実際の攻撃で悪用されていると公表しました*6。攻撃者は、正規のデジタル署名が付いた実行ファイルと不正なDLLを組み合わせ、悪意あるプログラムを実行させていました。米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は10月20日、この脆弱性を「KEVカタログ（Known Exploited Vulnerabilities）」に追加しました。本記事では、Siemens Software Centerの脆弱性とDLLサイドローディングの仕組み、ClickFixによる攻撃手法を解説するとともに、企業が確認すべき更新対応や侵害の兆候、再発防止に向けた対策を紹介します。

図：署名の確認だけでは判断できない3つの確認ポイント

入口の確認画面、実行場所とDLL、端末の更新と動作をそれぞれ確認する図
出典：Siemens ProductCERT「Active Exploitation of CVE-2026-110936 in Siemens Software Center」、Microsoft Learn「Dynamic-Link Library Security」、Microsoft Security Blog「Think before you Click(Fix): Analyzing the ClickFix social engineering technique」を基に弊社作成。
※Siemensは、今回の攻撃による公式更新経路の侵害は把握していないと説明しています。

修正対象は4.0.9.8未満、既存環境は更新を確認する

Siemensが10月15日に公開したセキュリティアドバイザリ「SSA-580366」では、Siemens Software Centerの4.0.9.8未満の全バージョンが影響を受けるとされています。深刻度はCVSS v4.0で8.4（High）です。同製品は、購入したソフトウェアのダウンロード、インストール、更新などを行うアプリです。対処方法は4.0.9.8以降への更新で、既存のインストールは次回起動時に自動更新されると案内されています。

脆弱性は、アプリがDLLを探す場所の制御に関わります。アドバイザリは、認証済みのローカル攻撃者が探索先に細工したDLLを置くことで、アプリの権限で任意のコードを実行できると説明しています。管理者は対象端末と導入バージョンを確認し、自動更新の設定だけで完了とせず、更新後のバージョンも記録しておくと対応状況を追いやすくなります。

正規の実行ファイルが、不正なDLLを読み込む仕組み

DLLは、Windowsのアプリが動作に利用するプログラム部品です。Microsoftの説明によると、アプリが完全なパスを指定せずにDLLを読み込む場合、Windowsは決められた順序でフォルダーを探索します*2。攻撃者がその探索先に不正なDLLを置き、正規のDLLより先に見つけさせると、アプリの中で不正なコードが動くおそれがあります。

Siemensが確認した攻撃では、当時の最新版だったバージョン3.5.8.7の正規実行ファイルが悪用されました。実行ファイル自体は改変されておらず、攻撃者が同じフォルダーに配置した不正なDLLが読み込まれる構成でした。Siemensは、把握する限り、自社のシステムや製品、公式更新経路への侵害はなく、正規プログラムと不正ファイルの組み合わせは公式経路の外で配布されたと説明しています。

このため、調査では署名の有無だけでなく、実行ファイルの配置場所や周囲のDLL、起動の経緯を確認することが重要です。Siemensも、正規ファイルの特徴だけに頼らず、配置先や動作に着目するよう案内しています。正規のデジタル署名が付いていても、それだけで配布物全体の安全性を判断することはできません。

偽の本人確認でコマンドを実行させるClickFix

Siemensは、今回の脆弱性悪用が「Romulus」と呼ばれるClickFixキャンペーンに関連していると報告しています。

ClickFixとは、エラーの修正や人間であることの確認などを装い、利用者自身に不正なコマンドを実行させるソーシャルエンジニアリングの手法です。Microsoftは、偽のCAPTCHAや修復案内から、Windowsの「ファイル名を指定して実行」、ターミナル、PowerShellなどへ操作を誘導する例を解説しています。メールの添付ファイルを開かないよう注意していても、画面に出た「確認手順」を業務の続きとして実行してしまうと、別の入口が生まれます。Microsoftは、こうした誘導を見分ける教育と、業務に不要な実行機能の制限など、端末設定の強化を組み合わせることを勧めています*3。

社内への周知は、「怪しいサイトに注意」だけで終わらせず、ブラウザー上の確認画面からコマンドの貼り付けや実行を求められたときの行動まで決めておきたいところです。その場で操作を止め、画面と発生時刻を添えて管理部門に相談できるよう、連絡先をいつも使う社内ページに載せておくと迷いを減らせます。

更新の確認と、侵害の兆候を調べる作業を進める

更新作業では、会社として導入したSoftware Centerの所在とバージョンを把握します。一方、身に覚えのない場所から実行されているファイルについては、通常の更新作業に混ぜず、管理部門に調査を引き継ぐ運用が必要です。製品を利用している端末の管理と、攻撃者が持ち込んだプログラムの調査は、それぞれ対象を明確にして進めます。

Siemensは、侵害の兆候として、通常とは異なる場所からの「SiemensSoftwareCenter.exe」の実行や、身に覚えのない「SM Software Provisioning Service」フォルダーの作成、実行ファイルと同じ場所にある不審なファイルなどを挙げています*4。また、不正な通信先としてIPアドレスやドメインも公表しており、これらを用いたログ調査を推奨しています。侵害の兆候が確認された場合は、端末を隔離し、インシデント対応手順に従って調査する必要があります。更新状況の確認と侵害調査を分けて進め、導入履歴や正規の業務操作も担当者と確認しながら、対応の根拠を記録しておくことが重要です。

今回の事例を、セキュリティ教育と脆弱性対策につなげる

ブロードバンドセキュリティ（BBSec）は、社員・経営者・システム担当者に応じた情報セキュリティ教育と、自社に必要な情報を選別する「脆弱性情報提供」を用意しています。研修は内容のカスタマイズにも対応しています。

偽の本人確認や修復案内を見たときの判断を社内教育に取り入れたい場合は、対象者と実際の業務画面を踏まえ、BBSecに教材や研修内容を相談できます。また、更新対象を追う運用に課題がある場合は、利用製品に応じた脆弱性情報の収集・確認方法を相談することができます。利用者が不審な操作を見分け、管理者が脆弱性への対応を適切に進められるよう、教育と情報収集の両面から備えることが重要です。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

阪急阪神百貨店でH2O ID約126万件の情報漏洩 ―予約サイトの追加被害とWebサービスの確認点

Share
阪急阪神百貨店でH2O ID約126万件の情報漏洩アイキャッチ画像

エイチ・ツー・オー リテイリング株式会社と株式会社阪急阪神百貨店は2026年10月19日、第三者による不正アクセスにより、会員ID「H2O ID」約126万件の個人情報の一部が漏洩したと発表しました。10月30日の第2報では、予約サイトの入力フォームに記載された情報6,243件の漏洩が新たに判明した一方、通販関連2サービスについては顧客情報の外部漏洩が確認されなかったことを公表しています。今回の事案を踏まえ、予約サイトやECサイトを運営する企業が確認しておきたい、顧客情報へのアクセス制御やWebサービスのセキュリティ対策について解説します。

※本記事は2026年11月6日時点で公表されている情報を基に作成しています。

図：予約・通販システムの3つの確認観点

Webサービスのセキュリティ確認観点として、画面とAPI、アクセス権限、操作ログの3つを示した図
出典：OWASP Foundation「Attack Surface Analysis Cheat Sheet」「Authorization Cheat Sheet」「Logging Cheat Sheet」を基に弊社作成
※一般的なWebサービスのセキュリティ確認観点を示したものであり、本件の攻撃経路や原因を示すものではありません。

漏洩が確認された情報と追加調査の結果

株式会社阪急阪神百貨店は2026年10月19日、同社が運営する予約サイトや通販サイトで不正アクセスが発生したと発表しました*5。10月16日には予約サイトを通じた顧客管理システムへの不正アクセスを確認し、翌17日には通販関連サービス「HANKYU HANSHIN E-STORES」と「Remo Order」でも不正アクセスを確認しました。各サービスのシステムを停止し、調査を進めた結果、H2O ID約126万件について、氏名、メールアドレス、住所、電話番号などの個人情報の一部が漏洩したことが判明しました。10月30日の第2報では、予約サイトの入力フォームに記載された申し込み情報など6,243件（予約総数188,590件の約3％）の漏えいが新たに確認されました*2。一方、「HANKYU HANSHIN E-STORES」と「Remo Order」については、顧客情報の外部漏洩は確認されなかったと発表しています。

なお、両社は引き続き詳細調査を進めています。現時点で不正アクセスの原因となった具体的な脆弱性は公表されておらず、特定の脆弱性や認可の不備を原因と断定することはできません。

Webサービスと顧客情報の連携を把握する

ECサイトや予約システムのセキュリティを点検する際は、利用者が操作する画面と、その処理で参照・更新される顧客情報との関係を把握することが重要です。サイトや機能の一覧だけでなく、システム間のデータの流れも整理しておきます。

OWASPの「Attack Surface Analysis Cheat Sheet」は、攻撃の入口になり得る箇所だけでなく、データが出ていく経路、アクセス制御、保護すべき情報を含めてシステムを把握する考え方を示しています。登録、ログイン、検索、注文などの操作に沿って、情報がどこに保存され、どの別システムに触れるかを確かめる方法です。点検では、予約情報の入力から保存までの流れを追い、連携先のシステムや利用するアカウントを確認します。複数のサービスが同じ顧客情報にアクセスする場合は、その接続も診断範囲に含めるか検討し、サービスの追加・変更に合わせて構成図と点検範囲を更新することが重要です。

認証・認可の適切な設定を確認する

本人であることを確かめる「認証」と、特定の情報や操作へのアクセスを許す「認可」は別の確認です。OWASPは両者を区別し、ログイン済みの利用者であっても、すべての情報にアクセスできるわけではないと説明しています。会員向けのWebサービスでは、この区別が点検の基本になります。

たとえば注文履歴や予約内容を表示する機能では、対象データにアクセスできる権限があるかを、要求ごとに確かめる設計が必要です。OWASPは、必要最小限の権限、原則として拒否する設定、すべてのリクエストでの権限確認を推奨しています。画面上で操作を隠すだけでなく、サーバ側の処理で判断することが要点です。点検では、一般会員や管理者などの権限ごとに、許可された情報へのアクセスや操作だけが実行できるかを確認します。業務上必要な操作とテスト項目を対応させることで、アクセス制御の不備を発見しやすくなります。

不正アクセスの検知・調査に必要なログを残す

不正アクセスの調査では、接続があったという記録に加え、利用者や権限、対象データ、処理結果を理解できるアプリケーションのログが役立ちます。OWASPは、認証や認可の失敗、管理者操作、データの出力などを記録対象として挙げています。ログの取得項目は、システムの設計段階から検討しておくことが重要です。保存期間やアクセス権限も含め、異常の検知や原因調査に必要な情報を記録できるようにします。単にログの量を増やすのではなく、実際の調査に活用できる内容になっているかを確認することが大切です。

WebとAPIの診断を業務の流れに合わせる

Webサービスのセキュリティ対策として、WebアプリケーションやAPIに潜む脆弱性を定期的に確認することも重要です。ブロードバンドセキュリティ（BBSec）では、「Webアプリケーション脆弱性診断 SQAT® for Web」を提供しています。攻撃者の手法を用いた外部からの動的な診断により、攻撃の入口になり得る弱点を確認します。開発時だけでなく、稼働中のシステムを定期的に診断する場面にも対応しています。診断を相談する際は、公開URLに加え、会員や管理者の役割、扱う情報、APIによる連携、重要な業務操作を共有し、対象範囲をすり合わせましょう。新規開発や大きな改修であれば、要件定義や設計のレビュー、開発標準の作成を支援するBBSecの「Shift Left コンサルティング」もご活用ください。

Webサービスの安全性を確保するために

予約サイトやECサイトでは、複数のシステムが顧客情報を共有する場合があります。こうした環境では、公開画面だけでなく、システム間のデータ連携やアクセス権限、操作ログを含めた確認が重要です。WebアプリケーションやAPIの脆弱性診断、開発段階でのセキュリティ対策については、BBSecへご相談ください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

ConnectWiseの不正アクセスでCloud Backupに影響 ―Microsoft 365の連携アプリをどう調べるか

Share
ConnectWiseの不正アクセスでCloud Backupに影響 ―Microsoft 365の連携アプリをどう調べるかアイキャッチ画像

ConnectWiseは2026年10月16日、Cloud Backup（旧SkyKick）に関係する連携アプリへの不正アクセスを公表しました。これを受け、Cloud Backupと、予防措置としてSaaS Security、Cloud Managementが一時停止されました。その後、10月28日から段階的な復旧が始まり、11月4日時点では多くのパートナーがMicrosoft 365テナントの再登録を進めています。Microsoft 365の管理者が確認したいのは、サービスの復旧状況だけではありません。自社の環境に残る連携アプリの権限と、そこで行われた操作の記録です。

※本記事は2026年11月6日時点で公表されている情報を基に作成しています

図：M365の連携アプリを調べる3つの視点

連携アプリの確認を、対象の特定、認証と変更の照合、証拠に基づく判断に分けた図
出典：Microsoft Corporation「Application and service principal objects in Microsoft Entra ID」「What are Microsoft Entra sign-in logs?」、ConnectWise, LLC「Cloud Backup technical investigation and remediation guide」
※各項目は調査の視点を示したものであり、対応完了や安全性を保証するものではありません。

保存済みバックアップと、稼働中のMicrosoft 365は分けて考える

ConnectWiseの発表によると、Cloud Backupに保存されているバックアップデータは暗号化され、稼働中の環境から隔離された状態で保管されています。同社は、これらのバックアップデータが侵害された兆候は確認されていないと説明しています*3。ただし、これは稼働中のMicrosoft 365環境に影響がなかったことを示すものではありません。10月28日から新しいアプリ「ConnectWise Cloud Backup for M365」を使用したバックアップ・復元機能の段階的な復旧が始まり、利用企業にはテナントごとの再認可が求められています。11月4日時点では一部機能の復旧作業が続いており、各テナントでの不正な変更やアクセスの有無についても引き続き確認が必要です。

業務上は、セキュリティ調査とバックアップの復旧状況を確認する担当者を決めておくと、対応を整理しやすくなります。バックアップが正常に再開されているか、必要なデータを復元できるかを確認するとともに、調査結果と業務への影響を関係者間で共有することが重要です。

サービスプリンシパルは、連携先が自社環境で動くためのID

Microsoft Entra IDでは、アプリケーションの定義を保持するオブジェクトと、各テナントでそのアプリを表すサービスプリンシパルが分かれています。サービスプリンシパルは、各テナント内でアプリを表すIDであり、そのアプリに付与された権限などを確認する際の対象となります。利用者企業の管理画面では「エンタープライズアプリケーション」から確認できます。

外部のクラウドサービスを利用する場合、サービス提供者側のアプリ登録と、自社側のサービスプリンシパルは同じ管理対象ではありません。Microsoftの説明でも、複数の組織で使うアプリには、利用する各テナントに対応するサービスプリンシパルが存在します。この構造を押さえると、提供者の対策完了という連絡と、自社が行う権限確認を別々に管理する理由が見えてきます。

接続の無効化、認証情報の失効、残された権限の調査を混同しない

ConnectWiseの技術ガイドによると、同社は10月17日に対象の7つのアプリケーションIDを無効化し、関連する認証情報を失効させました*2。また、10月19日には影響を受けたCloud Backup環境のアカウントと認証情報の全面リセットを完了しています。一方、提供者側の措置によって各利用者テナントの設定が自動的に変更されるわけではなく、発行済みトークンが有効な間のアクセスや、別に追加された認証情報・権限は個別の確認が必要です。

調査は自社だけでなく、管理を受託する顧客の各テナントでも行います。対象を表示名だけで判断せず、ガイドにあるApplication IDと照合し、ローカルのObject IDも記録します。対象アプリは調査の初動で安易に削除せず、設定と証拠を保全したうえで、ConnectWiseの案内に従って必要な対応を進めます。ログの保存を待って緊急の封じ込めを遅らせないことも、同ガイドの注意点です。次に、認証の記録と、その後に何が変更されたかを照合します。技術ガイドは、認証情報、所有者、同意された権限、ディレクトリロール、メール転送などの調査を案内しています。認証に成功した記録だけで情報流出と断定せず、取得できたログの範囲と欠落を記録することが大切です。

人のログインだけを見ていないか、監視の対象を見直す

Microsoft Entraのサインインログには、対話型・非対話型のユーザーサインインに加え、サービスプリンシパルとマネージドIDのサインインがあります。また、設定変更の把握には監査ログを使います。ユーザーのログインだけでなく、アプリの認証や設定変更も含めて確認することが重要です。平時の運用でも、連携を承認した部署、利用目的、必要な権限、変更時の連絡先を一緒に残しておくことを勧めます。調査中に見慣れない権限が見つかったとき、承認済みの設定と比較できるためです。外部サービスの導入時だけでなく、契約終了や担当者交代の際にも、この記録を更新する運用が役立ちます。

ログを集める運用から、判断につながる分析へ

ブロードバンドセキュリティ（BBSec）の「SIEM運用／分析」は、Splunkに集約したログを専門技術者が監視・分析し、複数のイベントを関連づけて調べるサービスです。相関分析のルールを調整し、アラートの品質向上を図ります。ログは保存できていても調査の担当や判断基準が定まっていない場合に、運用を整える選択肢になります。Microsoft 365の連携アプリを含むログ監視については、取得可能なログや保存期間、対象テナント、対応時の役割分担を整理することが重要です。BBSecでは、これらの条件を踏まえたログ分析・監視体制について相談を受け付けています。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

Cuenote FC不正アクセスで延べ約5,163万件の情報漏洩 ―影響範囲と委託先管理の課題

Share
Cuenote FC不正アクセスで延べ約5,163万件の情報漏洩アイキャッチ画像

ユミルリンク株式会社は2026年10月26日、Cuenote FCへの不正アクセスの第二報を公表しました。利用企業が確認したいのは、自社のどの情報が対象で、調査でどこまで判明しているかです。本記事では公表件数の読み方を整理するとともに、委託先の管理権限やセッション、操作ログを点検する際の実務を考えます。

※本記事は2026年11月6日時点で公表されている情報を基に作成しています。

FCは49システム 延べ件数はなお調査中

ユミルリンク株式会社は10月19日の第一報で、Cuenote FCの専用ASPプラン5システムから延べ約900万件の情報が出力されたと公表しました*3。その後の調査で対象は49システムに拡大し、漏えいのおそれがある件数は延べ51,628,280件となりました。うち16システムは件数調査中で、今後増える可能性があります。また、顧客管理システムCuenote BASEでは、契約者情報190件が閲覧可能な状態にあったことも公表されています。Cuenote FCの対象情報には、メールアドレスのほか、氏名、都道府県、生年月日などの付属情報が含まれます。登録内容は利用企業によって異なるため、個別の影響範囲は各社の調査結果を確認する必要があります。

同社は、対象サーバーの切り離し、脆弱性の修正、サポート・品質管理担当者の認証情報の削除、不正プログラムの検知体制の整備などを実施しています。また、影響が新たに確認された利用企業には、10月26日までに個別連絡を行ったとしています*2。利用企業は、社内の確認結果に日付を添え、追加連絡があった際に判断を更新できるよう、確認した対象や未確認の項目を記録しておくことが重要です。

図：Cuenote FC不正アクセスの影響範囲（2026年10月26日第二報より）

Cuenote FC不正アクセスの影響範囲
出典：ユミルリンク株式会社「当社システムへの不正なアクセスに関するご報告（第二報）」（https://www.cuenote.jp/support/news-incident.html）を基に弊社作成。
※FCの公表件数は延べ件数であり、被害人数や確定した最終総数を示すものではありません。件数調査中の16システムは49システムに含まれます。BASEの190件は別集計であり、FCとの合算はできません。

認証情報とセッション情報の悪用を分けて読む

同社は、プログラムの脆弱性を通じたサポート・品質管理担当者の認証情報の取得、不正プログラムによるデータ出力、他システムへの認証試行を確認しています。その後の調査では、他システムのデータ参照や、セッション情報を使った不正ログインも判明しました。この説明を、すべての利用環境で同じ侵入経路が成功したという意味に広げることはできません。自社が受け取った個別通知では、利用環境へのアクセスが確認されたのか、データ出力が確認されたのか、対象の情報項目まで判明しているのかを分けて確認することをお勧めします。

パスワード変更と ログイン状態の失効を確認する

セッションは、Webサービスが同じ利用者とのやり取りを継続して扱うための仕組みです。ログイン後の処理でも利用者を識別し、アクセス権を適用するために使われます。OWASPの「Session Management Cheat Sheet」は、セッションの有効期限を設け、終了時にはサーバー側で無効化することを求めています。

事故対応の手順では、パスワードなどの認証情報の変更と、既に成立したセッションの失効を別々の確認項目にすると、対応範囲を整理できます。OWASPはパスワード変更やアカウント侵害の検知など、リスクの高い事象の後に再認証を求める考え方も示しています。ブラウザーを閉じたりCookieを削除したりするだけで、サーバー側のセッションまで無効になったとは限りません。

外部サービスの利用企業であれば、自社の管理画面で実行できる操作と、提供事業者の対応が必要な操作を確認しておきます。例えば、全端末のログイン状態を終了できるか、実施後に再認証が求められるか、完了をどの記録で確認するかを、問い合わせ項目として整理する方法があります。これは一般的な点検の提案であり、Cuenote FCの機能や今回の対応の完了状況を示すものではありません。

サポート担当者が扱える環境と操作を把握する

管理アカウントを確認するときは、ログインの可否に加えて、その後に何ができるかを見る必要があります。OWASPの「Authorization Cheat Sheet」は、本人であることを確認する認証と、操作を許す認可を区別しています。業務に必要な最小限の権限を与え、要求ごとに適切な権限を確認する考え方です。

委託先への確認では、サポート業務で利用する権限の範囲と、承認の方法を説明してもらうと、契約上の表現と実際の運用を照合しやすくなります。どの環境に接続でき、閲覧・変更・データ出力のうち何を許しているかを整理します。作業が終わった後の権限や、不要になったアカウントをどう見直すかも確認したいところです。

自社でシステムを管理する場合には、想定した権限が実装でも守られているかを、管理権限のある試験環境で確かめます。OWASPも、設計した権限の検証と運用後の定期的な見直しを勧めています。担当者の異動や業務の変更を反映し、現在の仕事では不要になった操作権限が残っていないかを点検します。

ログインの成功だけでなく データ出力まで追える記録を

調査では、ログインできたことと、どの情報を取り出したかを別々に確かめます。OWASPの「Logging Cheat Sheet」は、認証の成功・失敗に加え、利用者管理や権限変更、データの入出力などを記録対象に挙げています。アプリケーションの記録には、利用者の権限や処理対象、結果といった、ネットワーク機器だけでは得られない情報も含まれます。

実務では、時刻や利用者を手がかりに、アクセス記録とデータ出力の操作記録を突き合わせます。出力した処理は見つかっても、その内容を特定できるかは別の確認になります。どの記録を調べ、どこまで分かり、何が未確認なのかを報告書に残すと、利用企業と提供事業者の間で認識を合わせやすくなります。

記録の取り方にも配慮が必要です。OWASPは、セッション識別子やアクセストークン、パスワードなどを直接ログへ残さず、除去やマスキング等を検討するよう示しています。[4] 調査に必要な識別ができることと、認証情報そのものを保存することを混同せず、収集項目を決めておきます。

配信を委託した後も 預けた情報と連絡手順を管理する

メール配信サービスの委託先管理では、預ける情報の内容を踏まえた評価が必要です。NISTのサプライチェーンリスク管理ガイドは、事業上の重要性、保存・処理するデータの機微性、自社システムへのアクセスの程度などから、提供事業者の重要度を判断する考え方を示しています。関係する事業者を、インシデントの計画・対応・復旧に含めることも挙げています。

また、利用企業側でも影響が明らかになっています。NTTPCコミュニケーションズ株式会社は11月2日、60,929件の情報漏えいを公表しました*3。また、エクスプレス予約では11月5日、172,735件の情報が対象となることを公表しています*4。自社で登録した配信先データの項目と利用目的、管理する部門を整理しておけば、通知を受けた際に自社の登録内容と照合できます。提供事業者から届く調査結果についても、受領窓口と社内の確認担当を決め、追加情報が出た際の共有先をそろえておきます。

NISTは、事業者との役割分担や情報共有・報告の手順を定めることも求めています。契約時の確認に加えて、事故時にどの情報を受け取り、誰が影響を判断するかまで具体化することが、委託先からの連絡を実際の対応につなげるうえで役立ちます。

委託先の利用を含めて 情報管理の現状を点検する

メール配信サービスを利用する企業は、委託先に預けている情報を把握し、インシデント発生時の確認事項や対応手順を明確にしておくことが重要です。ブロードバンドセキュリティ（BBSec）の「情報セキュリティリスクアセスメント」は、文書や運用実態の確認を通じて課題を整理し、対策の優先順位とロードマップの策定を支援します。外部サービスの利用管理を含め、自社の情報セキュリティ対策を見直す際にご相談いただけます。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

HTTP2Shellの脆弱性に続報 ― CISAが悪用を確認、.NETなど影響製品の対策

Share
HTTP2Shellの脆弱性に続報 ― CISAが悪用を確認、.NETなど影響製品の対策アイキャッチ画像

HTTP2Shell（CVE-2026-111497）について、実際の悪用を踏まえた注意喚起と、各製品の対応情報が相次いで公開されています。JPCERT/CCは2026年10月26日に注意喚起を公表し、米国CISAも27日に本脆弱性をKEVカタログに追加しました。今回の脆弱性はNode.jsだけでなく、Brotliを組み込む複数の製品に影響します。対応では、ライブラリや実行環境の更新に加え、コンテナーや配布済み実行ファイルに修正が反映されているかを確認する必要があります。本記事では、追加の注意喚起と製品別の対応情報を整理します。

HTTP2Shellの悪用確認とBrotliへの影響

今回調べる対象は、HTTP/2自体の欠陥ではなく、Brotliの展開処理です。同じC実装を組み込む製品にも影響するため、Node.jsの利用有無だけでは判断できません。

Node.jsの公式告知によると、不正な圧縮データを処理した際に、本来のエラーを入力待ちと扱うことで処理が続き、内部バッファの範囲を超えた書き込みが発生します。攻撃者のデータをアプリケーションが展開することが問題の入口です。深刻な影響があり得るという説明と、個々の環境で攻撃が成功したという事実は分けて受け止める必要があります。

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は10月27日、本脆弱性をKnown Exploited Vulnerabilities（KEV）カタログに追加しました。KEVは実際の悪用が確認された脆弱性を掲載するもので、今回の登録は対応を優先する重要な根拠となります。ただし、登録された事実だけで、日本国内での被害や、すべての製品・構成での攻撃成功が確認されたことを意味するわけではありません。

【関連記事】
HTTP2Shellの脆弱性の仕組みや、Node.js・Pythonなどへの影響、主な攻撃経路と修正版については、前回の記事で詳しく解説しています。
▶記事はこちら「HTTP2Shellとは？」

修正版はライブラリと製品の両方で確認する

Brotli本体では、1.2.1、1.1.1、1.0.10が修正版として10月21日に公開されています。JPCERT/CCが示す対象は、1.2.0以上1.2.1未満、1.1.0以上1.1.1未満、1.0.3以上1.0.10未満です。製品に組み込まれたBrotliについては、その製品の開発元が出す対応情報に従います。

Node.jsでは、22.x、24.x、26.xの各系列に対し、22.23.4、24.22.1、26.12.1が公開されました*5。公式告知はサポート終了版の利用を続けず、更新されたバージョンを使うよう求めています。実際の更新では、利用する系列のサポート状況を確認し、今回の修正を含む後続の更新版が公開されている場合は、その適用も検討してください。

管理台帳には、サービス名に加えて、実行環境の製品名、現在のバージョン、提供元の修正版、更新担当を残しておくと確認が進めやすくなります。委託先が運用するシステムも同じです。「Brotli対応済み」という回答だけでなく、どの製品をどの版へ更新したかを確認する運用が考えられます。

外部サイトから取得するレスポンスも確認対象に

Vercelは、Node.jsアプリケーション自身や利用ライブラリが、攻撃者の用意したBrotliデータを展開する場合に影響を受けると説明しています*2。その入口には、受信するリクエスト本文と、別のサーバーから取得するレスポンスの両方があります。

同社はVercel WAFによる防御も案内していますが、その対象はVercelのネットワークを通過する通信です。関数が外部サーバーから取得する応答はWAFの対象外であり、更新の代わりにはならないと明記しています。そのため、Webサイトの入口に対策を適用したかどうかと、外部データを取り込むアプリケーションに修正が反映されたかどうかは、それぞれ確認する必要があります。調査の際は、受信データを展開する機能と、外部へ接続して応答を展開する機能を分けて確認すると整理しやすくなります。通信先を一覧にするだけではなく、取得後にどのライブラリや実行環境がデータを処理するかまで担当者に確認してください。

図：Brotli展開処理に届く二つのデータ経路

Brotli展開処理に届く二つのデータ経路の図
出典：Vercel Inc.「Node.js security advisory: Brotli decoder RCE (CVE-2026-111497)」、Node.jsプロジェクト「Wednesday, October 21, 2026 Security Releases」の情報をもとに弊社作成。
※受信リクエストと外部から取得するレスポンスが、アプリケーションの展開処理へ届く関係を整理しています。製品・構成により利用する処理は異なり、すべての環境で攻撃が成立することを示す図ではありません。

.NETでは既定の構成と有効化した機能を区別する

Microsoftが10月25日に公表した.NETのアドバイザリは、ASP.NET CoreとHttpClientが既定の構成ではBrotliを自動展開しないことを明記しています*3。影響の判断には、Brotliの展開を有効にした設定や、展開APIで攻撃者が制御するデータを扱う処理の確認が必要です。.NET Frameworkは影響を受けません。また同社は同日、今回の脆弱性に対応する臨時のセキュリティ更新を公開しました。修正版は.NET 8が8.0.33、.NET 9が9.0.22、.NET 10が10.0.14です。更新後はアプリケーションの再起動が必要で、自己完結型（self-contained）アプリケーションやNativeAOTで作成した実行ファイルについては、再ビルドと再配置も必要になります。

更新までの対策として、同社は信頼できないBrotliデータの展開を避ける方法を示しています。ただし、設定例は既に展開を有効化しているアプリケーションを変更するためのものです。対策例をそのまま追加して、それまで無効だった自動展開を新たに有効化しないよう注意が必要です。導入済みパッケージだけで結論を出さず、実際の設定と処理を照合してください。

コンテナーと配布済み実行ファイルまで更新を反映する

Red Hatは10月27日更新の情報で、RHELやUBIを基にしたコンテナーについても確認を求めています*4。ベースイメージが更新された場合には、それを利用する顧客側のコンテナーを再ビルドする必要があるとしています。ベースイメージの修正情報を確認する作業と、自社のイメージを作り直す作業は別に管理する必要があります。

Bunにも、更新を配布物へ反映する際の注意点があります*5。公式アドバイザリによると、bun build –compileで生成した実行ファイルにはBunランタイムが含まれます。影響を受ける版で作った実行ファイルは、開発環境のBunだけを更新しても修正されません。Bun 1.4.4へ更新し、該当する実行ファイルを再ビルドするよう案内されています。

AWSも10月28日に本脆弱性に関するセキュリティ情報を公開し、30日に更新しました*6。AWS Lambdaについては、マネージドサービス自体と、関数で使用するランタイムの影響を区別しています。Node.jsや.NETのランタイムを使用する場合は、AWSが公開する対応状況を確認するとともに、利用者側で管理する依存ライブラリやデプロイ済みの構成についても確認が必要です。

対応完了の記録には、更新ファイルの入手だけでなく、稼働環境への適用と確認結果も残します。修正済みの構成を用意できた時点と、その構成でサービスが実際に動作している時点を区別すれば、再配置待ちの環境を見つけやすくなります。HTTP2Shellへの対応は、Brotliという部品の所在から始め、製品、コンテナー、配布済みプログラムへと確認を進めることが大切です。

HTTP2Shellへの対応では、脆弱なBrotliを使用しているかだけでなく、攻撃者が用意したデータが展開処理に届くか、修正版が稼働環境まで反映されているかを確認することが重要です。ライブラリや実行環境の更新情報を継続的に把握し、コンテナーや配布済み実行ファイルも含めて対応状況を管理する必要があります。

脆弱性情報の収集・管理を効率化しませんか？

利用している製品やライブラリの脆弱性情報を継続的に把握するには、システム構成情報と関連付けた管理が重要です。ブロードバンドセキュリティ（BBSec）の「脆弱性情報提供　SAS（Secure Net Alert Mail Service）」は、登録されたシステム情報に基づいて脆弱性情報を絞り込み、配信するサービスです。対応状況を管理する機能も備え、日々の脆弱性管理を支援します。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

HTTP2Shellとは ―Node.jsやPythonに広がるBrotli脆弱性の影響と対策

Share
HTTP2Shell（CVE-2026-111497）とは？影響製品と対策を解説アイキャッチ画像

WebサイトやAPIの安全性を確認する際は、外部からのリクエストだけでなく、アプリケーションが受信するレスポンスにも注意が必要です。HTTP2Shell（CVE-2026-111497）は、GoogleのBrotliデコーダーに存在する脆弱性で、細工された圧縮データの展開によって、情報漏洩や任意コード実行につながるおそれがあります。Node2Shellとも呼ばれるこの問題は、Node.jsに加え、Python関連パッケージやBun、Envoyなど幅広い製品に影響します。本記事では、主な攻撃経路、影響を受ける製品、修正版と対策を解説します。

【続報】HTTP2Shellの悪用確認と影響製品の追加情報

米国CISAが本脆弱性をKEVカタログに追加しました。.NETなどの影響条件や、コンテナー・配布済み実行ファイルへの修正反映について、続報記事で解説しています。
▶ 記事はこちら「HTTP2Shellの脆弱性に続報」

HTTP2ShellとNode2Shellの関係

Brotliは、Webコンテンツなどのデータを小さくするために使われる圧縮方式です。HTTP通信では、本文がBrotli形式で圧縮されていることをContent-Encoding: brというヘッダーで示します。本脆弱性は、当初Node.jsへの影響が注目されたことから「Node2Shell」と呼ばれていました*7。その後、Brotliを利用する複数の製品にも影響が及ぶことが明らかになり、「HTTP2Shell」という呼称も使われるようになりました。なお、名称にHTTPが含まれていますが、HTTP/2通信に限定された脆弱性ではありません。

問題があるのは、圧縮されたデータを元に戻すデコーダーです。不正なデータの処理を打ち切るべき場面で処理が続き、内部バッファの範囲を超えて書き込むことがあります。結果として、プロセスの停止やメモリ内の情報漏洩、条件によっては遠隔からの任意コード実行（RCE）につながります。

Googleが登録したCVEレコードの評価はCVSS v4.0で9.2、深刻度はCriticalです。一方、Node.jsの公式告知ではHighに分類されています*2。確認すべきなのは、脆弱なBrotliデコーダーを使用し、攻撃者が用意したデータがそこに届くかどうかです。

HTTPリクエストとレスポンスの両方が攻撃経路になる

受信側では、WebアプリケーションがBrotli圧縮されたリクエスト本文を展開する経路が問題になります。Impervaは、Express 5やbody-parser 2系でBrotli圧縮された本文を展開する構成で、細工したデータがNode.jsに内包されるデコーダーへ渡るケースを検証しています*3。⁠

もう一つは、アプリケーションがHTTPクライアントとして通信する経路です。Node.jsの組み込みfetchがBrotli圧縮された応答を展開すると、接続先のサーバーが返したデータがデコーダーに届きます。公開APIへの入力対策とあわせて、外部サイトから情報を取得する機能にも目を向ける必要があります。

図1：HTTP2Shellで確認する二つの攻撃経路

脆弱なBrotliデコーダーに細工されたデータが届く二つの攻撃経路を示した概念図
出典：Imperva, Inc.、Bunプロジェクトの公開情報をもとに作成。
※任意コード実行の成立条件は製品や構成によって異なります。

影響を受ける製品と修正版

影響調査では、開発言語の名前だけで範囲を区切らないことが大切です。Pythonの場合は、Python本体全体の問題として扱うのではなく、Brotliやbrotlicffiといったパッケージの導入状況を調べます。urllib3やrequestsなどは、これらのパッケージが利用できる環境でBrotli応答を自動展開するため、アプリケーションのコードにBrotliの呼び出しが見当たらなくても確認が必要です。

表1：主要コンポーネントの修正版と確認する条件

コンポーネント修正版確認する条件
Google Brotli1.0.10／1.1.1／1.2.11.0.3～1.0.9、1.1.0、1.2.0
Node.js22.23.4／24.22.1／26.12.1各系列の未修正版。内包するデコーダーの利用経路を確認
Python関連パッケージBrotli 1.2.1
brotlicffi 1.2.1.0		仮想環境やコンテナーごとの導入状況を確認
Bun1.4.41.0.21以上1.4.4未満。コンパイル済み実行ファイルも確認
Envoy1.40.0／1.39.3／1.38.6／1.37.8／1.36.12Brotli展開フィルターを設定した環境
Istio1.31.2／1.30.6／1.29.9Brotli展開を有効にした環境。1.29系はサポート終了
出典：Google LLC、Node.jsプロジェクト、GitHub Advisory Database、Bunプロジェクト、Envoy Proxyプロジェクト、Istioプロジェクトをもとに作成。
※主要コンポーネントの修正版と確認条件を整理しています。バージョン番号は各開発元の公表値です。影響製品を網羅したものではなく、利用環境に応じて各製品の公式情報を確認してください。

Node.jsの22・24・26系列で公開されたセキュリティ更新について、修正版やTLS証明書検証の問題、企業が確認すべき更新対応を解説しています。
関連記事：「Node.jsに10件の脆弱性 ―Brotliのリモートコード実行リスクと修正版」

EnvoyではBrotliの展開フィルターを設定した環境、IstioではEnvoyFilterなどを使ってBrotli展開を有効にした環境が確認対象です。製品名が一致するだけで、すべての構成が同じ攻撃経路を持つとは限りません。反対に、別製品に内包されたライブラリは、アプリケーションの依存パッケージ一覧だけでは見落とすおそれがあります。

コード実行の実証と実際の攻撃を分けて読む

Impervaは、公式のNode.js 24.22.0のLinux arm64イメージを用いた実験で、細工したBrotliデータによるコード実行を報告しています。修正版の24.22.1では同じ入力が拒否されました。ただし、実験環境では成功まで複数回の試行を要しています。この結果を、すべてのOSや構成で同じ攻撃が成立するという意味に広げることはできません。

また、研究環境での実証は、実際の組織に対する攻撃成功の報告とは別です。CVEレコードに収録されたCISAの評価では、2026年10月23日時点のExploitation（悪用状況）が「none」とされています。ただし、これは評価時点の情報であり、その後の悪用の有無を保証するものではありません。修正の優先順位は、被害報告の有無だけでなく、自社環境で攻撃者が用意したデータが脆弱な展開処理へ届くかどうかを踏まえて判断する必要があります。

Go向けBrotli実装にも関連する報告があります。Sweet Securityはv1.2.6でpanicと接続切断を再現しましたが、その実験ではアプリケーション全体は動作を続けていました。Go実装で任意コード実行やプロセス全体の停止が実証されたわけではありません*4。メンテナーは10月23日に修正コミット33c2a98による対応を報告しています*5。

更新する対象を実行環境まで追う

Node.jsを使う環境では、Brotliを内包するNode.jsランタイムそのものを更新する必要があります。Pythonでは仮想環境ごとにパッケージを確認し、コンテナーを使っている場合は、更新後の構成でイメージを再ビルドして再配置します。管理画面に表示された設定値だけでなく、稼働中のプロセスに修正が反映されていることまで確認します。

Bunでは、bun build –compileで作成した実行ファイルにランタイムが埋め込まれます。開発端末のBunを更新しても、すでに配布した実行ファイルは自動では直りません。公式告知はBun 1.4.4への更新と、該当する実行ファイルの再ビルドを求めています*6。製品に組み込まれたBrotliを修正するには、製品側の更新が必要になる点に注意してください。

図2：影響確認から修正の反映までの流れ

影響確認から修正版の適用までの対応を整理した概念図
出典：Node.jsプロジェクト、Aikido Security BV、Bunプロジェクト、Envoy Proxyプロジェクトの公開情報をもとに作成。
※暫定対策は修正版への更新を代替するものではありません。

更新までの暫定対策では展開前に止める

すぐに更新できない場合は、脆弱なデコーダーにBrotli圧縮データが渡らないようにすることが暫定対策となります。受信リクエストでは、Brotli形式の本文を展開する前に拒否する方法があります。外部サイトからのレスポンスについても、Brotli展開を無効にするか、展開前に拒否できるかを確認します。送信するAccept-Encodingからbrを削除するだけでは、接続先がBrotli圧縮されたレスポンスを返す可能性を排除できません。

回避策の設定方法は製品によって異なります。Bunの公式告知では、fetchの呼び出しにdecompress: falseを指定する方法が示されていますが、その呼び出しだけに適用される設定です。ほかのBrotli展開処理まで一括して無効になるわけではありません。回避策の対象範囲を確認したうえで修正版へ更新してください。

HTTP2Shellへの対応では、公開Webサーバーの点検に加え、外部と通信するアプリケーションや製品内の依存ライブラリまで確認を進めます。Brotliを含む実行環境を洗い出し、攻撃者のデータが届く経路を確認したうえで、稼働中のプロセスに修正が反映されたことまで確かめてください。外部から細工されたBrotliデータを受信・展開する可能性があった環境では、修正版の適用に加え、不審なプロセスの異常終了や関連ログなどを確認し、侵害の兆候がないか調査することも重要です。

Webアプリケーションのセキュリティ対策を見直しませんか？

公開WebサイトやAPIの安全性を維持するには、利用するソフトウェアの更新に加え、アプリケーション全体の脆弱性を継続的に確認することが重要です。ブロードバンドセキュリティ（BBSec）では、Webアプリケーションの脆弱性診断を通じて、企業のセキュリティ対策を支援しています。

SQATWebアプリケーション脆弱性診断サービスページバナーリンク

【参考情報】

公開日：2026年10月26日
更新日：2026年11月2日

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

デジタル庁がStudioへの不正アクセスによる情報漏洩の可能性を公表 ―SaaS利用企業の対策

Share
デジタル庁がStudioへの不正アクセスによる情報漏洩の可能性を公表アイキャッチ画像

デジタル庁は2026年10月22日、ホームページ運営の一部で利用していたStudio株式会社のサービスへの不正アクセスにより、個人情報が漏洩した可能性があると公表しました。対象には、過去の問い合わせフォームに入力された情報や、職員・委託事業従事者のアカウント情報が含まれます。

今回の事案では、Studio側での脆弱性修正に加え、利用企業による認証情報の変更や、個人情報保護委員会への報告、本人への通知なども課題となっています。本記事では、公表された影響範囲と対応状況を整理し、SaaSを利用する企業が確認すべき事項を解説します。

対象は過去の問い合わせと運営者のアカウント情報

デジタル庁は2026年10月22日、ホームページ運営の一部で利用していたStudio株式会社のサービスへの不正アクセスに伴い、個人情報が漏洩した可能性を公表しました*7。範囲は精査中です。公表されたのは問い合わせフォームなどの情報であり、マイナンバーの漏洩を確認したという発表ではありません。

対象となり得るフォーム入力は2021年5月から2023年3月までのものです。一般的な意見・要望は最大8,833件、採用に関する問い合わせは最大250件、接種証明書アプリに関する問い合わせは最大3,661件、マイナちゃんの着ぐるみ借用は最大117件、ワークショップ等の参加関連は最大462件とされています。情報項目はフォームによって異なり、氏名やメールアドレスなどは任意入力の場合もあります。別に、職員または委託事業従事者のStudioアカウント情報35件も挙げられています。

これらは漏洩が確定した人数ではありません。発表には区分間の重複を除いた人数の記載がないため、単純に足して被害人数とすることはできません。デジタル庁は、公表時点で二次被害は確認されていないとし、同庁などを装う不審な連絡に注意を求めています。

Studioの修正対応と利用企業に残る対応を分ける

Studioの公表によると、第三者が同社サービスの一部機能の脆弱性を悪用し、クラウド環境内のデータを外部から取得できる状態にしていました。不正アクセスが確認された期間は2026年9月30日から10月1日で、Studioは10月13日に事案を確認し、14日までに脆弱性の修正と不正アクセス経路の遮断を完了しました。実際に第三者がデータを取得した事実は確認されていませんが、同社は取得されたものとみなして対応を進めています。

利用企業が確認したいのは、自社が使っていた機能と、その機能に預けていた情報です。Studioは、暗号化されたフォーム回答や外部サービスのAPIキーなどについても、復号に必要な鍵が読み出されたため、内容を知られた可能性があると説明しています。また、外部サービスが発行したAPIキーやトークンはStudio側では無効化できず、利用者による切り替えと旧キーの失効が必要です。

担当者は公式の案内ページと個別通知を照合し、対象のプロジェクトを確認してください。対応状況は『確認待ち』『作業中』『完了』に分け、実施日と担当者を残すと進捗を共有しやすくなります。外部サービスの認証情報については、新しいキーを設定した記録に加え、旧キーを失効した記録も残す運用が考えられます。

委員会への連名報告に本人への通知は含まれない

フォームを運営する企業には、技術面の対応と併せて、個人情報保護委員会への報告や、情報を送信した本人への通知が必要かどうかの検討も求められます。Studioは10月20日の続報で、個人情報保護委員会への漏洩等報告について、利用企業が個別に行う方法と、Studioが取りまとめて連名で行う方法を選べると案内しました。さらに10月28日には、連名報告の受付を11月上旬に開始する予定であることを公表しています*2。

ただし、連名報告の対象は個人情報保護委員会への報告であり、フォーム送信者本人への通知は含まれません。本人への通知が必要となる場合は、各利用企業で対応を検討する必要があります。社内では、委員会への報告と本人への通知を分けて管理し、提供事業者からの案内を確認する担当者や対応状況を明確にしておくことが重要です。連名報告を希望する企業は、受付期間や対象範囲を確認し、対象となる個人データの項目・件数、本人への通知状況、委託先の監督状況などを整理しておく必要があります。

図：Studioと利用企業の対応範囲

Studioと利用企業の対応範囲の図
出典：Studio株式会社「Studioにおける不正アクセスに関するご案内」「フォーム機能などで個人情報を取り扱っているお客様へ：個人情報保護委員会へのご報告についてのご案内」を基に作成
※Studioと利用企業の主な対応範囲を整理したもの。連名報告に本人への通知は含まれません。

SaaSの委託先管理で確認したいデータと責任範囲

外部サービスのリスク評価を進める際には、契約先の一覧に加え、どの業務で何を預けているかを整理すると検討しやすくなります。米国国立標準技術研究所（NIST）のサプライチェーンリスク管理ガイドは、事業上の重要性、処理・保存するデータの機微性、自社システムへのアクセスの程度などに基づいて、供給者の重要度を判断する考え方を示しています。

Webサイト運営では、フォーム回答などの保存先や保存期間に加え、外部サービスと連携するAPIキーや認証情報の管理状況も確認する必要があります。委託先で事故が発生した場合に、自社でどの情報を確認し、どの認証情報を変更する必要があるのかを把握しておくことが重要です。保存を続ける理由を説明できない古いデータについては、業務上・法令上の必要性を確認したうえで保管ルールを見直すとよいでしょう。これは本件の原因を断定するものではなく、自社の管理を点検するための提案です。

NISTは、関係する供給者をインシデントの計画・対応・復旧に含め、情報共有や報告の手順を定めることも挙げています。平時に、提供事業者から何を受け取り、自社の誰が判断するかを決めておくことが、SaaSのセキュリティ管理を具体的な業務へ落とし込む一歩になります。

【関連記事】デジタル庁GSSへの不正アクセス
デジタル庁が公表した別の不正アクセス事案について、VPNの脆弱性管理や保守アカウントの監視で確認すべきポイントを解説しています。
▶記事はこちら「デジタル庁GSSに不正アクセス」

SaaS・委託先管理のリスク評価と改善に向けて

利用するSaaSが増え、自社の管理状況や改善の順序を整理しきれない場合は、外部の専門家による評価も選択肢になります。株式会社ブロードバンドセキュリティ（BBSec）の「情報セキュリティリスクアセスメント」は、コンサルタントが評価を行い、課題・対策一覧や報告書を作成し、対策ロードマップの策定につなげるサービスです。継続的な相談には「情報セキュリティ・アドバイザリ」もあります。規程やシステム構成、インシデント発生時の手順などを把握したうえで、施策の推進や初動対応について助言します。SaaSの利用状況や委託先管理の課題を整理し、必要な対策を検討したい企業は、BBSecへご相談ください。

sqatお問い合わせページリンクボタン

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

skyticket不正アクセス第3報 ―旧決済ログとバックアップの残存から考える情報管理のリスク

Share
skyticket不正アクセス第3報 ―旧決済ログとバックアップの残存から考える情報管理のリスクアイキャッチ画像

旅行比較予約サイト「skyticket」を運営するアドベンチャーは、2026年10月9日に顧客情報の流出に関する3件の不正アクセスを公表しました。その後、10月16日の第2報でクレジットカード情報の流出が判明し、10月30日の第3報では銀行口座情報の流出や、過去のバックアップに保存されていた情報への影響が明らかになりました。

今回の事案では、システム移行後も残っていた旧決済ログや、不要となったバックアップの管理が問題となっています。本記事では、追加公表された情報と、企業が見直したいデータ管理・アクセス制御のポイントを解説します。

※本記事は2026年10月30日時点で公表されている情報を基に作成しています。

3つの不正アクセス事案と追加調査で判明した情報

アドベンチャーが公表した3つの不正アクセス事案と、その後の調査で判明した情報を下図に示します。第2報・第3報では、サーバーへの不正アクセスに関する新たな情報流出や、そのおそれが明らかになりました。

図：skyticketの3つの不正アクセス事案と第3報までの公表内容

skyticketの3つの不正アクセス事案。サーバー事案では第2報でカード情報流出を追加確認。件数の単位が異なり、合算は不可。
出典：株式会社アドベンチャーの2026年10月9日、16日、30日の公表資料をもとに弊社作成。
約413万件は約1,464万件の内数です。各事案で対象情報や件数の数え方が異なるため、単純に合算することはできません。

第2報・第3報で判明した情報流出と利用者への影響

10月16日の第2報では、2017年2月から2018年6月に「skyticketプレミアム」の会費支払いで使用されたクレジットカード情報が、最大6,140名分流出したことが判明しました。対象にはカード番号、名義人名、有効期限が含まれ、一部はカード番号のみです。セキュリティコードは含まれていません。

10月30日の第3報では、返金先の銀行口座情報32,341件の流出が確認されました。さらに、2021年5月頃から2024年5月中旬頃までのクレジットカード決済に関する情報約93.6万件（約41.4万人）と、旅行保険の申込情報約11.8万件（約11.9万人）について、流出のおそれがあると発表しています。

第3報で対象となったクレジットカード情報は、主にカード名義や一部を伏せたカード番号などですが、12件にはカード番号の全桁が記録されていました。ただし、この12件には有効期限やセキュリティコードは含まれていません。また、第2報で流出したと説明されていたベネフィット・ステーションの会員情報については、第3報で訂正され、実際にはskyticketプレミアムを利用するために内部で設定された会員IDと氏名だったことが明らかになりました。

同社は、銀行口座やクレジットカードの利用明細の確認に加え、返金や補償を装って口座情報やカード情報を聞き出す不審な連絡への注意を呼びかけています。企業側も、流出が確認された情報と流出のおそれがある情報を区別し、対象者に必要な対応を具体的に伝えることが重要です。

skyticketの3つの不正アクセス経路と、パスワードのハッシュ化や認証・認可の基本的な対策については、前回記事「skyticketで約1,464万件の情報流出 ―3つの不正アクセス経路から考えるWebサービスのセキュリティ対策」で解説しています。

旧決済ログとバックアップの残存から考える情報管理のリスク

今回の不正アクセスでは、過去のシステム運用で残されたデータが問題となりました。第2報によると、同社は2018年7月にクレジットカード情報を自社サーバーで保管しない方式へ移行しましたが、それ以前の「skyticketプレミアム」の会費支払いに関する決済ログが削除されずに残っていました。このログが不正アクセスによって取得され、暗号化されたカード情報とともに、暗号化に用いる情報も不正に取得されたと説明しています。

第3報では、不要となったデータベースのバックアップがクラウド上に残存していたことも明らかになりました。不正に取得された認証情報が悪用され、バックアップの一部が読み取られています。銀行口座情報を含む部分は外部への送信が確認されましたが、その他の情報については送信の痕跡が確認されておらず、流出のおそれがあるとされています。また、銀行口座情報と旅行保険の申込情報に含まれる氏名は、本来暗号化して保存すべきところ、暗号化されずに保存されていました。

これらの事案から、企業は現在利用しているデータベースだけでなく、過去のログやバックアップも含めて、保存情報とアクセス権限を確認する必要があります。システム移行や機能変更の際には、不要となったデータの削除、バックアップの保管期間、認証情報の管理、機密情報の暗号化状況を点検することが重要です。特にバックアップは、障害復旧や調査のために必要な一方、適切に管理されなければ情報流出の原因となり得ます。保存目的と期間を明確にし、アクセスできる利用者やシステムを必要最小限に制限するとともに、不要となったデータを適切に削除する運用が求められます。

Webサービスのアクセス制御と脆弱性を継続的に確認する

今回の事案は、Webサービスの脆弱性対策に加え、認証情報や保存データの管理も重要であることを示しています。公開Webサービスでは、外部からの不正アクセスにつながる脆弱性がないかを継続的に確認するとともに、管理機能やバックアップへのアクセス権限も適切に制限する必要があります。当社の「Webアプリケーション脆弱性診断 SQAT® for Web」では、WebアプリケーションやAPIを外部から動的に検証し、脆弱性の検出を支援します。また、システムの設計段階からセキュリティ対策を見直したい場合には、「Shift Leftコンサルティング」もご相談いただけます。

Webサービスの安全性を高めるには、公開機能の脆弱性診断と、保存データ・バックアップの管理状況の点検を組み合わせることが重要です。現在のシステムだけでなく、過去の運用で残された情報にも目を向け、継続的な確認と改善につなげていきましょう。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る