4月27日 – Feature Flagsの設定に何が起きたのか

2026年4月27日、あるセキュリティ研究者が、ClickUpのクライアントサイドのFeature Flags設定により、個人を特定できる情報が公開されていたことを公表しました。具体的には、893件の顧客の電子メールアドレスがFeature Flagsのターゲティングルールに埋め込まれており、さらに、あるワークスペースからのトラフィックをレートリミットするためにインシデント対応中に使用された、顧客のAPIトークンを不適切に参照していたフラグが1つ確認されました。

もっと早く気づくべきでした。しかし、そうできなかった以上、何が起きたのか、その理由、現在どのような対応を取っているのか、そして今後どのように改善していくのかについて、皆様に明確な説明をする義務があります。

影響を受けていますか？

影響を受けたのは、機能の展開時にどのユーザーに特定の機能を表示するかを制御するためのFeature Flagsのターゲティングルールで使用された893件の顧客電子メールアドレスのみでした。

4月29日（現在も継続中）以前に当社から直接連絡があった場合、お客様の電子メールアドレスはFeature Flagsの設定に含まれていたものです。 当社から連絡がない場合は、お客様の電子メールアドレスは対象リストに含まれていませんでした。

技術的な問題

ClickUpでは、Feature Flagsの管理にSplit.io（現在はHarnessの一部）を使用しています。 ほとんどのブラウザサイドのFeature Flags SDKと同様に、Split.ioでは、アプリケーションのJavaScriptバンドルにクライアントサイドSDK鍵を埋め込む必要があります。この鍵は意図的に公開されており、SDKがブラウザ上で現在のユーザーのFeature Flagsを評価するために使用されます。これはSplit.io、LaunchDarkly、および類似のプラットフォームにおいて標準的かつ文書化された動作であり、脆弱性ではありません。

重要なのは問題そのものではありません。重要なのは、当社のエンジニアがフラグ設定に何を入力するかです。

アーキテクチャ上の経緯は以下の通りです。Feature Flagsプラットフォームを利用することで、エンジニアは機能の展開ターゲットを特定のユーザーに絞り込むことができます。 ClickUpのエンジニアリングチームは、フラグのターゲティングルールに電子メールを直接使用していました。例えば、特定のベータテスターグループに対して機能を有効にする場合などが挙げられます。Split.ioSDKの公開クエリ可能なsplitChangesエンドポイントは、これらのターゲティングルールを含むフラグ定義の全セットを返します。つまり、クライアントサイドの鍵（これもまた、意図的にフロントエンドコード内に記述されています）を持つ者であれば誰でも、それらのフラグ定義を取得し、そこに埋め込まれた電子メールを抽出することが可能でした。

エンジニアたちは、フラグの設定を内部ツールとして扱っていましたが、SDKのアーキテクチャ上、これらは本来公開して照会可能な仕様となっています。そのため、電子メールアドレスが本来あるべきではない場所に蓄積されてしまいました。Feature Flagsの更新には、コードと同様に「+1」のピアレビューが必要です。しかし、このレビューステップではこの問題が見逃されてしまいました。

唯一の例外――特定の顧客に対するレートリミット用に設定されたフラグ

APIの不正利用に対応していた当直エンジニアが、トラフィックを制限するためのレートリミットフラグの設定において、ある顧客のAPIトークンを参照したため、SDKエンドポイント経由でそのトークンが読み取られる可能性が生じました。これは決してあってはならないことです。認証情報はフラグの設定に含まれてはなりません。当社は直ちに当該トークンを無効化しました。現時点でのログ調査では、研究者自身の調査以外の悪意あるアクセスは確認されていません。 他の顧客のトークンやワークスペースのデータにアクセスされた事実はなく、現在、当該顧客と直接連携して対応を進めています。

何が明らかになり、何が明らかにならなかったのか

タイムライン

当社は、第三者のバグ報奨金プロバイダーや自社の社内コミュニケーションツールにおける不具合を含め、プロセスのどの部分で問題が生じたかについて、完全に透明性を確保することをお約束します。

当社のプロセスがどこで失敗したのか

ここでは3つの問題が発生しました。それぞれを明確に指摘したいと思います。変更点については、次のセクションで説明します。

1. 当初の報告に対する二次的な対応が行われなかった。 2025年1月のバグ報奨金プログラムによる報告を受けて、エンジニアリングタスクが割り当てられ、フラグ設定内にどのようなデータが存在するかの確認が行われるはずでした。しかし、実際にはそうなりませんでした。今後このような事態が再発しないよう、トリアージプロセスを改善しています。

2. HackerOneによる重複報告の処理に不備があった。 2026年4月の報告書には、2025年1月の報告書と比較して、実質的に新たな影響が記載されていた。HackerOneがこれを重複として閉じてはならなかった。 さらに調査を進めた結果、同様のレポートが閉じた事例が他に2件確認されました。1件は2025年9月6日、もう1件は2026年1月1日のものです。現在、HackerOneと連携し、同社のトリアージプロセスにおける不備の解消に取り組んでいます。今後は、サードパーティのプロセスに依存しないよう、すべてのHackerOneレポートに対して二次審査を実施する予定です。

3. 当社の電子メールサービスは、この研究者からのエスカレーションをスパムとして検知しました。 4月25日（土）、この研究者は当社のCEOとsecurity@clickup.comの両方に電子メールを送信し、さらにClickUpのXアカウントにダイレクトメッセージを送りました。

これらの電子メールは、Xへの公開投稿が行われてから初めて確認されました。これらは、スパムフォルダやXのDMフィルタリングに関する社内調査の結果、発見されたものです。

セキュリティ関連の電子メールが誤って削除されないよう、電子メールフィルタリングおよびスパム判定のプロセスを更新しています。

しかし、これらはいずれも根本的な問題を正当化するものではありません。そもそも、顧客データをFeature Flagsの設定に含めるべきではなかったのです。

これまでの取り組み

即時（完了）

短期（進行中）

長期的な

研究者についてメモ

ClickUpは、ハンドルネーム「impulsive / @weezerOSINT」で活動する、この問題を公表した研究者と連絡を取ると、責任ある対応を取り、求められたすべての情報を提供しました。

ハンドルネーム「impulsive / @weezerOSINT」を名乗るこの研究者は、適切なルート（HackerOne、続いてsecurity@ClickUp.comへの直接電子メール、および当社CEOへの連絡）を通じて報告を行い、当社から連絡を取った際には建設的な対応を示しました。しかし、当社の内部プロセスでは、その報告やエスカレーションを適時に把握することができませんでした。

その研究者と仕事をした後、ClickUpは4月28日1時47分（UTC）に次のようなメッセージを受け取りました。「[ClickUp]さん、ありがとうございます。これほど迅速に対応していただき、本当に感謝しています。このような対応はめったにないことで、大きな違いを生んでいます。」

ClickUpは、この発見に対して当該の研究者にバグ報奨金を支給します。他の研究者の皆様も、ぜひ当社のバグ報奨金プログラムにご参加いただくか、脆弱性開示プログラムを通じて、あるいは security@clickup.com まで直接電子メールにて、責任ある形で報告してください。

要約

今回のインシデントで流出したデータは、893件の電子メールアドレスに限定されています。前述の1社を除き、どの顧客についてもワークスペース内のコンテンツ、パスワード、請求データへの影響はありません。当該1社とは直接連携し、秘密鍵が不正にアクセスされていないか確認を進めています。

お客様には、このような事態を招いてしまい、心よりお詫び申し上げます。今後、同様のことが二度と起こらないよう、すべてを尽くしてまいります。

新たな情報が入り次第、この記事を更新いたします。ご質問がある場合は、セキュリティ@ClickUp.com までご連絡ください。