
作業管理プラットフォームAsanaは、同社の新機能であるModel Context Protocol(MCP)の実装に欠陥があり、自分のインスタンスから他のユーザーへ、あるいはその逆へとデータが流出する可能性があるとして、ユーザーに警告を発している。
データ流出はMCPシステムのロジック欠陥によるもので、ハッキングの結果ではないが、この事故から生じるリスクは、場合によっては重大なものになる可能性がある。
Asanaは、仕事の計画、追跡、管理、チームメンバーへのタスク割り当て、期限設定、および一元化されたインターフェイスからの共同作業に組織が使用するプロジェクトおよびタスク管理SaaSプラットフォームです。
昨年の時点で、同プラットフォームは190カ国に13万人以上の有料顧客と数百万人の無料ユーザーを抱えている。
2025年5月1日、アサナは大規模言語モデル(LLM)を統合したMCPサーバー機能を導入し、要約、スマート返信、自然言語クエリなどのAI搭載機能を実現した。
しかし、MCPサーバーのソフトウェアバグにより、Asanaインスタンスのデータが他のMCPユーザーに公開され、データの種類は各ユーザーのアクセススコープに制限されていた。
つまり、組織全体がAsanaワークスペースに流出することはなかった。それでも、MCPにアクセスできる他社のユーザーは、チャットボットが生成したクエリなど、別のドメインの特定のデータを見たかもしれない。
統合タイプやチャットボットとのエンゲージメントによっては、公開されたデータにはタスクレベルの情報、プロジェクトのメタデータ、チームの詳細、コメントやディスカッション、アップロードされたファイルなどが含まれる可能性があります。
Asanaは6月4日にこの情報漏えいを引き起こすロジックの欠陥を発見したため、このような組織横断的なデータ漏えいは1ヶ月以上発生していたことになります。
組織内での Asana の機能的な役割を考えると、これらの流出には、影響を受けた企業にプライバシーや規制上の複雑ささえもたらす可能性のある機密情報が含まれていた可能性があります。
このため、管理者は MCP アクセスの Asana ログを確認し、生成された AI サマリーまたは回答を確認し、他の組織から取得されたと思われるデータを見つけたら直ちに報告することが推奨される。
LLM 統合はアクセス制限に設定し、自動再接続とボットパイプラインは、信頼が再確立され、暴露リスクが残らなくなるまで一時停止する必要があります。
Asana は、影響を受けた各組織にコミュニケーションフォームへのリンクを含む通知を送付したが、インシデントに関する公式声明は発表していない。
この問題を通知したUpGuardは、影響を受ける可能性のあるユーザーへのアドバイスを含む詳細を自身のブログスペースで共有した。
Asanaに連絡を取り、暴露された範囲と影響を受けた組織/ユーザーの数について尋ねたところ、広報担当者はこのインシデントがおよそ1,000人の顧客に影響を及ぼしていると回答した。
その間、MCP サーバーはオフラインになりましたが、Asana のステータスページによると、6 月 17 日 17:00 UTC に予定通り通常の運用状態に戻ったとのことです。
.ia_ad { background-color:#width: 95%; max-width: 800px; margin: 15px auto; border-radius: 8px; border:1px solid #d6ddee; display: flex; align-items: stretch; padding: 0; overflow: hidden; }:0; overflow: hidden; } .ia_lef { flex: 1; max-width: 200px; height: auto; display: flex; align-items: stretch; } .ia_lef a { display: flex; width: 100%; height: 100%; } .ia_lef a img { width: 100%; height: 100%; object-fit: cover; border-radius: 8px 0 0 8px; margin: 0; display: block; } .ia_rig { flex: 2; padding:display: flex; flex-direction: column; justify-content: center; } .ia_rig h2 { font-size: 17px !important; font-weight: 700; color:#line-height: 1.4; font-family:margin: 0 0 14px 0; } .ia_rig p { font-weight: bold; font-size: 14px; margin: 0 0 clamp(6px, 2vw, 14px) 0; } .ia_button { background-color:#border:1px solid #3b59aa; color: black; text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; cursor: pointer; padding:10px 20px; width: fit-content; } .ia_button a { text-decoration: none; color: inherit; display: block; } @media (max-width: 600px) { .ia_ad { flex-direction: column; align-items: center; text-align: center; } .ia_lef { max-width: 100%; } .ia_lef a img { border-radius: 8px 8px 0 0; } .ia_rig { padding:15px; width: 100%; } .ia_button { width: 100%; } .
ITチームが手作業によるパッチ管理をやめる理由
かつてはパッチ適用といえば、複雑なスクリプト、長時間の作業、終わりのない消火訓練が必要でした。今は違います。
この新しいガイドでは、Tines氏が最新のIT組織が自動化によってどのようにレベルアップしているかを解説している。複雑なスクリプトは必要ありません。




Comments