27 kwietnia 2026 r. badacz ds. bezpieczeństwa ujawnił publicznie, że konfiguracja flag funkcji po stronie klienta w serwisie ClickUp narażała na ujawnienie danych osobowych. W szczególności w regułach kierowania flag funkcji osadzono 893 adresy e-mail klientów, a także jedną flagę, która nieprawidłowo odwoływała się do tokenu API klienta – wykorzystanego podczas reagowania na incydent w celu ograniczenia szybkości ruchu z tego obszaru roboczego.
Powinniśmy byli to wykryć wcześniej. Nie zrobiliśmy tego i jesteśmy wam winni jasne wyjaśnienie tego, co się stało, dlaczego tak się stało, jakie działania podjęliśmy w tej sprawie oraz jak zamierzamy poprawić sytuację w przyszłości.
Czy dotyczy to Ciebie?
Ujawnienie dotyczyło wyłącznie 893 adresów e-mail klientów wykorzystanych w regułach kierowania flagami funkcji, służących do określania, którzy użytkownicy widzą konkretne funkcje podczas wdrażania.
Jeśli otrzymałeś bezpośrednią wiadomość wysłaną najpóźniej 29 kwietnia (trwa), oznacza to, że Twój adres e-mail znalazł się wśród adresów uwzględnionych w konfiguracji flagi funkcji. Jeśli nie otrzymałeś od nas żadnej wiadomości, Twój adres e-mail nie znalazł się na liście adresatów.
- Żadna zawartość z obszaru roboczego (zadania, dokumenty, pliki ani dane projektowe) nie została ujawniona w przypadku żadnego klienta — z jednym potencjalnym wyjątkiem opisanym poniżej.
- Nie doszło do ujawnienia żadnych haseł, danych rozliczeniowych ani danych logowania do kont.
- Żaden system uwierzytelniania nie został naruszony.
Problem techniczny
ClickUp korzysta z Split.io (obecnie należącego do Harness) do zarządzania flagami funkcji. Podobnie jak większość zestawów SDK do obsługi flag funkcji po stronie przeglądarki, Split.io wymaga klucza SDK po stronie klienta osadzonego w pakiecie JavaScript aplikacji. Klucz ten jest celowo publiczny i służy SDK do oceny flag dla bieżącego użytkownika w przeglądarce. Jest to standardowe, udokumentowane zachowanie w Split.io, LaunchDarkly i podobnych platformach i nie stanowi luki w zabezpieczeniach.
Nie jest problemem sam klucz. Problemem jest to, co nasi inżynierowie umieścili w konfiguracjach flag.
Oto, co miało miejsce z technicznego punktu widzenia: platformy flag funkcji umożliwiają inżynierom kierowanie wdrażania funkcji do określonych użytkowników. Zespoły inżynierów ClickUp wykorzystywały adresy e-mail bezpośrednio w regułach kierowania flag. Przykładem może być włączenie funkcji dla określonej grupy beta testerów. Publicznie dostępny punkt końcowy splitChanges w SDK Split.io zwraca pełny zestaw definicji flag, w tym te reguły kierowania. Oznacza to, że każdy, kto posiada klucz po stronie klienta (który, powtórzę, celowo znajduje się w naszym kodzie frontendowym), mógłby pobrać te definicje flag i wyodrębnić zawarte w nich adresy e-mail.
Inżynierowie traktowali konfiguracje flag jako narzędzia wewnętrzne, podczas gdy architektura SDK z założenia umożliwia publiczne wyszukiwanie tych danych. To spowodowało, że adresy e-mail gromadziły się w miejscu, w którym nigdy nie powinny się znaleźć. Aktualizacje flag funkcji wymagają weryfikacji przez dwóch innych inżynierów, podobnie jak w przypadku kodu. Ten krok weryfikacji nie wykrył tego błędu.
Jedyny wyjątek – flaga skonfigurowana w celu ograniczenia szybkości dla pojedynczego klienta
Inżynier dyżurny, reagując na nadużycie interfejsu API, umieścił token API klienta w konfiguracji flagi ograniczającej szybkość w celu ograniczenia ruchu, co spowodowało, że token stał się potencjalnie dostępny do odczytu za pośrednictwem punktu końcowego SDK. Takie zdarzenie nie powinno mieć miejsca: dane uwierzytelniające nie powinny znajdować się w konfiguracjach flag. Natychmiast wyłączyliśmy ten token i na chwilę obecną analiza naszych logów nie wykazuje żadnych oznak złośliwego dostępu poza działaniami samego badacza. Żadne inne tokeny klientów ani dane obszaru roboczego nie były dostępne, a my współpracujemy bezpośrednio z tym klientem.
Co zostało ujawnione, a co nie
| Roszczenie | Nasze ustalenia |
| Klucz SDK zapisany na stałe w pakiecie | To jest poprawne i zgodne z zamierzeniami. Tak właśnie działają zestawy SDK do obsługi flag funkcji po stronie przeglądarki. Nie jest to samo w sobie luka w zabezpieczeniach. |
| 893 adresy e-mail klientów w regułach kierowania reklam na podstawie flag | Informacje aktualne w momencie publikacji raportu. Wszystkie adresy e-mail osób trzecich zostały usunięte 28 kwietnia o godz. 03:25 czasu UTC. |
| Aktywny token API klienta w konfiguracji flag | Potwierdzono. Dodano 7 października 2025 r. Unieważniono 27 kwietnia 2026 r. o godz. 12:05 UTC. |
| Uprawnienia do zapisu w serwisie Split.io | To prawidłowe zachowanie zgodne z założeniami. Punkty końcowe telemetrii w pakiecie SDK przeglądarki (wydarzenia/bulk, testImpressions) akceptują operacje zapisu w ramach standardowego działania pakietu SDK. Nie jest to błędna konfiguracja ClickUp. |
| „Brak działań naprawczych przez 15 miesięcy” | Nieprawidłowe sformułowanie; daty są poprawne. Pierwotny raport z 17 stycznia 2025 r. dotyczący klucza SDK nie doprowadził do powstania zadania inżynieryjnego, ponieważ sam klucz nie stanowił luki w zabezpieczeniach. Rzeczywistym problemem były adresy e-mail i konfiguracje flag, które nie zostały uwzględnione w tym pierwotnym raporcie. Konfiguracje flag zostały ujawnione serwisowi HackerOne dopiero 8 kwietnia 2026 r., a firma ClickUp dowiedziała się o nich dopiero 27 kwietnia 2026 r. |
oś czasu
Zależy nam na pełnej przejrzystości w kwestii tego, gdzie doszło do niepowodzeń w naszych procesach, w tym w przypadku naszego zewnętrznego dostawcy usług bug bounty oraz naszych własnych wewnętrznych narzędzi komunikacyjnych.
| Data | Wydarzenie |
| 17 stycznia 2025 r. | Badacz zgłosił ujawnienie klucza SDK serwisu Split.io do naszego programu nagród za wykrycie błędów na platformie BugCrowd. Biorąc pod uwagę zawartość raportu, zostało ono słusznie oznaczone jako zgłoszenie informacyjne zarówno przez BugCrowd, jak i ClickUp. |
| 3 czerwca 2025 r. | ClickUp przenosi program nagród za wykrycie błędów na platformę HackerOne. Wszystkie dotychczasowe zgłoszenia zostały pomyślnie przeniesione, w tym również powyższy problem. |
| 8 kwietnia 2026 r. | Badacz o pseudonimie impulsive opublikował na platformie HackerOne nowy, szczegółowy raport, w którym opisuje szerszy zakres skutków: 893 adresy e-mail klientów w regułach wykrywania zagrożeń, aktywny token API klienta oraz inne dane operacyjne. |
| 10 kwietnia 2026 r. | Analityk ds. selekcji zgłoszeń w serwisie HackerOne błędnie zamknął zgłoszenie jako duplikat zgłoszenia ze stycznia 2025 r., nie zauważając, że nowe zgłoszenie dotyczyło istotnie odmiennego i szerszego zakresu skutków. Po dokładniejszym zbadaniu sprawy zidentyfikowaliśmy dwie inne instancje błędnego zamknięcia podobnych zgłoszeń – jedną z 6 września 2025 r. i jedną z 1 stycznia 2026 r. |
| 21 kwietnia 2026 r. | Badacz sprzeciwia się zamknięciu sprawy, przekazując serwisowi HackerOne dodatkowe informacje. |
| 25 kwietnia 2026 r. | Badacz podejmuje bardziej zdecydowane działania: wysyła e-mail do dyrektora generalnego ClickUp oraz na adres security@clickup.com, a także wysyła prywatną wiadomość do ClickUp na platformie X, wyznaczając termin publicznego ujawnienia informacji na 2 maja. Te wiadomości e-mail skierowane do dyrektora generalnego ClickUp i na adres security@ zostają przechwycone przez filtry antyspamowe i nie docierają do adresatów. Prywatne wiadomości wysłane do ClickUp na platformie X zostały automatycznie odfiltrowane i nie zostały przeczytane. |
| 27 kwietnia 2026 r. ~10:42 UTC | Badacz publikuje te informacje na platformie X. |
| 27 kwietnia 2026 r., godz. 11:06 UTC | ClickUp otrzymuje powiadomienie. Zgłoszono incydent. Rozpoczęto procedurę reagowania na incydent oraz proces wymiany tokenu API klienta. |
| 27 kwietnia 2026 r., godz. 12:53–14:12 UTC | Wstępne porządkowanie flag podziału w poszczególnych zespołach inżynierów. |
| 27 kwietnia 2026 r. ~17:00 UTC | W pełni zautomatyzowany audyt wszystkich 4 809 flag funkcji został zakończony. |
| 27 kwietnia 2026 r., godz. 23:13 UTC | Inżynierowie z ClickUp i Harness (Split) analizują szczegóły techniczne. |
| 28 kwietnia 2026 r., godz. 03:25 UTC | Wszystkie adresy e-mail klientów zostały usunięte z konfiguracji flag. Uwaga: niektóre adresy e-mail stron trzecich celowo pozostały w dwóch flagach; wynika to z przypadków nadużyć. |
Gdzie zawiódł nasz proces
W tym przypadku popełniono trzy błędy i chcemy je wszystkie jasno wymienić. W następnej sekcji omówimy wprowadzone zmiany.
1. Brak dalszych działań w związku z pierwotnym zgłoszeniem. Raport dotyczący programu bug bounty ze stycznia 2025 r. mógł mieć dla inżynierów następujący wynik: zlecenie zadania oraz przegląd danych przechowywanych w konfiguracjach flag. Tak się jednak nie stało. Aktualizujemy nasz proces klasyfikacji zgłoszeń, aby zapobiec powtórzeniu się takiej sytuacji w przyszłości.
2. Serwis HackerOne nieprawidłowo potraktował zgłoszenie jako duplikat. Zgłoszenie z kwietnia 2026 r. zawierało informacje o znacznie większym zakresie skutków w porównaniu ze zgłoszeniem ze stycznia 2025 r. Serwis HackerOne nie powinien był go zamykać jako duplikat. Po dokładniejszym zbadaniu sprawy zidentyfikowaliśmy dwie inne instancje zamkniętych podobnych zgłoszeń – jedną z 6 września 2025 r. i jedną z 1 stycznia 2026 r. Współpracujemy z serwisem HackerOne w celu usunięcia luk w ich procesach selekcji zgłoszeń. Wprowadzimy dodatkową weryfikację wszystkich zgłoszeń z serwisu HackerOne, aby w przyszłości nie polegać wyłącznie na procesach stron trzecich.
3. Nasz system pocztowy oznaczył zgłoszenie badacza jako spam. W sobotę 25 kwietnia badacz wysłał e-mail zarówno do naszego dyrektora generalnego, jak i na adres security@clickup.com, a także wysłał prywatną wiadomość na konto ClickUp na platformie X.
Zauważyliśmy te wiadomości e-mail dopiero po opublikowaniu wpisu na X. Zostały one wykryte w wyniku wewnętrznego dochodzenia dotyczącego folderów ze spamem oraz filtrowania prywatnych wiadomości na X.
Aktualizujemy nasze procedury filtrowania wiadomości e-mail i sprawdzania spamu, aby zapewnić, że przychodzące wiadomości dotyczące bezpieczeństwa nie będą pomijane bez powiadomienia.
Żadna z tych rzeczy nie usprawiedliwia sedna problemu: dane klientów w ogóle nie powinny były znaleźć się w naszych konfiguracjach flag funkcji.
Co zrobiliśmy
Natychmiastowe (zakończone)
- Unieważniono ujawniony token API klienta.
- Usunięto wszystkie adresy e-mail klientów z konfiguracji flag funkcji.
- Wydano ogólnofirmową dyrektywę zakazującą umieszczania danych osobowych lub danych uwierzytelniających w konfiguracjach flag.
- Zakończono pełny audyt wszystkich flag funkcji dotyczących danych osobowych, danych uwierzytelniających i danych wrażliwych.
Krótkoterminowe (w trakcie postępu)
- Zaktualizowano reguły filtrowania wiadomości e-mail, aby adres security@ClickUp.com wyświetlał wszystkie przychodzące wiadomości dotyczące bezpieczeństwa, dodając krok procesu służący do (bezpiecznego) sprawdzania wiadomości spamowych.
- Przegląd cykli pracy selekcji zgłoszeń w ramach programu bug bounty we współpracy z HackerOne, mający na celu zapobieganie błędnemu zamykaniu uzasadnionych zgłoszeń.
- Szkolenie osób sprawdzających flagi funkcji w zakresie tego, jakie zawartości są dopuszczalne.
Długoterminowe
- Automatyczne skanowanie wszystkich konfiguracji flag funkcji pod kątem występowania danych osobowych (adresów e-mail, tokenów, kluczy API) przy każdej zmianie flagi, z automatycznym blokowaniem.
- Zautomatyzowany proces i narzędzia służące do weryfikacji wszystkich decyzji dotyczących klasyfikacji zgłoszeń w serwisie HackerOne.
- Wprowadź serwer proxy lub inne rozwiązanie techniczne w celu oddzielenia flag front-endu od flag back-endu.
Notatka o badaczu
Gdy firma ClickUp nawiązała kontakt z badaczem, który ujawnił tę informację, działającym pod pseudonimem impulsive / @weezerOSINT, postąpiła odpowiedzialnie i przekazała wszystkie wymagane informacje.
Badacz, posługujący się pseudonimem impulsive / @weezerOSINT, zgłosił sprawę odpowiednimi kanałami (HackerOne, a następnie bezpośrednio za pośrednictwem e-maila na adres security@ClickUp.com oraz do naszego dyrektora generalnego) i wykazał się konstruktywnym podejściem, gdy nawiązaliśmy z nim kontakt. Nasze wewnętrzne procedury nie pozwoliły na terminowe wykrycie jego raportu i eskalacji sprawy.
Po nawiązaniu współpracy z badaczem firma ClickUp otrzymała 28 kwietnia o godz. 1:47 czasu UTC następującą wiadomość: „Dziękuję [ClickUp], naprawdę doceniam waszą szybką reakcję. Nieczęsto się to zdarza, a to naprawdę ma znaczenie.”
ClickUp przyznaje badaczowi nagrodę w ramach programu Bug Bounty za wykryte luki. Zachęcamy innych badaczy do dołączenia do naszego programu Bug Bounty, raportowania luk w sposób odpowiedzialny za pośrednictwem naszego programu ujawniania luk w zabezpieczeniach lub bezpośrednio na adres e-mail security@clickup.com.
Podsumowanie
Zakres danych ujawnionych w wyniku tego incydentu ograniczał się do 893 adresów e-mail – nie miało to wpływu na zawartość obszarów roboczych, hasła ani dane rozliczeniowe żadnego klienta, z wyjątkiem jednego klienta, o którym wspomniano powyżej – współpracujemy z nim bezpośrednio, aby upewnić się, że nie doszło do nieuprawnionego dostępu do klucza.
Serdecznie przepraszamy naszych klientów za tę sytuację i dołożymy wszelkich starań, aby coś takiego nie powtórzyło się w przyszłości.
W razie pojawienia się nowych informacji zaktualizujemy ten wpis. W razie pytań prosimy o kontakt pod adresem security@ClickUp.com.