На 27 април 2026 г. изследовател в областта на сигурността разкри публично, че конфигурацията на флаговете за функции от страна на клиента в ClickUp е изложила на риск лична информация. По-конкретно, 893 имейл адреса на клиенти са били вградени в правилата за насочване на флаговете за функции, заедно с един флаг, който неправилно е съдържал препратка към API токена на клиент, използван по време на реакция при инцидент за ограничаване на трафика от съответното работно пространство.
Трябваше да забележим това по-рано. Не го направихме и ви дължим ясно обяснение за това какво се случи, защо, какво предприехме по въпроса и как ще подобрим работата си занапред.
Засегнати ли сте?
Изтичането на информация засягаше само 893 имейл адреса на клиенти, използвани в правилата за насочване на функционални флагове, за да се контролира кои потребители виждат конкретни функции по време на внедряването.
Ако сте получили пряко съобщение на или преди 29 април (процесът все още продължава), вашият имейл адрес е бил включен в конфигурацията на функционалния флаг. Ако не сте получили съобщение от нас, вашият имейл адрес не е бил в списъка с имейл адреси.
- Няма изтичане на информация от работната среда (задачи, документи, файлове или данни по проекти) за нито един клиент — с едно потенциално изключение, описано по-долу.
- Няма изтекли пароли, данни за фактуриране или данни за достъп до акаунти.
- Нито една система за удостоверяване не е била компрометирана.
Техническият проблем
ClickUp използва Split.io (сега част от Harness) за управление на флаговете на функциите. Подобно на повечето SDK за флагове на функции от страна на браузъра, Split.io изисква ключ за SDK от страна на клиента, вграден в JavaScript пакета на приложението. Този ключ е умишлено публичен и по този начин SDK оценява флаговете за текущия потребител в браузъра. Това е стандартно, документирано поведение в Split.io, LaunchDarkly и подобни платформи и не представлява уязвимост.
Ключът не е проблемът. Проблемът е това, което нашите инженери включват в конфигурациите на флаговете.
Ето какво се случи от архитектурна гледна точка: платформите за флагове на функции позволяват на инженерите да насочват внедряването на функции към конкретни потребители. Инженерните екипи на ClickUp са използвали имейл адреси директно в правилата за насочване на флаговете. Пример за това е активирането на функция за конкретна група бета тестери. Публично достъпният ендпойнт splitChanges на Split.io SDK връща пълния набор от дефиниции на флаговете, включително тези правила за насочване. Това означава, че всеки, който разполага с ключа от страна на клиента (който, отново, умишлено се намира в нашия фронтенд код), може да извлече тези дефиниции на флаговете и да извлече имейл адресите, вградени в тях.
Инженерите третираха конфигурациите на флаговете като вътрешни инструменти, въпреки че архитектурата на SDK по проект позволява те да бъдат достъпни за публично търсене. Това доведе до натрупване на имейл адреси на място, където те никога не би трябвало да се намират. Актуализациите на флаговете за функции изискват рецензия от колега с ранг +1, подобно на кода. Тази стъпка от процеса на рецензиране не е успяла да засече този проблем.
Единственото изключение – флаг, настроен за ограничаване на скоростта на един клиент
Инженер, дежурен по време на инцидента, свързан със злоупотреба с API, е посочил API токена на клиент в конфигурацията на флага за ограничаване на скоростта с цел регулиране на трафика, което е направило токена потенциално достъпен за четене чрез SDK крайната точка. Това никога не би трябвало да се случи: идентификационните данни нямат място в конфигурациите на флаговете. Веднага деактивирахме токена и към момента разследването на логовете не показва признаци за злонамерен достъп извън рамките на собственото разследване на изследователя. Няма достъп до други токени на клиенти или данни от работната среда и ние работим директно с този клиент.
Какво беше разкрито и какво не
| Твърдение | Нашите констатации |
| SDK ключът е твърдо кодиран в пакета | Това е правилно и е предвидено в дизайна. Така функционират SDK-тата за функционални флагове от страна на браузъра. Не става въпрос само за уязвимост. |
| 893 имейл адреса на клиенти в правилата за таргетиране по флагове | Вярно към момента на публикуване на доклада. Всички имейл адреси на трети страни бяха премахнати на 28 април в 03:25 UTC. |
| Активен токен за API на клиента в конфигурацията на флаговете | Потвърдено. Добавено на 7 октомври 2025 г. Отменено на 27 април 2026 г. в 12:05 UTC. |
| Право на запис в Split.io | Това е правилно и е предвидено в дизайна. Крайните точки за телеметрия на SDK на браузъра (events/bulk, testImpressions) приемат записи като част от стандартното поведение на SDK. Това не е грешка в настройките на ClickUp. |
| „Без саниране в продължение на 15 месеца“ | Неправилно описано; датите са верни. Първоначалният доклад за награда за откриване на бъг от 17 януари 2025 г. относно ключа на SDK не доведе до инженерна задача, тъй като самият ключ не представлява уязвимост. Имейл адресите и конфигурациите на флаговете бяха действителният проблем и не бяха включени в този първоначален доклад. Конфигурациите на флаговете не бяха разкрити пред HackerOne до 8 април 2026 г. и не бяха известни на ClickUp до 27 април 2026 г. |
Хронология
Ние се ангажираме да бъдем напълно прозрачни по отношение на това къде са се провалили нашите процеси, включително пропуските от страна на нашия външен доставчик на услуги за откриване на уязвимости и нашите собствени инструменти за вътрешна комуникация.
| Дата | Събитие |
| 17 януари 2025 г. | Изследовател съобщава за разкриването на ключ от SDK на Split.io в нашата програма за награди за откриване на бъгове в BugCrowd. Предвид съдържанието на доклада, той беше правилно класифициран като „информационен“ от BugCrowd и ClickUp. |
| 03.06.2025 г. | ClickUp прехвърля програмата за награди за откриване на бъгове към HackerOne. Всички предишни сигнали са успешно прехвърлени, включително и посочения по-горе проблем. |
| 08.04.2026 г. | Изследовател с псевдоним „impulsive“ публикува нов, подробен доклад в HackerOne, в който описва по-широкия обхват на инцидента: 893 имейл адреса на клиенти в правилата за маркиране, активен API токен на клиент, както и други оперативни данни. |
| 10 април 2026 г. | Анализаторът по сортиране на HackerOne погрешно затваря доклада като дубликат на доклада от януари 2025 г., като пропуска факта, че новият доклад документира съществено различно и по-широко въздействие. При по-нататъшен преглед установихме още два случая на подобни доклади, които са били погрешно затворени – един на 6 септември 2025 г. и един на 1 януари 2026 г. |
| 21 април 2026 г. | Изследователят опровергава твърдението, като предоставя допълнителна информация на HackerOne. |
| 25 април 2026 г. | Изследователят засилва натиска: чрез HackerOne изпраща имейл до главния изпълнителен директор на ClickUp и на адреса security@clickup.com, а чрез директни съобщения в X поставя краен срок за публично разкриване на информацията на 2 май. Тези имейли до главния изпълнителен директор на ClickUp и адреса security@ са блокирани от спам филтрите и не достигат до адресатите. Директните съобщения в X до ClickUp са били автоматично филтрирани и не са прочетени. |
| 27.04.2026 г., около 10:42 UTC | Изследователят публикува информацията в X. |
| 27.04.2026 г., 11:06 UTC | ClickUp получава уведомление. Инцидентът е обявен. Стартира процесът за реагиране при инциденти и е задействана процедурата за подмяна на API токена на клиента. |
| 27.04.2026 г., 12:53–14:12 UTC | Първоначално разпределение на задачите за почистване на флаговете между инженерните екипи. |
| 27.04.2026 г., около 17:00 UTC | Завършен е напълно автоматизираният одит на всички 4 809 флага за функции. |
| 27 април 2026 г., 23:13 UTC | Инженерите от ClickUp и Harness (Split) обсъждат техническите подробности. |
| 28 април 2026 г., 03:25 UTC | Всички имейл адреси на клиенти, чиято валидност е потвърдена, са премахнати от конфигурациите на флаговете. Забележка: някои имейл адреси на трети страни умишлено остават в два флага; това е свързано с измамна употреба. |
Къде се провали процесът ни
Тук има три проблема и искаме да ги посочим ясно. В следващия раздел ще обсъдим промените.
1. Липса на последващи действия във връзка с първоначалния доклад. Докладът за наградата за откриване на бъгове от януари 2025 г. би могъл да доведе до възлагане на инженерна задача и преглед на данните, съдържащи се в конфигурациите на флаговете. Това обаче не се случи. Актуализираме процеса си за сортиране на сигналите, за да предотвратим повторение на подобна ситуация в бъдеще.
2. HackerOne е допуснал грешка при затварянето на доклада като дубликат. Докладът от април 2026 г. документираше значително по-голямо въздействие в сравнение с доклада от януари 2025 г. Той не е трябвало да бъде затворен като дубликат от HackerOne. При по-нататъшен преглед идентифицирахме още два случая на затваряне на подобни доклади – един на 6 септември 2025 г. и един на 1 януари 2026 г. Работим с HackerOne за отстраняване на пропуските в техните процеси за сортиране. Ще включим вторичен преглед на всички доклади на HackerOne, за да се уверим, че в бъдеще няма да разчитаме на процеси на трети страни.
3. Нашата услуга за електронна поща маркира съобщението на изследователя като спам. В събота, 25 април, изследователят изпрати имейл както на нашия главен изпълнителен директор, така и на security@clickup.com, и изпрати лично съобщение на профила на ClickUp в X.
Видяхме тези имейли едва след публикуването на поста в X. Те бяха открити в резултат на вътрешно разследване на папките със спам и филтрирането на личните съобщения в X.
Актуализираме процесите си за филтриране на имейли и проверка на спам, за да гарантираме, че входящите съобщения, свързани със сигурността, няма да бъдат пренебрегнати.
Нищо от това не оправдава основния проблем: данните на клиентите изобщо не трябваше да се намират в конфигурациите на нашите функционални флагове.
Какво сме направили
Незабавно (завършено)
- Анулирахме разкрития API токен на клиента.
- Премахнахме всички имейл адреси на клиенти от конфигурациите на функционалните флагове.
- Издадена е обща за инженерния отдел директива, забраняваща включването на лична информация или идентификационни данни в конфигурациите на флаговете.
- Извършен е пълен одит на всички флагове за функции, свързани с лична информация, идентификационни данни и чувствителни данни.
Краткосрочно (в процес на изпълнение)
- Актуализирахме правилата за филтриране на имейли, за да гарантираме, че security@clickup.com показва всички входящи съобщения, свързани със сигурността, като добавихме стъпка в процеса за (безопасно) проверка на спам съобщенията.
- Преглед на работните процеси за сортиране на сигналите за откриване на бъгове чрез HackerOne, с цел да се предотврати неправилното затваряне на валидни сигнали.
- Обучение на лицата, отговарящи за проверката на флаговете за функции, относно това какво представлява одобреното съдържание.
Дългосрочно
- Автоматично сканиране на всички конфигурации на флаговете за функции за наличие на модели на лична информация (е-mail адреси, токени, API ключове) при всяка промяна на флага, съпроводено с принудително блокиране.
- Автоматизиран процес и инструментариум за преглед на всички решения за сортиране, взети от HackerOne.
- Въведете прокси или техническа мярка за разделяне на флаговете на фронтенда и флаговете на бекенда.
Няколко думи за изследователя
След като ClickUp се свърза с изследователя, разкрил тази информация, който използва псевдонима impulsive / @weezerOSINT, компанията реагира отговорно и предостави цялата поискана информация.
Изследователят, действащ под псевдонима impulsive / @weezerOSINT, подаде сигнал по установените канали (HackerOne, след което изпрати директно имейл до security@clickup.com и до нашия главен изпълнителен директор) и прояви конструктивно сътрудничество, когато се свързахме с него. Нашите вътрешни процедури не успяха да отразят навреме неговия сигнал и ескалациите по случая.
След като работиха с изследователя, на 28 април в 1:47 UTC екипът на ClickUp получи следното съобщение: „Благодаря, [ClickUp], наистина оценявам колко бързо реагирахте. Не е нещо, което виждам често, и това прави разликата.“
ClickUp възнаграждава изследователя с награда за откритата уязвимост. Приканваме и други изследователи да се включат в нашата програма за награди за откриване на уязвимости, да съобщават за откритите проблеми по отговорен начин чрез нашата програма за разкриване на уязвимости или директно по имейл на адрес security@clickup.com.
Резюме
Обхватът на данните, изтекли при този инцидент, се ограничава до 893 имейл адреса – не е засегнато съдържание от работната среда, пароли или данни за фактуриране на нито един клиент, с изключение на един-единствен клиент, споменат по-горе – ние работим директно с него, за да проверим дали не е имало неправомерен достъп до ключа.
Извиняваме се искрено пред нашите клиенти за случилото се и ще направим всичко възможно, за да гарантираме, че подобно нещо няма да се повтори.
Ще актуализираме тази публикация, ако се появи нова информация. Ако имате въпроси, пишете ни на security@clickup.com.