結論から言う。今回の主役はSalesforceの脆弱性ではない。Salesforceに接続する「連携アプリ」側で管理していたOAuthトークンが盗まれたことが原因だ。 競合インテリジェンス(セールスイネーブルメント)SaaS「Klue」は2026年6月12日、自社の連携基盤で不正な活動を検知したと公表した。攻撃者は、Klueが過去に試作連携のために発行し使われないまま残っていた「レガシー認証情報」を悪用してKlue社内に侵入し、Klueと顧客企業のSalesforceを接続するOAuthトークンを取得。Python製の自動化スクリプトでSalesforceのREST APIに反復クエリを送り、氏名・連絡先・商談情報・価格情報などのCRMデータを大量に抜き出した。恐喝グループ「Icarus」が自らのリークサイトで犯行を主張し、Huntress・Recorded Future・Tanium・Jamf・Gongなど十数社がすでに被害を公表している。
この記事で伝えたいのは「Salesforceを使っている会社は危ない」ではない。**Salesforceそのものは破られていない。**破られたのは、Salesforceと外部SaaSを繋ぐために自社が許可した「OAuth連携」というアクセス経路だ。自社のCRMやSaaS群のセキュリティをどれだけ固めても、連携させている外部アプリ側が侵害されれば、そのアプリに与えた権限の範囲でデータが持ち出される。委託先ベンダーの管理体制の話ではなく、自社が能動的に「連携を許可した」ことそのものがリスクになる、もう一段踏み込んだ論点だ。
目次
- 何が起きたか｜事実関係の早見表
- 手口：Salesforceではなく「連携アプリの鍵」が盗まれた
- 被害を公表した企業
- なぜ自社のOAuth連携が同じ穴になり得るのか
- OAuth権限棚卸しチェックリスト
- 誰が読むべき記事か
- よくある質問
- GXOに相談すべきタイミング
何が起きたか｜事実関係の早見表 {#事実関係}
| 項目 | 内容 |
|---|---|
| 対象SaaS | Klue(競合インテリジェンス／セールスイネーブルメントツール「Klue Battlecards」) |
| 不正活動の検知日 | 2026年6月12日(Klueが自社の統合基盤で検知) |
| 侵入経路 | Klueが過去の試作連携用に発行し、その後使われないまま有効に残っていた「レガシー認証情報」の悪用 |
| 窃取された鍵 | KlueとSalesforce等サードパーティプラットフォームを接続するOAuthトークン |
| 実行手口 | Python(urllib)によるSalesforce REST APIへの自動反復クエリ。1環境で15分間に約1,000件のクエリが集中、別環境では6時間超にわたる抽出も観測 |
| Salesforce側の対応 | Klue Battlecardsアプリのプラットフォーム接続を無効化する旨のアラートを発出(6月19日週) |
| Klue公式声明 | CEO Jason Smith名で2026年6月22日にブログ公開。認証情報・トークン失効、不正コード除去、CrowdStrike起用、法執行機関への通報を実施したと説明 |
| 犯行主張 | 2026年4月28日から活動する恐喝グループ「Icarus」がリークサイトで6月19日に犯行を主張。データはロシアのブレットプルーフホスティング事業者PROSPERO配下のIPで一部公開 |
| 被害範囲の限定 | Klue・被害各社とも「Klueプラットフォーム内部の保存データには影響なし」「影響はSalesforce等連携先のビジネス系データに限定」と説明 |
出典はKlue公式ブログ(2026年6月22日付、CEO Jason Smith執筆)、The Hacker News(2026年6月19日公開・6月23日更新)、BleepingComputer(2026年6月19日公開)の3系統で内容が一致することを直接確認した。被害企業各社の影響範囲は、Huntress公式ブログなど各社が自ら公表した声明の引用に基づく。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
手口：Salesforceではなく「連携アプリの鍵」が盗まれた {#手口}
Klueの説明によれば、攻撃者はKlue社内の統合サービス用アカウントに紐づく、使われなくなっていたものの無効化されずに残っていた認証情報を悪用してKlueの環境に侵入。そこからKlueが各顧客企業のSalesforce環境との接続に使っていたOAuthトークンを窃取し、顧客企業のSalesforce環境へ直接アクセスした。
セキュリティ企業ReliaQuestの分析では、攻撃者はPython-urllibのユーザーエージェントを使った自動化スクリプトでSalesforceのオブジェクトカタログを列挙し、クエリAPIへの反復アクセスとページングで結果を取得し続けたという。ある環境では15分間に約1,000件のクエリが集中し、別環境では6時間を超える抽出ウィンドウが観測された。ReliaQuestはこの手口を2025年のSalesloft DriftやGainsightを起点とするOAuth悪用型のSalesforce侵害と似たパターンと指摘し、「連携アプリのサービスアカウントは強い権限を持続的に持つ一方、従業員アカウントほど厳密に監視されていないことが多い」と警鐘を鳴らす。
重要なのは、Salesforce自体には脆弱性がなかった点だ。攻撃者はパスワードも多要素認証コードも必要とせず、正規に発行された連携用トークンを使って正規のアクセス経路からデータを取得した。ログの上では「いつも通りの連携アプリからのアクセス」にしか見えない。
被害を公表した企業 {#被害企業}
The Hacker Newsの報道(2026年6月23日更新版)による主な被害企業は次の通り。いずれも「影響はSalesforce上のビジネス関連データに限定され、自社製品やインフラ、決済情報には影響していない」と説明している。
| 企業 | 公表された影響範囲(各社発表の要旨) |
|---|---|
| Huntress | 氏名・業務メール・役職・電話番号・住所、契約製品、価格条件、商談関連の連絡・メモ。約3.4GBのデータ流出を確認 |
| Recorded Future / Tanium | 顧客連絡先氏名・メールアドレス、商談名・金額等の営業データ、一部契約情報 |
| Jamf / Sprout Social | Salesforce環境内のビジネスデータ項目(連絡先・企業情報・CRMレコード)に限定 |
| Gong | ライセンスユーザーの氏名・役職・メール(通話録音・文字起こしは対象外) |
| LastPass | 標準的な業務連絡先情報、サポートケース情報、営業関連データ |
| そのほか | Insurity、OneTrust、HackerOne、Snyk、Pendo、8x8、BeyondTrustなどが同様の限定的影響を公表 |
なぜ自社のOAuth連携が同じ穴になり得るのか {#自社リスク}
ここが今回いちばん伝えたい論点だ。多くの企業は、名刺管理ツール・MAツール・商談分析ツール・議事録AI・チャットボットなど、複数の外部SaaSをSalesforceやその他のCRMに「連携」として許可している。導入時には利便性や機能を評価しても、「そのアプリに何のデータへのアクセス権限を与えているか」「連携が今も業務上必要か」を定期的に点検している企業は多くない。
OAuth連携は、いったん許可すると人手を介さずに動き続ける「非人間ID」だ。従業員アカウントなら退職時にチェックが入るが、連携アプリ用のトークンは担当者の異動・退職と無関係に生き続け、使われなくなっても明示的に解除しない限り有効なままになりやすい。今回の起点が、Klueが「試作して使わなくなった連携」用の古い認証情報だった点は、この構造的な弱さを象徴している。攻撃者から見れば、CRMに直接侵入するより監視の目が届きにくい連携アプリ経由でトークンを奪う方が効率的で、一つの連携基盤を破れば接続する複数の顧客企業へ同時にアクセスできる。
OAuth権限棚卸しチェックリスト {#チェックリスト}
- SalesforceやCRM、基幹システムに連携を許可している外部SaaSアプリの一覧を、情報システム部門が最新の状態で把握しているか
- 各連携アプリに付与しているアクセス権限(参照のみか、書き込み・エクスポートまで可能か)を個別に確認したか
- 導入検証だけで終わった連携アプリが、削除されずに放置されていないか
- 連携先SaaSベンダーが、今回のようなインシデント発生時に自社へ通知する契約・体制になっているか
- 連携アプリ経由の異常な大量データ取得(短時間の反復クエリ等)を検知できるログ・アラート体制があるか
誰が読むべき記事か {#誰が読むべきか}
- SalesforceやCRMに複数の外部SaaSアプリ(名刺管理・MA・商談分析・議事録AI等)を連携させている経営者・営業DX担当者
- 顧客の氏名・連絡先・商談情報などCRMデータの管理責任を負う情報システム担当者
- 新規SaaS導入・連携許可の意思決定に関わる調達・情報システム担当者
よくある質問 {#faq}
Q. うちはKlueを使っていません。それでも関係がありますか。 A. Klueという製品名そのものより、「連携許可したSaaSアプリのOAuthトークンが盗まれると、自社のSalesforceやCRMに正規のアクセス経路でアクセスされる」という手口が重要です。同種の連携アプリを1つでも使っていれば、構造的には同じリスクを抱えています。
Q. Salesforceを使っていなければ無関係ですか。連携を増やさなければ安全ですか。 A. いずれも「いいえ」です。今回の手口はSalesforce固有の脆弱性ではなくOAuth連携という仕組み一般に当てはまり、HubSpot等の他CRMや会計・人事系SaaS同士の連携でも同様の構造的リスクがあります。連携数を絞るより、既存連携を定期的に棚卸しし、不要な連携を解除して権限を最小限に保つ運用の方が実務的な対策です。
GXOに相談すべきタイミング {#相談タイミング}
- 自社がSalesforceやCRMに許可しているOAuth連携・外部SaaSアプリの一覧を、正確に把握できていないと感じたとき
- 導入検証だけで終わったSaaS連携が、解除されないまま残っている可能性があるとき
- 連携先SaaSベンダーからインシデントの連絡を受けたが、自社への影響を判断できないとき
- 今回を機に、自社が許可しているSaaS連携全体の権限を点検し最小権限の運用に見直したいとき
こうした棚卸しを自社だけで進めるのは負荷が大きい。GXOでは委託先・連携SaaSも含めたセキュリティ体制の評価で、OAuth連携先の洗い出しと権限の最小化を支援している。今回のような特定インシデントを起点に短期間で影響範囲を確認したい場合はセキュリティ緊急診断、連携アプリを含む脆弱性情報を継続的にキャッチアップしたい場合はセキュリティ顧問が対応する。まずはセキュリティの全体像から確認することもできる。
本記事のインシデント情報は2026年7月2日時点で確認できたKlue公式発表および複数の専門セキュリティメディアの報道に基づく。被害範囲や追加の影響企業について今後情報が更新される可能性があるため、最新情報は各ソースで確認することを推奨する。
