Am 27. April 2026 gab ein Sicherheitsforscher öffentlich bekannt, dass durch die Konfiguration der clientseitigen Feature Flags bei ClickUp personenbezogene Daten offengelegt wurden. Konkret waren 893 E-Mail-Adressen von Kunden in den Targeting-Regeln für Feature Flags eingebettet; außerdem gab es ein Flag, das fälschlicherweise auf das API-Token eines Kunden verwies, das im Rahmen einer Incident-Response-Maßnahme verwendet wurde, um ein Ratenlimit für den Datenverkehr aus diesem ClickUp-Workspace einzuführen.
Wir hätten das früher bemerken müssen. Das ist uns nicht gelungen, und wir schulden Ihnen eine klare Erklärung dafür, was passiert ist, warum es passiert ist, welche Maßnahmen wir inzwischen ergriffen haben und wie wir uns in Zukunft verbessern werden.
Sind Sie davon betroffen?
Die Datenpanne beschränkte sich auf 893 E-Mail-Adressen von Kunden, die in Targeting-Regeln für Feature Flags verwendet wurden, um zu steuern, welche Benutzer bestimmte Funktionen während der Einführung sehen.
Wenn Sie bis einschließlich 29. April (derzeit) eine direkte Nachricht von uns erhalten haben, war Ihre E-Mail-Adresse in einer Konfiguration von Feature Flags enthalten. Wenn Sie nichts von uns gehört haben, war Ihre E-Mail-Adresse nicht in der Liste der E-Mail-Adressen enthalten.
- Es wurden keine Workspace-Inhalte (Aufgaben, Dokumente, Dateien oder Projektdaten) von Kunden offengelegt – mit einer möglichen Ausnahme, die im Folgenden beschrieben wird.
- Es wurden keine Passwörter, Zahlungsdaten oder Daten zum Konto offengelegt.
- Es wurden keine Systeme der Authentifizierung kompromittiert.
Das technische Problem
ClickUp nutzt Split.io (mittlerweile Teil von Harness) für das Management von Feature Flags. Wie die meisten browserbasierten Feature Flags-SDKs erfordert Split.io einen clientseitigen SDK-Schlüssel, der in das JavaScript-Bundle der Anwendung eingebettet ist. Dieser Schlüssel ist absichtlich öffentlich und dient dem SDK dazu, Flags für den aktuellen Benutzer im Browser auszuwerten. Dies ist ein standardmäßiges, dokumentiertes Verhalten bei Split.io, LaunchDarkly und ähnlichen Plattformen und stellt keine Sicherheitslücke dar.
Der Schlüssel ist nicht das Problem. Entscheidend ist vielmehr, was unsere Ingenieure in die Flag-Konfigurationen einbauen.
Aus technischer Sicht lief es folgendermaßen ab: Feature Flags ermöglichen es Entwicklern, bestimmte Benutzer für die Einführung neuer Features gezielt anzusprechen. Die Entwicklerteams von ClickUp hatten E-Mail-Adressen direkt in den Targeting-Regeln für Flags verwendet. Ein Beispiel hierfür ist die Aktivierung einer Funktion für eine bestimmte Gruppe von Beta-Testern. Der öffentlich abfragbare Endpunkt „splitChanges“ des Split.io-SDKs gibt den vollständigen Satz an Flag-Definitionen zurück, einschließlich dieser Targeting-Regeln. Das bedeutet, dass jeder, der über den clientseitigen Schlüssel verfügt (der wiederum absichtlich in unserem Frontend-Code enthalten ist), diese Flag-Definitionen abrufen und die darin eingebetteten E-Mail-Adressen extrahieren könnte.
Die Entwickler behandelten die Flag-Konfigurationen als interne Tools, obwohl sie aufgrund der Architektur des SDK von vornherein öffentlich abfragbar sind. Dadurch sammelten sich die E-Mail-Adressen an einem Ort an, an dem sie niemals hätten sein dürfen. Aktualisierungen von Feature Flags erfordern – ähnlich wie bei Code – eine Peer-Review durch mindestens einen Kollegen. Dieser Schritt hat dies nicht erkannt.
Die einzige Ausnahme – Ein Flag, das für ein Ratenlimit für einen einzelnen Kunden konfiguriert ist
Ein Bereitschaftstechniker, der auf einen API-Missbrauch reagierte, gab in einer Konfiguration zur Ratenbegrenzung das API-Token eines Kunden an, um den Datenverkehr zu drosseln, wodurch dieses über den SDK-Endpunkt potenziell lesbar wurde. Das hätte niemals passieren dürfen: Anmeldedaten haben in Konfigurationsdateien nichts zu suchen. Wir haben das Token umgehend deaktiviert, und unsere Log-Auswertung zeigt bislang keine Anzeichen für böswillige Zugriffe, die über die Untersuchung des Forschers hinausgehen. Es war kein Zugriff auf andere Token oder Workspace-Daten möglich, und wir arbeiten direkt mit diesem Kunden zusammen.
Was wurde aufgedeckt und was nicht
| Behauptung | Unsere Erkenntnis |
| SDK-Schlüssel im Bundle fest codiert | Das ist korrekt und beabsichtigt. So funktionieren browserbasierte Feature Flags-SDKs. Es handelt sich nicht um eine Sicherheitslücke an sich. |
| 893 E-Mail-Adressen von Kunden in den Regeln für das Targeting nach Flaggen | Stand zum Zeitpunkt der Berichterstellung. Alle E-Mail-Adressen von Dritten wurden bis zum 28. April, 03:25 Uhr UTC, entfernt. |
| Live-Kunden-API-Token in der Flag-Konfiguration | Bestätigt. Hinzugefügt am 7. Oktober 2025. Für ungültig erklärt am 27. April 2026 um 12:05 Uhr UTC. |
| Schreibzugriff auf Split.io | Das ist korrekt und beabsichtigt. Die Telemetrie-Endpunkte des Browser-SDKs (Ereignisse/bulk, testImpressions) akzeptieren Schreibvorgänge als Teil des Standardverhaltens des SDKs. Dies ist keine Fehlkonfiguration von ClickUp. |
| „Keine Sanierungsmaßnahmen seit 15 Monaten“ | Falsch dargestellt; die Daten sind korrekt. Der ursprüngliche Bug-Bounty-Bericht vom 17. Januar 2025 über den SDK-Schlüssel hatte als Ergebnis nicht eine technische Aufgabe, da der Schlüssel allein nicht die Schwachstelle darstellt. Die E-Mail-Adressen und Flag-Konfigurationen waren das eigentliche Problem und in diesem ursprünglichen Bericht nicht enthalten. Die Flag-Konfigurationen wurden HackerOne erst am 8. April 2026 offengelegt und waren ClickUp bis zum 27. April 2026 nicht bekannt. |
Zeitleiste
Wir verpflichten uns zu vollständiger Transparenz hinsichtlich der Stellen, an denen unsere Prozesse versagt haben, einschließlich der Versäumnisse unseres externen Bug-Bounty-Anbieters und unserer eigenen internen Kommunikationstools.
| Datum | Ereignis |
| 17.01.2025 | Ein Forscher meldet die Offenlegung des Split.io-SDK-Schlüssels an unser Bug-Bounty-Programm auf BugCrowd. Angesichts des Inhalts des Berichts wurde dieser von BugCrowd und ClickUp zu Recht als „informativ“ eingestuft. |
| 03.06.2025 | ClickUp verlagert sein Bug-Bounty-Programm auf HackerOne. Alle bisherigen Berichte wurden erfolgreich migriert, einschließlich des oben genannten Problems. |
| 08.04.2026 | Der Forscher mit dem Pseudonym „impulsive“ hat auf HackerOne einen neuen, detaillierten Bericht veröffentlicht, in dem er die Ausmaße des Vorfalls dokumentiert: 893 E-Mail-Adressen von Kunden in den Regeln zur Erkennung von Bedrohungen, das aktive API-Token eines Kunden sowie weitere Betriebsdaten. |
| 10.04.2026 | Ein Triage-Analyst bei HackerOne hat den Bericht fälschlicherweise als Duplikat des Berichts vom Januar 2025 geschlossen und dabei übersehen, dass der neue Bericht wesentlich andere und weitreichendere Auswirkungen dokumentiert. Bei einer weiteren Überprüfung haben wir zwei weitere Instanzen identifiziert, in denen ähnliche Berichte fälschlicherweise geschlossen wurden – einen am 6. September 2025 und einen am 1. Januar 2026 |
| 21.04.2026 | Der Forscher widerspricht der Ablehnung und liefert HackerOne weitere Details. |
| 25.04.2026 | Der Forscher eskaliert die Angelegenheit: Er schickt eine E-Mail an den CEO von ClickUp und an security@clickup.com über HackerOne und setzt ClickUp über Direktnachrichten auf X eine Frist für die öffentliche Bekanntgabe bis zum 2. Mai. Diese E-Mails an den CEO von ClickUp und an security@ werden von Spamfiltern abgefangen und erreichen die vorgesehenen Empfänger nicht. Die Direktnachrichten an ClickUp auf X wurden automatisch gefiltert und nicht gelesen. |
| 27.04.2026 ~10:42 UTC | Der Forscher veröffentlicht dies auf X. |
| 27.04.2026, 11:06 Uhr UTC | ClickUp wird darauf aufmerksam. Der Incident wird gemeldet. Der Prozess zur Reaktion auf den Incident wird eingeleitet, und der Vorgang zur Erneuerung des Tokens für die API des Kunden wurde gestartet. |
| 27.04.2026, 12:53–14:12 UTC | Erste Bereinigung der Split-Flags in den verschiedenen Entwicklungsteams. |
| 27.04.2026 ~17:00 UTC | Die vollautomatische Überprüfung aller 4.809 Feature Flags wurde fertiggestellt. |
| 27.04.2026, 23:13 UTC | Die Entwickler von ClickUp und Harness (Split) besprechen technische Details. |
| 28.04.2026, 03:25 UTC | Alle bestätigten E-Mail-Adressen von Kunden wurden aus den Flag-Konfigurationen entfernt. Notiz: Einige E-Mail-Adressen von Drittanbietern bleiben absichtlich in zwei Flags erhalten; dies steht im Zusammenhang mit betrügerischer Nutzung. |
Wo unser Prozess gescheitert ist
Hier sind drei Dinge schiefgelaufen, und wir möchten jedes einzelne davon klar benennen. Im folgenden Abschnitt werden wir die Änderungen erörtern.
1. Keine Folgemaßnahmen auf der Grundlage des ursprünglichen Berichts. Der Bug-Bounty-Bericht vom Januar 2025 hätte das Ergebnis einer technischen Aufgabe und einer Überprüfung der in den Flag-Konfigurationen enthaltenen Daten sein können. Dies war jedoch nicht der Fall. Wir überarbeiten derzeit unseren Triage-Prozess, um zu verhindern, dass sich dies in Zukunft wiederholt.
2. HackerOne hat die Schließung als Duplikat falsch gehandhabt. Der Bericht vom April 2026 dokumentierte im Vergleich zum Bericht vom Januar 2025 wesentlich neue Auswirkungen. Er hätte von HackerOne nicht als Duplikat geschlossen werden dürfen. Bei einer weiteren Überprüfung haben wir zwei weitere Instanzen identifiziert, in denen ähnliche Berichte geschlossen wurden – eine am 6. September 2025 und eine am 1. Januar 2026. Wir arbeiten mit HackerOne zusammen, um Lücken in deren Triage-Prozessen zu beheben. Wir werden eine zweite Überprüfung aller HackerOne-Berichte einführen, um sicherzustellen, dass wir uns künftig nicht mehr auf Prozesse von Drittanbietern verlassen müssen.
3. Unser E-Mail-Dienst hat die Meldung des Forschers als Spam markiert. Am Samstag, dem 25. April, schickte der Forscher eine E-Mail sowohl an unseren CEO als auch an security@clickup.com und sandte eine Direktnachricht an das X-Konto von ClickUp.
Wir haben diese E-Mails erst nach der Veröffentlichung auf X gesehen. Sie wurden im Rahmen einer internen Untersuchung der Spam-Ordner und der Filterung von X-Direktnachrichten entdeckt.
Wir aktualisieren unsere E-Mail-Filter- und Spam-Prüfungsverfahren, um sicherzustellen, dass Nachrichten, die mit der Sicherheit zu tun haben, nicht unbemerkt verworfen werden.
Nichts davon entschuldigt das eigentliche Problem: Kundendaten hätten von vornherein niemals in unseren Feature Flags enthalten sein dürfen.
Was wir getan haben
Sofort (fertiggestellt)
- Das offengelegte API-Token des Kunden wurde gesperrt.
- Alle E-Mail-Adressen von Kunden wurden aus den Konfigurationen der Feature Flags entfernt.
- Es wurde eine abteilungsweite Richtlinie erlassen, die die Angabe personenbezogener Daten oder Anmeldedaten in Flag-Konfigurationen untersagt.
- Es wurde eine umfassende Prüfung aller Feature Flags auf personenbezogene Daten, Anmeldedaten und sensible Daten fertiggestellt.
Kurzfristig (In Bearbeitung)
- Die E-Mail-Filterregeln wurden aktualisiert, um sicherzustellen, dass security@clickup.com alle eingehenden Mitteilungen zur Sicherheit anzeigt; dazu wurde ein Schritt hinzugefügt, um Spam-Nachrichten (auf sichere Weise) zu prüfen.
- Überprüfung der Triage-Workflows im Rahmen des Bug-Bounty-Programms mit HackerOne, um zu verhindern, dass berechtigte Berichte fälschlicherweise geschlossen werden.
- Schulung der für Feature Flags zuständigen Prüfer hinsichtlich der zulässigen Inhalte.
Langfristig
- Automatische Überprüfung aller Feature-Flag-Konfigurationen auf Muster für personenbezogene Daten (E-Mail-Adressen, Tokens, API-Schlüssel) bei jeder Änderung eines Flags, mit automatischer Sperrung.
- Ein automatisierter Prozess und entsprechende Tools zur Überprüfung aller Triage-Entscheidungen bei HackerOne.
- Implementieren Sie einen Proxy oder eine technische Maßnahme, um Frontend-Flags und Backend-Flags voneinander zu trennen.
Eine Notiz zum Forscher
Nachdem ClickUp Kontakt zu dem Forscher aufgenommen hatte, der diese Informationen unter dem Pseudonym „impulsive / @weezerOSINT“ veröffentlicht hatte, handelte das Unternehmen verantwortungsbewusst und stellte alle angeforderten Informationen zur Verfügung.
Der Forscher, der unter dem Pseudonym „impulsive / @weezerOSINT“ auftritt, meldete den Vorfall über die vorgesehenen Kanäle (HackerOne, anschließend per E-Mail direkt an security@clickup.com und an unseren CEO) und zeigte sich konstruktiv, als wir Kontakt aufnahmen. Unsere internen Prozesse haben es versäumt, seinen Bericht und die Eskalationen rechtzeitig zu erkennen.
Nach der Zusammenarbeit mit dem Forscher erhielt ClickUp am 28. April um 1:47 Uhr UTC folgende Nachricht: „Danke [ClickUp], ich weiß es wirklich zu schätzen, wie schnell ihr hier gehandelt habt. Das sehe ich nicht oft, und es macht einen Unterschied.“
ClickUp belohnt den Forscher für seine Entdeckung mit einer Prämie. Andere Forscher sind herzlich eingeladen, an unserem Bug-Bounty-Programm teilzunehmen, ihre Entdeckungen verantwortungsbewusst über unser Programm zur Offenlegung von Sicherheitslücken oder direkt per E-Mail an security@clickup.com zu melden.
Zusammenfassung
Der Umfang der bei diesem Incident offengelegten Daten beschränkte sich auf 893 E-Mail-Adressen – mit Ausnahme des oben genannten einzelnen Kunden waren weder Workspace-Inhalte noch Passwörter oder Abrechnungsdaten von Kunden betroffen. Wir arbeiten direkt mit diesem Kunden zusammen, um sicherzustellen, dass nicht unbefugt auf den Schlüssel zugegriffen wurde.
Wir möchten uns bei unseren Kunden aufrichtig dafür entschuldigen, dass es dazu gekommen ist, und werden alles in unserer Macht Stehende zu erledigen haben, um sicherzustellen, dass so etwas nicht noch einmal passiert.
Wir werden diesen Beitrag aktualisieren, sobald neue Informationen vorliegen. Bei Fragen wenden Sie sich bitte an Sicherheit@ClickUp.com.