Den 27 april 2026 avslöjade en säkerhetsforskare offentligt att ClickUps konfiguration av funktionsflaggor på klientsidan hade exponerat personligt identifierbar information. Mer specifikt hade 893 kundernas e-postadresser inbäddats i riktningsreglerna för funktionsflaggor, tillsammans med en flagga som felaktigt hänvisade till en kunds API-token, vilken använts under en incidenthantering för att begränsa trafiken från det arbetsområdet.
Vi borde ha upptäckt detta tidigare. Det gjorde vi inte, och vi är skyldiga er en tydlig förklaring av vad som hände, varför det hände, vilka åtgärder vi har vidtagit och hur vi ska förbättra situationen framöver.
Är du drabbad?
Exponeringen begränsades till 893 kund-e-postadresser som användes i regler för inriktning av funktionsflaggor för att styra vilka användare som ser vissa funktioner under lanseringar.
Om du har fått ett direkt meddelande senast den 29 april (pågår), ingick din e-postadress i en konfiguration av funktionsflaggor. Om du inte har hört något från oss, fanns din e-postadress inte med på listan över e-postadresser.
- Inget innehåll i arbetsytan (uppgifter, dokument, filer eller projektdata) har läckt ut för någon kund – med ett möjligt undantag som beskrivs nedan.
- Inga lösenord, faktureringsuppgifter eller inloggningsuppgifter har läckt ut.
- Inga autentiseringssystem har utsatts för intrång.
Det tekniska problemet
ClickUp använder Split.io (numera en del av Harness) för hantering av funktionsflaggor. Liksom de flesta SDK:er för funktionsflaggor på webbläsarsidan kräver Split.io en SDK-nyckel på klientsidan som är inbäddad i applikationens JavaScript-paket. Denna nyckel är avsiktligt offentlig och det är så SDK:n utvärderar flaggor för den aktuella användaren i webbläsaren. Detta är ett standardiserat och dokumenterat beteende hos Split.io, LaunchDarkly och liknande plattformar, och det utgör inte någon sårbarhet.
Det är inte nyckeln som är problemet. Det är vad våra ingenjörer lägger in i flaggkonfigurationerna.
Så här såg det ut ur ett arkitektoniskt perspektiv: plattformar för funktionsflaggor gör det möjligt för utvecklare att rikta in sig på specifika användare vid lansering av nya funktioner. ClickUps teknikteam hade använt e-postadresser direkt i reglerna för flagginriktning. Ett exempel är att aktivera en funktion för en specifik grupp betatestare. Split.io SDK:s offentligt sökbara splitChanges-ändpunkt returnerar hela uppsättningen flaggdefinitioner, inklusive dessa inriktningsregler. Detta innebär att vem som helst med klientsidans nyckel (som, återigen, avsiktligt finns i vår frontend-kod) kunde hämta dessa flaggdefinitioner och extrahera de e-postadresser som var inbäddade i dem.
Ingenjörerna betraktade flaggkonfigurationerna som interna verktyg, trots att SDK-arkitekturen enligt sin utformning gör dem tillgängliga för allmän sökning. Detta ledde till att e-postadresserna samlades på en plats där de aldrig borde ha funnits. Uppdateringar av funktionsflaggor kräver en +1-granskning av kollegor, precis som för kod. Detta granskningssteg upptäckte inte felet.
Det enda undantaget – En flagga som är konfigurerad för att begränsa hastigheten för en enskild kund
En jourtekniker som hanterade ett fall av API-missbruk angav en kunds API-token i en konfiguration för hastighetsbegränsning för att strypa trafiken, vilket gjorde att token potentiellt kunde läsas via SDK-ändpunkten. Detta borde aldrig ha hänt: inloggningsuppgifter hör inte hemma i flaggkonfigurationer. Vi inaktiverade token omedelbart, och hittills visar vår loggundersökning inga tecken på skadlig åtkomst utöver forskarens egen undersökning. Inga andra kundtoken eller arbetsplatsdata var tillgängliga, och vi arbetar direkt med denna kund.
Vad som avslöjades och vad som inte avslöjades
| Påstående | Vår slutsats |
| SDK-nyckeln är fast inbyggd i paketet | Det är korrekt och avsiktligt. Så fungerar SDK:er för funktionsflaggor på webbläsarsidan. Det är inte en säkerhetsbrist i sig. |
| 893 kundernas e-postadresser i reglerna för flaggbaserad målgruppsinriktning | Uppgifterna är korrekta vid tidpunkten för rapporten. Alla e-postadresser från tredje part har tagits bort den 28 april kl. 03:25 UTC. |
| Aktivt API-token för kunder i flaggkonfigurationen | Bekräftad. Lagd till den 7 oktober 2025. Ogiltigförklarad den 27 april 2026 kl. 12:05 UTC. |
| Skrivbehörighet till Split.io | Det är korrekt och enligt specifikationen. Telemetri-slutpunkterna i webbläsarens SDK (events/bulk, testImpressions) tillåter skrivningar som en del av SDK:ns standardfunktioner. Detta beror inte på någon felaktig konfiguration i ClickUp. |
| ”Ingen sanering på 15 månader” | Felaktig beskrivning; datumen är korrekta. Den ursprungliga bug bounty-rapporten från den 17 januari 2025 om SDK-nyckeln ledde inte till någon teknisk åtgärd, eftersom nyckeln i sig inte utgör sårbarheten. E-postadresserna och flaggkonfigurationerna var det egentliga problemet och ingick inte i den ursprungliga rapporten. Flaggkonfigurationerna avslöjades inte för HackerOne förrän den 8 april 2026 och var inte kända för ClickUp förrän den 27 april 2026. |
Tidslinje
Vi är fast beslutna att vara helt öppna med var våra processer brast, inklusive brister hos vår externa leverantör av buggbounty-program och våra egna interna kommunikationsverktyg.
| Datum | Evenemang |
| 17 januari 2025 | En forskare rapporterade avslöjandet av Split.io SDK-nyckeln till vårt bug bounty-program på BugCrowd. Med tanke på rapportens innehåll klassificerades detta korrekt som ”informativt” av både BugCrowd och ClickUp. |
| 3 juni 2025 | ClickUp flyttar sitt bug bounty-program till HackerOne. Alla tidigare rapporter har migrerats utan problem, inklusive problemet ovan. |
| 8 april 2026 | Forskaren med användarnamnet impulsive har publicerat en ny, detaljerad rapport på HackerOne där den redogör för den omfattande skadan: 893 kundernas e-postadresser i regler för flaggning, aktiva API-token för kunder samt annan driftsdata. |
| 10 april 2026 | En triageanalytiker hos HackerOne stängde felaktigt rapporten som en dubblett av rapporten från januari 2025, utan att uppmärksamma att den nya rapporten dokumenterade väsentligt annorlunda och mer omfattande konsekvenser. Vid en närmare granskning upptäckte vi ytterligare två fall där liknande rapporter felaktigt hade stängts – ett den 6 september 2025 och ett den 1 januari 2026 |
| 21 april 2026 | Forskaren invänder mot stängningen och lämnar ytterligare information till HackerOne. |
| 25 april 2026 | Forskaren trappar upp sina åtgärder: via HackerOne skickar han e-post till ClickUps VD och till security@clickup.com, samt skickar direktmeddelanden till ClickUp på X, där han sätter den 2 maj som deadline för offentliggörandet. Dessa e-postmeddelanden till ClickUps VD och security@ fastnar i spamfiltren och når inte fram till de avsedda mottagarna. Direktmeddelandena till ClickUp på X filtrerades bort automatiskt och lästes aldrig. |
| 2026-04-27 kl. 10:42 UTC | Forskaren offentliggör detta på X. |
| 27 april 2026, kl. 11:06 UTC | ClickUp får kännedom om händelsen. Incidenten rapporteras. Incidenthanteringsprocessen inleds och processen för att byta ut kundens API-token påbörjas. |
| 27 april 2026, kl. 12:53–14:12 UTC | Inledande uppstädning av split-flaggor inom de olika utvecklingsgrupperna. |
| 27 april 2026, kl. 17.00 UTC | Den helt automatiserade granskningen av samtliga 4 809 funktionsflaggor är nu avslutad. |
| 27 april 2026, kl. 23:13 UTC | Tekniker från ClickUp och Harness (Split) går igenom de tekniska detaljerna. |
| 28 april 2026, kl. 03:25 UTC | Alla kundernas e-postadresser har nu tagits bort från flaggkonfigurationerna. Obs! Vissa e-postadresser från tredje part finns avsiktligt kvar i två flaggor på grund av bedrägligt bruk. |
Där vår process misslyckades
Det var tre saker som gick fel här, och vi vill tydligt peka ut var och en av dem. Vi kommer att diskutera ändringarna i nästa avsnitt.
1. Inga uppföljningsåtgärder vidtogs efter den ursprungliga rapporten. Bug bounty-rapporten från januari 2025 kunde ha lett till ett tekniskt arbetsuppdrag och en granskning av vilka data som fanns i flaggkonfigurationerna. Så blev det inte. Vi uppdaterar nu vår prioriteringsprocess för att förhindra att detta inträffar igen i framtiden.
2. HackerOne hanterade stängningen av ärendet som dubblett på ett felaktigt sätt. Rapporten från april 2026 dokumenterade väsentligt nya konsekvenser jämfört med rapporten från januari 2025. Den borde inte ha stängts som en dubblett av HackerOne. Vid en närmare granskning identifierade vi två andra fall där liknande rapporter stängts – ett den 6 september 2025 och ett den 1 januari 2026. Vi samarbetar med HackerOne för att åtgärda bristerna i deras triageprocesser. Vi kommer att införa en sekundär granskning av alla HackerOne-rapporter för att säkerställa att vi inte är beroende av tredjepartsprocesser framöver.
3. Vår e-posttjänst markerade forskarens anmälan som skräppost. Lördagen den 25 april skickade forskaren ett e-postmeddelande till både vår VD och security@clickup.com, samt skickade ett direktmeddelande till ClickUps X-konto.
Vi såg inte dessa e-postmeddelanden förrän efter det offentliga inlägget på X. De upptäcktes i samband med en intern utredning av skräppostmappar och filtrering av direktmeddelanden på X.
Vi uppdaterar våra processer för e-postfiltrering och granskning av skräppost för att säkerställa att säkerhetsrelaterad inkommande kommunikation inte avvisas utan att vi märker det.
Inget av detta ursäktar det grundläggande problemet: kunddata borde aldrig ha funnits i våra konfigurationer för funktionsflaggor från början.
Vad vi har gjort
Omedelbart (avslutat)
- Det exponerade API-tokenet för kunden har ogiltigförklarats.
- Vi har tagit bort alla kundernas e-postadresser från konfigurationerna för funktionsflaggor.
- Utfärdade en riktlinje för hela teknikavdelningen som förbjuder personuppgifter eller inloggningsuppgifter i flaggkonfigurationer.
- Genomfört en fullständig granskning av alla funktionsflaggor för personuppgifter, inloggningsuppgifter och känslig information.
Kortsiktigt (pågår)
- Vi har uppdaterat reglerna för e-postfiltrering för att säkerställa att security@clickup.com visar all inkommande säkerhetskommunikation, och lagt till ett steg i processen för att (på ett säkert sätt) granska skräppostmeddelanden.
- Granskning av arbetsflödena för prioritering av buggbounty-rapporter med HackerOne för att förhindra att giltiga rapporter stängs av misstag.
- Utbildning av granskare av funktionsflaggor i vad som räknas som godkänt innehåll.
Långsiktigt
- Automatisk genomsökning av alla konfigurationer för funktionsflaggor efter mönster som kan utgöra personuppgifter (e-postadresser, token, API-nycklar) vid varje ändring av en flagga, med automatisk blockering.
- En automatiserad process och verktyg för att granska alla beslut om prioritering på HackerOne.
- Inför en proxy eller en teknisk åtgärd för att separera frontend-flaggor och backend-flaggor.
Några ord om forskaren
När ClickUp hade tagit kontakt med den forskare som avslöjade detta, som går under namnet impulsive / @weezerOSINT, agerade de ansvarsfullt och lämnade ut all begärd information.
Forskaren, som använder sig av pseudonymen impulsive / @weezerOSINT, rapporterade via de rätta kanalerna (HackerOne, därefter direkt via e-post till security@clickup.com och vår VD) och visade sig vara konstruktiv när vi tog kontakt. Våra interna processer lyckades inte upptäcka rapporten och eskaleringarna i tid.
Efter att ha samarbetat med forskaren fick ClickUp följande meddelande den 28 april kl. 01:47 UTC: ”Tack [ClickUp], jag uppskattar verkligen hur snabbt ni har agerat i det här ärendet. Det är inte något jag ser ofta, och det gör verkligen skillnad.”
ClickUp belönar forskaren med en buggbounty för upptäckten. Vi uppmuntrar andra forskare att delta i vårt buggbounty-program, rapportera på ett ansvarsfullt sätt via vårt program för rapportering av sårbarheter eller direkt via e-post till security@clickup.com.
Sammanfattning
De uppgifter som läckte ut i samband med denna incident begränsade sig till 893 e-postadresser – inget innehåll i arbetsytan, inga lösenord och inga faktureringsuppgifter för någon kund påverkades, med undantag för den enda kund som nämns ovan – vi samarbetar direkt med denne för att säkerställa att ingen har fått obehörig tillgång till nyckeln.
Vi ber våra kunder om ursäkt för det som har hänt och kommer att göra allt som står i vår makt för att se till att något liknande inte inträffar igen.
Vi kommer att uppdatera detta inlägg om ny information framkommer. Om du har frågor, kontakta security@clickup.com.