Le 27 avril 2026, un chercheur en sécurité a révélé publiquement que la configuration des Feature Flags côté client de ClickUp exposait des informations personnelles identifiables. Plus précisément, 893 adresses e-mail de clients étaient intégrées dans les règles de ciblage des Feature Flags, ainsi qu’un Feature Flag qui faisait référence de manière inappropriée au jeton API d’un client, utilisé lors d’une intervention pour limiter la limite de fréquence du trafic provenant de cet environnement de travail.
Nous aurions dû nous en rendre compte plus tôt. Ce n’est pas le cas, et nous vous devons une explication claire sur ce qui s’est passé, les raisons de cette situation, les mesures que nous avons faites pour y remédier et les améliorations que nous allons mettre en place à l’avenir.
Êtes-vous concerné ?
La fuite concernait uniquement 893 adresses e-mail de clients utilisées dans les règles de ciblage des Feature Flags afin de déterminer quels utilisateurs avaient accès à certaines fonctionnalités lors des déploiements.
Si vous avez reçu un message de notre part avant le 29 avril inclus (ou si vous en recevez actuellement), cela signifie que votre adresse e-mail figurait parmi celles incluses dans une configuration de Feature Flags. Si vous n'avez pas reçu de message de notre part, cela signifie que votre adresse e-mail ne figurait pas dans la liste des adresses e-mail concernées.
- Aucun contenu de l'environnement de travail (tâches, documents, fichiers ou données de projet) n'a été divulgué pour aucun client — à l'exception d'un cas potentiel décrit ci-dessous.
- Aucun mot de passe, aucune donnée de facturation ni aucun identifiant de compte n'a été divulgué.
- Aucun système d'authentification n'a été compromis.
Le problème technique
ClickUp utilise Split.io (qui fait désormais partie de Harness) pour la gestion des Feature Flags. Comme la plupart des SDK de Feature Flags côté navigateur, Split.io nécessite une clé SDK côté client intégrée dans le bundle JavaScript de l'application. Cette clé est volontairement publique et permet au SDK d'évaluer les Feature Flags pour l'utilisateur actuel dans le navigateur. Il s'agit d'un comportement standard et documenté sur Split.io, LaunchDarkly et les plateformes similaires, et cela ne constitue pas une vulnérabilité.
Ce n'est pas le problème qui importe. Ce qui compte, c'est ce que nos ingénieurs intègrent dans les configurations des indicateurs.
Voici ce qui s'est passé sur le plan architectural : les plateformes de Feature Flags permettent aux ingénieurs de cibler des utilisateurs spécifiques lors du déploiement de fonctionnalités. Les équipes d'ingénierie de ClickUp utilisaient directement les adresses e-mail dans les règles de ciblage des indicateurs. Par exemple, pour activer une fonctionnalité pour un groupe spécifique de bêta-testeurs. Le point de terminaison splitChanges du SDK Split.io, accessible au public, renvoie l'ensemble complet des définitions d'indicateurs, y compris ces règles de ciblage. Cela signifie que toute personne disposant de la clé côté client (qui, encore une fois, se trouve intentionnellement dans notre code front-end) pouvait récupérer ces définitions d'indicateurs et extraire les adresses e-mail qui y étaient intégrées.
Les ingénieurs ont traité les configurations des indicateurs comme des outils internes, alors que l'architecture du SDK est conçue pour permettre leur consultation publique. Cela a permis aux adresses e-mail de s'accumuler à un endroit où elles n'auraient jamais dû se trouver. Les mises à jour des Feature Flags nécessitent une révision par les pairs de type « +1 », à l'instar du code. Cette étape de révision n'a pas permis de détecter ce problème.
La seule exception : un indicateur configuré pour fixer la limite de fréquence pour un seul client
Un ingénieur de garde chargé de traiter un cas d'utilisation abusive de l'API a intégré le jeton API d'un client dans la configuration d'un indicateur de limite de fréquence afin de réguler le trafic, rendant ainsi ce jeton potentiellement accessible via le point de terminaison du SDK. Cela n'aurait jamais dû se produire : les identifiants n'ont pas leur place dans les configurations d'indicateurs. Nous avons immédiatement désactivé le jeton et, à l'heure actuelle, l'analyse de nos journaux ne révèle aucun signe d'accès malveillant autre que celui lié à l'enquête menée par le chercheur lui-même. Aucun autre jeton client ni aucune donnée de l'environnement de travail n'étaient accessibles, et nous travaillons directement avec ce client.
Ce qui a été révélé et ce qui ne l'a pas été
| Réclamation | Nos conclusions |
| Clé SDK intégrée dans le bundle | C'est normal et voulu. C'est ainsi que fonctionnent les SDK de Feature Flags côté navigateur. Il ne s'agit pas d'une faille en soi. |
| 893 adresses e-mail de clients dans les règles de ciblage par indicateur | Informations exactes au moment des rapports. Toutes les adresses e-mail tierces ont été supprimées le 28 avril à 03 h 25 UTC. |
| Jeton API client en production dans la configuration des indicateurs | Confirmé. Ajouté le 7 octobre 2025. Invalidé le 27 avril 2026 à 12 h 05 UTC. |
| Droit d'écriture sur Split.io | C'est normal et prévu. Les points de terminaison de télémétrie du SDK du navigateur (évènements/bulk, testImpressions) acceptent les écritures dans le cadre du fonctionnement standard du SDK. Il ne s'agit pas d'une erreur de configuration de ClickUp. |
| « Aucune mesure corrective pendant 15 mois » | Erreur de formulation ; les dates sont correctes. Le rapport initial de bug bounty du 17 janvier 2025 concernant la clé SDK n'a pas donné lieu à une tâche d'ingénierie, car la clé en elle-même ne constituait pas la vulnérabilité. Les adresses e-mail et les configurations de drapeaux constituaient le véritable problème et n'étaient pas incluses dans ce rapport initial. Les configurations de drapeaux n'ont été divulguées à HackerOne que le 8 avril 2026 et n'ont été portées à la connaissance de ClickUp que le 27 avril 2026. |
Échéancier
Nous nous engageons à faire preuve d'une transparence totale quant aux défaillances de nos processus, y compris celles de notre fournisseur externe chargé du programme de prime aux bogues et de nos propres outils de communication interne.
| Date | Évènement |
| 17 janvier 2025 | Un chercheur a signalé une fuite de clés du SDK Split.io à notre programme de prime aux bogues sur BugCrowd. Compte tenu du contenu du rapport, celui-ci a été correctement classé comme « informatif » par BugCrowd et ClickUp. |
| 3 juin 2025 | ClickUp transfère son programme de prime aux bogues vers HackerOne. Tous les rapports antérieurs ont été migrés avec succès, y compris le problème mentionné ci-dessus. |
| 8 avril 2026 | Le chercheur connu sous le pseudonyme « impulsive » a publié un nouveau rapport détaillé sur HackerOne, dans lequel il fait état d'un impact plus important que prévu : 893 adresses e-mail de clients dans les règles de signalement, le jeton API d'un client actif et d'autres données opérationnelles. |
| 10 avril 2026 | Un analyste chargé du triage chez HackerOne a fermé à tort le rapport comme un doublon du rapport de janvier 2025, sans se rendre compte que ce nouveau rapport faisait état d'un impact sensiblement différent et plus étendu. Après un examen plus approfondi, nous avons identifié deux autres instances de rapports similaires qui avaient été fermés à tort : l'une le 6 septembre 2025 et l'autre le 1er janvier 2026. |
| 21 avril 2026 | Le chercheur conteste cette conclusion en fournissant des précisions supplémentaires à HackerOne. |
| 25 avril 2026 | Le chercheur passe à la vitesse supérieure : via HackerOne, il envoie un e-mail au PDG de ClickUp et à security@clickup.com, et envoie un message privé à ClickUp sur X, fixant au 2 mai la date limite de divulgation publique. Ces e-mails adressés au PDG de ClickUp et à security@ sont bloqués par les filtres anti-spam et ne parviennent pas à leurs destinataires. Les messages privés envoyés à ClickUp sur X ont été automatiquement filtrés et n'ont pas été lus. |
| 27 avril 2026 ~ 10 h 42 UTC | Le chercheur publie ses conclusions sur X. |
| 27 avril 2026, 11 h 06 UTC | ClickUp est informé. L'incident est déclaré. Le processus de gestion des incidents est lancé et la procédure de renouvellement du jeton API du client a été mise en œuvre. |
| 27 avril 2026, de 12 h 53 à 14 h 12 UTC | Premiers travaux de nettoyage des indicateurs de division au sein des équipes d'ingénierie. |
| 27 avril 2026 ~ 17 h 00 UTC | L'audit entièrement automatisé des 4 809 Feature Flags est achevé. |
| 27 avril 2026, 23 h 13 UTC | Les ingénieurs de ClickUp et de Harness (Split) examinent les détails techniques. |
| 28 avril 2026, 03 h 25 UTC | Toutes les adresses e-mail des clients ont été supprimées des configurations des indicateurs. Note : certaines adresses e-mail tierces sont volontairement conservées dans deux indicateurs ; cela est lié à des utilisations frauduleuses. |
Là où notre processus a échoué
Trois problèmes se sont posés ici, et nous souhaitons les identifier clairement. Nous aborderons les modifications à apporter dans la section suivante.
1. Absence de suivi de deuxième niveau concernant le rapport initial. Le rapport du programme de prime aux bogues de janvier 2025 aurait pu donner lieu à une tâche technique et à un examen des données contenues dans les configurations des indicateurs. Cela n'a pas été le cas. Nous mettons à jour notre processus de triage afin d'éviter que cela ne se reproduise à l'avenir.
2. HackerOne a mal géré la clôture pour cause de doublon. Le rapport d'avril 2026 faisait état d'un impact sensiblement différent de celui du rapport de janvier 2025. Il n'aurait pas dû être fermé comme doublon par HackerOne. Après un examen plus approfondi, nous avons identifié deux autres instances de rapports similaires qui ont été fermés : l'une le 6 septembre 2025 et l'autre le 1er janvier 2026. Nous travaillons avec HackerOne pour combler les lacunes de leurs processus de triage. Nous allons mettre en place un examen secondaire de tous les rapports HackerOne afin de nous assurer que nous ne dépendons pas de processus tiers à l'avenir.
3. Notre service de messagerie a classé la demande du chercheur dans le dossier des spams. Le samedi 25 avril, le chercheur a envoyé un e-mail à notre PDG et à security@clickup.com, et a envoyé un message privé au compte X de ClickUp.
Nous n'avons pris connaissance de ces e-mails qu'après la publication sur X. Ils ont été découverts à la suite d'une enquête interne portant sur les dossiers de spam et le filtrage des messages privés sur X.
Nous mettons à jour nos processus de filtrage des e-mails et de vérification des spams afin de garantir que les communications entrantes liées à la sécurité ne soient pas ignorées.
Rien de tout cela n'excuse le problème fondamental : les données clients n'auraient tout simplement jamais dû figurer dans nos configurations de Feature Flags.
Ce que nous avons fait
Immédiat (achevé)
- Le jeton API client exposé a été invalidé.
- Toutes les adresses e-mail des clients ont été supprimées des configurations des Feature Flags.
- Une directive a été émise à l'échelle de l'ingénierie interdisant l'utilisation de données à caractère personnel ou d'identifiants dans les configurations de drapeaux.
- Nous avons achevé un audit complet de tous les Feature Flags concernant les informations personnelles identifiables, les identifiants et les données sensibles.
À court terme (en cours)
- Mise à jour des règles de filtrage des e-mails afin de garantir que security@clickup.com affiche toutes les communications de sécurité entrantes, en ajoutant une étape permettant d'examiner (en toute sécurité) les messages indésirables.
- Révision des flux de travail de triage des programmes de prime aux bogues avec HackerOne afin d'éviter que des signalements valides ne soient fermés à tort.
- Formation des responsables de la validation des Feature Flags sur les contenus autorisés.
À long terme
- Analyse automatisée de toutes les configurations des Feature Flags à la recherche de données à caractère personnel (adresses e-mail, jetons, clés API) à chaque modification d'indicateur, avec application de mesures de blocage.
- Un processus d’automatisation et des outils permettant de réexaminer toutes les décisions de triage prises par HackerOne.
- Mettre en place un proxy ou une mesure technique permettant de séparer les indicateurs du front-end de ceux du back-end.
Une note sur le chercheur
Dès que ClickUp a pris contact avec le chercheur à l'origine de cette révélation, connu sous le pseudonyme impulsive / @weezerOSINT, l'entreprise a agi de manière responsable et a fourni toutes les informations demandées.
Le chercheur, connu sous le pseudonyme impulsive / @weezerOSINT, a signalé le problème par les voies officielles (HackerOne, puis par e-mail directement à sécurité@clickup.com et à notre PDG) et s'est montré constructif lorsque nous l'avons contacté. Nos processus internes n'ont pas permis de faire remonter son rapport et ses demandes d'escalade en temps voulu.
Après avoir collaboré avec le chercheur, ClickUp a reçu le message suivant le 28 avril à 1 h 47 UTC : « Merci [ClickUp], j'apprécie vraiment la rapidité avec laquelle vous avez réagi. Ce n'est pas quelque chose que je vois souvent, et cela fait toute la différence. »
ClickUp récompense le chercheur par une prime de sécurité pour ses découvertes. Nous encourageons les autres chercheurs à rejoindre notre programme de primes de sécurité, à signaler les bugs de manière responsable via notre programme de divulgation des vulnérabilités, ou directement par e-mail à l'adresse security@clickup.com.
Résumé
Les données exposées lors de cet incident se limitaient à 893 adresses e-mail : aucun contenu de l'environnement de travail, mot de passe ou donnée de facturation n'a été compromis pour aucun client, à l'exception d'un seul client mentionné ci-dessus. Nous travaillons directement avec lui pour vérifier que personne n'a accédé indûment à sa clé.
Nous présentons nos sincères excuses à nos clients pour cet incident et nous ferons tout ce qui est en notre pouvoir pour qu'une telle situation ne se reproduise plus.
Nous mettrons cet article à jour si de nouvelles informations sont disponibles. Si vous avez des questions, veuillez contacter sécurité@ClickUp.com.