27 april – Wat is er gebeurd met de configuratie van onze functies?

Op 27 april 2026 maakte een beveiligingsonderzoeker bekend dat de configuratie van de feature flags aan de clientzijde bij ClickUp persoonlijk identificeerbare informatie blootlegde. Concreet waren 893 e-mailadressen van klanten opgenomen in de targetingregels voor feature flags, samen met één flag die ten onrechte verwees naar het API-token van een klant, dat tijdens een incidentrespons was gebruikt om de limiet voor verkeer vanuit die werkruimte te beperken.

We hadden dit eerder moeten opmerken. Dat is niet gebeurd, en we zijn jullie een duidelijke uitleg verschuldigd over wat er is gebeurd, waarom, wat we er inmiddels aan hebben gedaan en hoe we het in de toekomst beter gaan aanpakken.

Heeft u hier last van?

De inbreuk bleef beperkt tot 893 e-mailadressen van klanten die werden gebruikt in targetingregels voor feature flags om te bepalen welke gebruikers tijdens de uitrol bepaalde functies te zien krijgen.

Als u vóór of op 29 april (nog steeds) een rechtstreeks bericht van ons hebt ontvangen, stond uw e-mailadres vermeld in een configuratie van een feature flag. Als u niets van ons hebt gehoord, stond uw e-mailadres niet op de lijst met e-mailadressen.

Het technische probleem

ClickUp maakt gebruik van Split.io (nu onderdeel van Harness) voor het beheer van feature flags. Net als de meeste browser-side feature flag SDK's vereist Split.io een client-side SDK-sleutel die in de JavaScript-bundel van de applicatie is ingebed. Deze sleutel is opzettelijk openbaar en op deze manier evalueert de SDK flags voor de huidige gebruiker in de browser. Dit is standaard, gedocumenteerd gedrag bij Split.io, LaunchDarkly en vergelijkbare platforms, en het is geen kwetsbaarheid.

Het probleem is niet de sleutel zelf, maar wat onze technici in de vlagconfiguraties hebben ingebouwd.

Dit is wat er op architecturaal vlak gebeurde: met feature flag-platforms kunnen ontwikkelaars bij de uitrol van functies specifieke gebruikers targeten. De engineeringteams van ClickUp hadden e-mailadressen rechtstreeks in de targetingregels voor flags gebruikt. Een voorbeeld hiervan is het inschakelen van een functie voor een specifieke groep bètatesters. Het openbaar doorzoekbare splitChanges-eindpunt van de Split.io SDK retourneert de volledige set flagdefinities, inclusief deze targetingregels. Dit betekent dat iedereen met de client-side sleutel (die, nogmaals, opzettelijk in onze frontend-code staat) die flagdefinities kon ophalen en de daarin ingebedde e-mailadressen kon extraheren.

Ontwikkelaars beschouwden vlagconfiguraties als interne hulpmiddelen, terwijl de SDK-architectuur deze per definitie openbaar toegankelijk maakt. Daardoor konden de e-mailadressen zich ophopen op een plek waar ze nooit hadden mogen staan. Bij updates van functie-vlaggen is een peer review met +1 vereist, net als bij code. Deze stap heeft dit niet opgemerkt.

De enige uitzondering – Een vlag die is geconfigureerd voor de limiet voor één enkele klant

Een technicus die op afroep beschikbaar was en reageerde op API-misbruik, had het API-token van een klant opgenomen in een configuratie voor limietbeperking om het verkeer af te remmen, waardoor het mogelijk via het SDK-eindpunt kon worden ingezien. Dit had nooit mogen gebeuren: inloggegevens horen niet thuis in configuraties voor limietbeperking. We hebben het token onmiddellijk uitgeschakeld en uit ons logboekonderzoek blijkt tot nu toe dat er geen aanwijzingen zijn voor kwaadwillige toegang buiten het onderzoek van de onderzoeker zelf. Er was geen toegang tot andere klanttokens of werkruimtegegevens, en we werken rechtstreeks samen met deze klant.

Wat wel en wat niet aan het licht kwam

tijdlijn

We streven ernaar volledig transparant te zijn over de punten waarop onze processen tekortschoten, met inbegrip van tekortkomingen bij onze externe bugbounty-provider en onze eigen interne communicatiemiddelen.

Waar ons proces tekortschoot

Er zijn hier drie dingen misgegaan, en we willen ze allemaal duidelijk benoemen. In het volgende hoofdstuk bespreken we de aanpassingen.

1. Er is geen vervolg gegeven aan het oorspronkelijke rapport. Het bugbounty-rapport van januari 2025 had kunnen leiden tot een technische Taak en een onderzoek naar welke gegevens er in de vlagconfiguraties stonden. Dat is niet gebeurd. We passen ons triageproces aan om te voorkomen dat dit in de toekomst nog eens gebeurt.

2. HackerOne heeft de afsluiting als dubbel gemeld onjuist afgehandeld. Het rapport van april 2026 beschreef aanzienlijk nieuwe gevolgen in vergelijking met het rapport van januari 2025. Het had door HackerOne niet als dubbel gemeld mogen worden afgesloten. Bij nader onderzoek hebben we nog twee andere gevallen geïdentificeerd waarin soortgelijke rapporten werden gesloten – één op 6 september 2025 en één op 1 januari 2026. We werken samen met HackerOne om hiaten in hun triageprocessen aan te pakken. We zullen een secundaire beoordeling van alle HackerOne-rapporten opnemen om ervoor te zorgen dat we in de toekomst niet afhankelijk zijn van processen van derden.

3. Onze e-mailservice heeft de melding van de onderzoeker als spam gemarkeerd. Op zaterdag 25 april stuurde de onderzoeker een e-mail naar zowel onze CEO als security@clickup.com, en stuurde hij een privébericht naar het X-account van ClickUp.

We hebben deze e-mails pas gezien nadat het bericht op X openbaar was gemaakt. Ze zijn aan het licht gekomen na een intern onderzoek naar spammaps en de filtering van DM’s op X.

We zijn bezig met het aanpassen van onze procedures voor e-mailfiltering en spamcontrole om ervoor te zorgen dat inkomende berichten die van belang zijn voor de veiligheid niet ongemerkt worden verwijderd.

Dit alles neemt het kernprobleem niet weg: klantgegevens hadden überhaupt nooit in onze feature flag-configuraties mogen staan.

Wat we hebben gedaan

Onmiddellijk (voltooid)

Korte termijn (in uitvoering)

Op lange termijn

Een aantekening over de onderzoeker

Toen ClickUp eenmaal contact had gelegd met de onderzoeker die dit aan het licht had gebracht – die opereert onder de gebruikersnaam impulsive / @weezerOSINT – handelde het bedrijf verantwoord en verstrekte het alle gevraagde informatie.

De onderzoeker, die onder de gebruikersnaam impulsive / @weezerOSINT opereert, heeft via de juiste kanalen (HackerOne, vervolgens via een rechtstreekse e-mail aan security@clickup.com en onze CEO) melding gedaan en heeft constructief meegewerkt toen wij contact met hem opnamen. Onze interne processen hebben er niet in geslaagd zijn rapport en de daaropvolgende escalaties tijdig aan het licht te brengen.

Na de samenwerking met de onderzoeker ontving ClickUp op 28 april om 01:47 UTC het volgende bericht: „Bedankt [ClickUp], ik waardeer het enorm hoe snel jullie hierop hebben gereageerd. Dat zie ik niet vaak en het maakt echt een verschil.”

ClickUp beloont de onderzoeker met een bugbounty voor zijn of haar bevindingen. Andere onderzoekers worden aangemoedigd om deel te nemen aan ons bugbountyprogramma, op verantwoorde wijze melding te maken via ons programma voor het melden van kwetsbaarheden, of rechtstreeks via e-mail op security@clickup.com.

Samenvatting

De gegevens die bij dit incident zijn blootgesteld, bleven beperkt tot 893 e-mailadressen – er zijn geen werkruimte-inhoud, wachtwoorden of factuurgegevens van klanten aangetast, met uitzondering van één klant waarnaar hierboven wordt verwezen – we werken rechtstreeks met deze klant samen om na te gaan of er geen ongeoorloofde toegang tot de sleutel heeft plaatsgevonden.

Wij bieden onze klanten onze oprechte excuses aan voor wat er is gebeurd en zullen er alles aan doen om ervoor te zorgen dat zoiets niet nog eens gebeurt.

We zullen dit bericht bijwerken zodra er nieuwe informatie bekend wordt. Neem bij vragen contact op via veiligheid@ClickUp.com.