Em 27 de abril de 2026, um pesquisador de segurança divulgou publicamente que a configuração dos sinalizadores de recursos do lado do cliente do ClickUp expunha informações de identificação pessoal. Especificamente, 893 endereços de e-mail de clientes estavam incorporados nas regras de segmentação dos sinalizadores de recursos, juntamente com um sinalizador que fazia referência indevida ao token de API de um cliente, utilizado durante uma resposta a incidente para limitar a taxa de tráfego proveniente daquele espaço de trabalho.
Devíamos ter percebido isso antes. Não o fizemos, e devemos a vocês uma explicação clara sobre o que aconteceu, por quê, o que já fizemos a respeito e como vamos melhorar daqui para frente.
Você está sendo afetado?
A exposição limitou-se a 893 endereços de e-mail de clientes utilizados nas regras de segmentação de sinalizadores de recursos para controlar quais usuários têm acesso a recursos específicos durante as implementações.
Se você recebeu uma comunicação direta até 29 de abril (incluindo esse dia) (em andamento), seu endereço de e-mail estava entre os incluídos em uma configuração de sinalizador de recurso. Se você não recebeu nenhuma comunicação nossa, seu e-mail não constava na lista de endereços de e-mail.
- Nenhum conteúdo do espaço de trabalho (tarefas, documentos, arquivos ou dados de projetos) foi exposto para nenhum cliente — com uma possível exceção descrita abaixo.
- Nenhuma senha, dado de cobrança ou credencial de conta foi exposta.
- Nenhum sistema de autenticação foi comprometido.
A questão técnica
O ClickUp utiliza o Split.io (agora parte do Harness) para o gerenciamento de sinalizadores de recursos. Como a maioria dos SDKs de sinalizadores de recursos do lado do navegador, o Split.io requer uma chave de SDK do lado do cliente incorporada no pacote JavaScript do aplicativo. Essa chave é intencionalmente pública e é assim que o SDK avalia os sinalizadores para o usuário atual no navegador. Esse é um comportamento padrão e documentado no Split.io, no LaunchDarkly e em plataformas semelhantes, e não constitui uma vulnerabilidade.
O importante não é a questão em si, mas sim o que nossos engenheiros incluem nas configurações de sinalizadores.
Eis o que aconteceu do ponto de vista arquitetônico: as plataformas de sinalizadores de recursos permitem que os engenheiros direcionem o lançamento de recursos a usuários específicos. As equipes de engenharia do ClickUp usavam endereços de e-mail diretamente nas regras de segmentação de sinalizadores. Um exemplo é habilitar um recurso para um conjunto específico de testadores beta. O endpoint splitChanges do SDK do Split.io, que pode ser consultado publicamente, retorna o conjunto completo de definições de sinalizadores, incluindo essas regras de segmentação. Isso significa que qualquer pessoa com a chave do lado do cliente (que, novamente, está intencionalmente em nosso código front-end) poderia recuperar essas definições de sinalizadores e extrair os endereços de e-mail incorporados nelas.
Os engenheiros trataram as configurações de sinalizadores como ferramentas internas, embora a arquitetura do SDK as torne publicamente consultáveis por padrão. Isso permitiu que os endereços de e-mail se acumulassem em um local onde nunca deveriam ter estado. As atualizações dos sinalizadores de recursos exigem uma revisão por pares +1, semelhante à do código. Essa etapa de revisão não detectou o problema.
A única exceção – Um sinalizador configurado para limitar a taxa de um único cliente
Um engenheiro de plantão que estava lidando com um caso de uso indevido da API incluiu o token de API de um cliente na configuração de um sinalizador de limitação de taxa para restringir o tráfego, tornando-o potencialmente acessível por meio do endpoint do SDK. Isso nunca deveria ter acontecido: credenciais não devem constar em configurações de sinalizadores. Desativamos o token imediatamente e, até o momento, nossa análise dos logs não mostra sinais de acesso malicioso além da própria investigação do pesquisador. Nenhum outro token de cliente ou dados do espaço de trabalho ficaram acessíveis, e estamos trabalhando diretamente com esse cliente.
O que foi revelado e o que não foi
| Reivindicação | Nossa conclusão |
| Chave do SDK codificada no pacote | É correto e faz parte do design. É assim que funcionam os SDKs de sinalizadores de recursos no lado do navegador. Não se trata, por si só, de uma vulnerabilidade. |
| 893 endereços de e-mail de clientes nas regras de segmentação por bandeira | Informações corretas no momento da publicação. Todos os endereços de e-mail de terceiros foram removidos até 28 de abril, às 03h25 UTC. |
| Token da API do cliente em produção na configuração de sinalizadores | Confirmado. Adicionado em 7 de outubro de 2025. Invalidado em 27 de abril de 2026, às 12h05 UTC. |
| Acesso de gravação ao Split.io | Está correto e é intencional. Os pontos de extremidade de telemetria do SDK do navegador (events/bulk, testImpressions) aceitam gravações como parte do comportamento padrão do SDK. Isso não é uma configuração incorreta do ClickUp. |
| “Sem medidas corretivas por 15 meses” | Informação incorreta; as datas estão corretas. O relatório original de recompensa por bug de 17 de janeiro de 2025 sobre a chave do SDK não resultou em uma tarefa de engenharia, pois a chave por si só não constitui a vulnerabilidade. Os endereços de e-mail e as configurações de sinalizadores eram o problema real e não foram incluídos neste relatório original. As configurações de sinalizadores não foram divulgadas à HackerOne até 8 de abril de 2026 e não eram do conhecimento da ClickUp até 27 de abril de 2026. |
Cronologia
Estamos empenhados em ser totalmente transparentes quanto aos pontos em que nossos processos falharam, incluindo falhas por parte do nosso provedor terceirizado de recompensas por bugs e de nossas próprias ferramentas de comunicação interna.
| Data | Evento |
| 17 de janeiro de 2025 | Um pesquisador relatou a divulgação da chave do SDK do Split.io ao nosso programa de recompensa por bugs no BugCrowd. Dado o conteúdo do relatório, este foi corretamente classificado como “informativo” pelo BugCrowd e pelo ClickUp. |
| 03/06/2025 | A ClickUp transferiu o programa de recompensa por bugs para o HackerOne. Todos os relatórios anteriores foram migrados com sucesso, incluindo o problema mencionado acima. |
| 08/04/2026 | O pesquisador conhecido como impulsive publicou um novo relatório detalhado no HackerOne, documentando um impacto mais amplo: 893 endereços de e-mail de clientes nas regras de sinalização, o token da API de clientes ativo e outros dados operacionais. |
| 10 de abril de 2026 | Um analista de triagem da HackerOne encerra indevidamente o relatório como uma duplicata do relatório de janeiro de 2025, sem perceber que o novo relatório documenta um impacto substancialmente diferente e mais abrangente. Após uma análise mais aprofundada, identificamos outros dois casos de relatórios semelhantes que foram encerrados indevidamente – um em 6 de setembro de 2025 e outro em 1º de janeiro de 2026 |
| 21 de abril de 2026 | O pesquisador contesta o encerramento do caso, fornecendo mais detalhes à HackerOne. |
| 25 de abril de 2026 | O pesquisador intensifica suas ações: por meio do HackerOne, envia um e-mail ao CEO da ClickUp e à conta security@clickup.com; além disso, envia mensagens diretas à ClickUp no X, estabelecendo o dia 2 de maio como prazo final para a divulgação pública. Esses e-mails enviados ao CEO da ClickUp e à conta security@ são bloqueados pelos filtros de spam e não chegam aos destinatários pretendidos. As mensagens diretas enviadas à ClickUp no X foram filtradas automaticamente e não foram lidas. |
| 27/04/2026 ~10:42 UTC | O pesquisador divulga publicamente no X. |
| 27/04/2026 11:06 UTC | O ClickUp é notificado. Incidente declarado. O processo de resposta a incidentes é acionado e o procedimento para atualizar o token da API do cliente é iniciado. |
| 27/04/2026 12:53–14:12 UTC | Limpeza inicial das bandeiras de divisão entre as equipes de engenharia. |
| 27 de abril de 2026 ~17h00 UTC | A auditoria totalmente automatizada de todos os 4.809 sinalizadores de recurso foi concluída. |
| 27 de abril de 2026, 23h13 UTC | Os engenheiros da ClickUp e da Harness (Split) analisam os detalhes técnicos. |
| 28 de abril de 2026, 03:25 UTC | Todos os endereços de e-mail de clientes confirmados foram removidos das configurações de sinalização. Observação: alguns endereços de e-mail de terceiros permanecem intencionalmente em duas sinalizações; isso está relacionado ao uso fraudulento. |
Onde nosso processo falhou
Houve três problemas aqui, e queremos identificá-los claramente. Discutiremos as alterações na seção seguinte.
1. Não houve acompanhamento do relatório original. O relatório do programa de recompensa por bugs de janeiro de 2025 poderia ter dado origem a uma tarefa de engenharia e a uma análise dos dados contidos nas configurações de sinalizadores. Isso não aconteceu. Estamos atualizando nosso processo de triagem para evitar que isso se repita no futuro.
2. A HackerOne tratou indevidamente o encerramento por duplicidade. O relatório de abril de 2026 documentou um impacto substancialmente novo em comparação com o relatório de janeiro de 2025. Ele não deveria ter sido encerrado como duplicado pela HackerOne. Após uma análise mais aprofundada, identificamos outros dois casos de relatórios semelhantes que foram encerrados – um em 6 de setembro de 2025 e outro em 1º de janeiro de 2026. Estamos trabalhando com a HackerOne para corrigir falhas em seus processos de triagem. Incluiremos uma revisão secundária de todos os relatórios da HackerOne para garantir que não dependamos de processos de terceiros daqui para frente.
3. Nosso serviço de e-mail classificou a mensagem do pesquisador como spam. No sábado, 25 de abril, o pesquisador enviou um e-mail tanto para o nosso CEO quanto para security@clickup.com e enviou uma mensagem direta para a conta do ClickUp no X.
Só vimos esses e-mails depois da publicação no X. Eles foram encontrados após uma investigação interna nas pastas de spam e na filtragem de mensagens diretas do X.
Estamos atualizando nossos processos de filtragem de e-mails e análise de spam para garantir que as comunicações recebidas relacionadas à segurança não sejam descartadas sem aviso prévio.
Nenhuma dessas razões justifica o problema principal: os dados dos clientes nunca deveriam ter sido incluídos nas configurações dos nossos sinalizadores de recurso, para começar.
O que fizemos
Imediato (concluído)
- O token da API do cliente exposto foi invalidado.
- Removemos todos os endereços de e-mail dos clientes das configurações dos sinalizadores de recurso.
- Foi emitida uma diretriz para toda a área de engenharia proibindo o uso de informações de identificação pessoal (PII) ou credenciais nas configurações de sinalizadores.
- Concluímos uma auditoria completa de todos os sinalizadores de recursos relacionados a informações de identificação pessoal (PII), credenciais e dados confidenciais.
Curto prazo (em andamento)
- Atualizamos as regras de filtragem de e-mails para garantir que security@clickup.com exiba todas as comunicações de segurança recebidas, adicionando uma etapa ao processo para examinar (com segurança) as mensagens de spam.
- Revisão dos fluxos de trabalho de triagem do programa de recompensa por bugs com o HackerOne para evitar que relatórios válidos sejam encerrados indevidamente.
- Treinamento dos revisores de feature flags sobre quais conteúdos são aprovados.
A longo prazo
- Verificação automatizada de todas as configurações de sinalizadores de recursos em busca de padrões de informações de identificação pessoal (endereços de e-mail, tokens, chaves de API) a cada alteração de sinalizador, com aplicação de bloqueio.
- Um processo automatizado e ferramentas para revisar todas as decisões de triagem do HackerOne.
- Implemente um proxy ou uma medida técnica para separar os sinalizadores do front-end dos sinalizadores do back-end.
Uma nota sobre o pesquisador
Assim que a ClickUp entrou em contato com o pesquisador que divulgou essa informação, que atua sob o pseudônimo impulsive / @weezerOSINT, a empresa agiu de forma responsável e forneceu todas as informações solicitadas.
O pesquisador, que atua sob o pseudônimo impulsive / @weezerOSINT, fez a denúncia pelos canais adequados (HackerOne, seguido de um e-mail direto para security@clickup.com e para o nosso CEO) e colaborou de forma construtiva quando entramos em contato. Nossos processos internos não conseguiram identificar a denúncia e as escalações a tempo.
Após trabalhar com o pesquisador, a ClickUp recebeu a seguinte mensagem em 28 de abril, às 1h47 UTC: “Obrigado, [ClickUp], agradeço muito a rapidez com que agiram neste caso. Não é algo que vejo com frequência e isso faz toda a diferença.”
A ClickUp está recompensando o pesquisador com uma recompensa por bug pelas descobertas feitas. Outros pesquisadores são incentivados a participar do nosso programa de recompensas por bug, a relatar vulnerabilidades de forma responsável por meio do nosso Programa de Divulgação de Vulnerabilidades ou diretamente por e-mail para security@clickup.com.
Resumo
Os dados expostos neste incidente limitaram-se a 893 endereços de e-mail – nenhum conteúdo do espaço de trabalho, senha ou dado de cobrança de nenhum cliente foi afetado, com exceção de um único cliente mencionado acima – estamos trabalhando diretamente com ele para verificar se a chave não foi acessada indevidamente.
Aos nossos clientes, pedimos sinceras desculpas pelo ocorrido e faremos tudo o que estiver ao nosso alcance para garantir que algo assim não volte a acontecer.
Atualizaremos esta publicação caso surjam novas informações. Se tiver alguma dúvida, entre em contato com security@clickup.com.