El 27 de abril de 2026, un investigador de seguridad reveló públicamente que la configuración de los conmutadores de función del lado del cliente de ClickUp dejaba al descubierto información de identificación personal. En concreto, 893 direcciones de correo electrónico de clientes estaban integradas en las reglas de segmentación de los conmutadores de función, junto con un conmutador que hacía referencia de forma incorrecta al token de API de un cliente, utilizado durante una respuesta a una incidencia para limitar el tráfico procedente de ese entorno de trabajo.
Deberíamos habernos dado cuenta antes. No lo hicimos, y os debemos una explicación clara de lo que ocurrió, por qué, qué medidas hemos terminado de tomar al respecto y cómo vamos a mejorar en el futuro.
¿Te afecta esto?
La filtración se limitó a 893 direcciones de correo electrónico de clientes utilizadas en las reglas de segmentación de conmutadores de función para controlar qué usuarios ven funciones específicas durante los lanzamientos.
Si has recibido una comunicación directa antes del 29 de abril o en esa misma fecha (en curso), tu dirección de correo electrónico figuraba entre las incluidas en una configuración de conmutadores de función. Si no has recibido ninguna notificación por nuestra parte, tu correo electrónico no figuraba en la lista de direcciones de correo electrónico.
- No se ha visto comprometido ningún contenido del entorno de trabajo (tareas, documentos, archivos o datos de proyectos) de ningún cliente, salvo una posible excepción que se describe a continuación.
- No se filtraron contraseñas, datos de facturación ni credenciales de cuenta.
- Ningún sistema de autenticación se vio comprometido.
El problema técnico
ClickUp utiliza Split.io (ahora parte de Harness) para la gestión de conmutadores de función. Al igual que la mayoría de los SDK de conmutadores de función del lado del navegador, Split.io requiere una clave de SDK del lado del cliente integrada en el paquete JavaScript de la aplicación. Esta clave es pública de forma intencionada y es la forma en que el SDK evalúa los conmutadores para el usuario actual en el navegador. Se trata de un comportamiento estándar y documentado en Split.io, LaunchDarkly y plataformas similares, y no constituye una vulnerabilidad.
La clave no es el problema. Lo importante es lo que nuestros ingenieros incluyen en las configuraciones de los indicadores.
Esto es lo que ocurrió desde el punto de vista arquitectónico: las plataformas de conmutadores de función permiten a los ingenieros dirigir el lanzamiento de funciones a usuarios específicos. Los equipos de ingeniería de ClickUp habían utilizado direcciones de correo electrónico directamente en las reglas de segmentación de indicadores. Un ejemplo es habilitar una función para un conjunto específico de probadores beta. El punto final splitChanges del SDK de Split.io, que se puede consultar públicamente, devuelve el conjunto completo de definiciones de indicadores, incluidas estas reglas de segmentación. Esto significa que cualquier persona con la clave del lado del cliente (que, de nuevo, se encuentra intencionadamente en nuestro código frontend) podría recuperar esas definiciones de indicadores y extraer las direcciones de correo electrónico incrustadas en ellas.
Los ingenieros trataron las configuraciones de los conmutadores de función como herramientas internas, cuando la arquitectura del SDK permite, por diseño, consultarlas públicamente. Esto provocó que las direcciones de correo electrónico se acumularan en un lugar en el que nunca deberían haber estado. Las actualizaciones de los conmutadores de función requieren una revisión por pares de +1, al igual que el código. Este paso de revisión no detectó el problema.
La única excepción: un indicador configurado para limitar el ancho de banda de un solo cliente
Un ingeniero de guardia que respondía a un caso de uso indebido de la API incluyó el token de API de un cliente en la configuración de un indicador de limitación de velocidad para regular el tráfico, lo que hizo que fuera potencialmente legible a través del punto final del SDK. Esto nunca debería haber ocurrido: las credenciales no deben figurar en las configuraciones de los indicadores. Desactivamos el token de inmediato y, hasta el momento, nuestro análisis de los registros no muestra indicios de accesos maliciosos más allá de la propia investigación del investigador. No se pudo acceder a ningún otro token de cliente ni a datos del entorno de trabajo, y estamos trabajando directamente con este cliente.
Lo que se reveló y lo que no
| Reclamación | Nuestra conclusión |
| Clave del SDK integrada en el paquete | Es correcto y forma parte del diseño. Así es como funcionan los SDK de conmutadores de función del lado del navegador. No se trata de una vulnerabilidad en sí misma. |
| 893 direcciones de correo electrónico de clientes en las reglas de segmentación por indicadores | Información correcta en el momento de la elaboración de informes. Todas las direcciones de correo electrónico de terceros se han eliminado a las 03:25 UTC del 28 de abril. |
| Token de la API de clientes en producción en la configuración de flags | Confirmado. Añadido el 7 de octubre de 2025. Invalidado el 27 de abril de 2026 a las 12:05 UTC. |
| Acceso de escritura a Split.io | Es correcto y forma parte del diseño. Los puntos finales de telemetría del SDK del navegador (evENTOS/bulk, testImpressions) admiten operaciones de escritura como parte del comportamiento estándar del SDK. No se trata de una configuración incorrecta de ClickUp. |
| «Sin medidas correctoras durante 15 meses» | Información errónea; las fechas son correctas. El informe original de recompensa por errores del 17 de enero de 2025 sobre la clave del SDK no dio lugar a una tarea de ingeniería, ya que la clave por sí sola no constituye la vulnerabilidad. Las direcciones de correo electrónico y las configuraciones de los indicadores eran el problema real y no se incluyeron en este informe original. Las configuraciones de los indicadores no se revelaron a HackerOne hasta el 8 de abril de 2026 y ClickUp no tuvo conocimiento de ellas hasta el 27 de abril de 2026. |
Cronograma
Nos comprometemos a ser totalmente transparentes en cuanto a los fallos que se han producido en nuestros procesos, incluidos los de nuestro proveedor externo de programas de recompensa por errores y los de nuestras propias herramientas de comunicación interna.
| Fecha | Evento |
| 17 de enero de 2025 | Un investigador ha notificado la filtración de claves del SDK de Split.io a nuestro programa de recompensas por errores en BugCrowd. Teniendo en cuenta el contenido del informe, BugCrowd y ClickUp lo clasificaron correctamente como «informativo». |
| 3 de junio de 2025 | ClickUp traslada su programa de recompensas por errores a HackerOne. Todos los informes anteriores se han migrado correctamente, incluido el problema mencionado anteriormente. |
| 8 de abril de 2026 | El investigador conocido como «impulsive» ha publicado un nuevo y detallado informe en HackerOne en el que documenta un impacto mayor: 893 direcciones de correo electrónico de clientes en las reglas de detección, el token de la API de clientes en tiempo real y otros datos operativos. |
| 10 de abril de 2026 | Un analista de triaje de HackerOne cerró erróneamente el informe por considerarlo un duplicado del informe de enero de 2025, sin tener en cuenta que el nuevo informe documentaba un impacto sustancialmente diferente y de mayor alcance. Tras un análisis más detallado, identificamos otras dos instancias de informes similares que se cerraron erróneamente: una el 6 de septiembre de 2025 y otra el 1 de enero de 2026. |
| 21 de abril de 2026 | El investigador rebate el cierre aportando más detalles a HackerOne. |
| 25 de abril de 2026 | El investigador intensifica sus acciones: envía un correo electrónico al director general de ClickUp y a security@clickup.com a través de HackerOne, y envía mensajes directos a ClickUp en X, fijando el 2 de mayo como fecha límite para la divulgación pública. Estos correos electrónicos dirigidos al director general de ClickUp y a security@ quedan retenidos por los filtros de spam y no llegan a sus destinatarios. Los mensajes directos de X enviados a ClickUp fueron filtrados automáticamente y no se leyeron. |
| 27 de abril de 2026, ~10:42 UTC | El investigador lo hace público en X. |
| 27 de abril de 2026, 11:06 UTC | ClickUp recibe la notificación. Se declara la incidencia. Se pone en marcha el proceso de respuesta ante incidencias y se inicia el procedimiento para rotar el token de API del cliente. |
| 27 de abril de 2026, 12:53-14:12 UTC | Primeras tareas de limpieza de banderas de división en los equipos de ingeniería. |
| 27 de abril de 2026, aproximadamente a las 17:00 UTC | La auditoría totalmente automatizada de los 4.809 conmutadores de función ha sido completada. |
| 27 de abril de 2026, 23:13 UTC | Los ingenieros de ClickUp y Harness (Split) revisan los detalles técnicos. |
| 28 de abril de 2026, 03:25 UTC | Se ha confirmado que todas las direcciones de correo electrónico de los clientes se han eliminado de las configuraciones de las marcas. Nota: algunas direcciones de correo electrónico de terceros se mantienen intencionadamente en dos marcas; esto se debe a un uso fraudulento. |
Dónde falló nuestro proceso
Aquí han salido mal tres cosas, y queremos señalarlas claramente. En la siguiente sección hablaremos de los cambios.
1. No se llevó a cabo ningún seguimiento del informe original. El informe del programa de recompensas por errores de enero de 2025 podría haber dado lugar a una tarea de ingeniería y a una revisión de los datos que contenían las configuraciones de los indicadores. No fue así. Estamos actualizando nuestro proceso de clasificación para evitar que esto vuelva a suceder en el futuro.
2. HackerOne gestionó incorrectamente el cierre por duplicado. El informe de abril de 2026 documentaba un impacto sustancialmente nuevo en comparación con el informe de enero de 2025. HackerOne no debería haberlo cerrado por duplicado. Tras un análisis más detallado, identificamos otras dos instancias de informes similares que fueron cerrados: una el 6 de septiembre de 2025 y otra el 1 de enero de 2026. Estamos trabajando con HackerOne para subsanar las deficiencias en sus procesos de clasificación. Incluiremos una revisión secundaria de todos los informes de HackerOne para asegurarnos de que, en el futuro, no dependamos de procesos de terceros.
3. Nuestro servicio de correo electrónico marcó la notificación del investigador como spam. El sábado 25 de abril, el investigador envió un correo electrónico tanto a nuestro director general como a security@clickup.com, y envió un mensaje directo a la cuenta de ClickUp en X.
No vimos esos correos electrónicos hasta después de la publicación en X. Se encontraron tras una investigación interna de las carpetas de spam y del filtrado de mensajes directos de X.
Estamos actualizando nuestros procesos de filtrado de correo electrónico y revisión de spam para garantizar que las comunicaciones entrantes relacionadas con la seguridad no se descarten sin previo aviso.
Ninguna de estas razones justifica el problema fundamental: los datos de los clientes nunca deberían haber estado en nuestras configuraciones de conmutadores de función, para empezar.
Lo que hemos terminado
Inmediato (completada)
- Se ha invalidado el token de la API de cliente expuesto.
- Se han eliminado todas las direcciones de correo electrónico de los clientes de las configuraciones de los conmutadores de función.
- Se ha emitido una directiva para todo el departamento de ingeniería que prohíbe incluir información de identificación personal (PII) o credenciales en las configuraciones de los indicadores.
- Se ha completado una auditoría exhaustiva de todos los conmutadores de función relacionados con la información de identificación personal, las credenciales y los datos confidenciales.
A corto plazo (en curso)
- Se han actualizado las reglas de filtrado de correo electrónico para garantizar que security@ClickUp muestre todas las comunicaciones de seguridad entrantes, añadiendo un paso al proceso para examinar (de forma segura) los mensajes de spam.
- Revisión de los flujos de trabajo de clasificación de incidencias con HackerOne para evitar que se cierren por error los informes válidos.
- Formación de los revisores de conmutadores de función sobre qué contenidos están aprobados.
A largo plazo
- Análisis automático de todas las configuraciones de conmutadores de función en busca de patrones de información de identificación personal (direcciones de correo electrónico, tokens, claves de API) cada vez que se modifica un conmutador de función, con aplicación de medidas de bloqueo.
- Un proceso de automatización y herramientas para revisar todas las decisiones de clasificación de HackerOne.
- Implementa un proxy o una medida técnica para separar los indicadores del front-end de los del back-end.
Una nota sobre el investigador
Una vez que ClickUp se puso en contacto con el investigador que reveló esta información, conocido por el alias impulsive / @weezerOSINT, actuó de forma responsable y facilitó toda la información solicitada.
El investigador, que opera bajo el alias impulsive / @weezerOSINT, informó a través de los canales adecuados (HackerOne, y posteriormente por correo electrónico directo a seguridad@clickup.com y a nuestro director general) y colaboró de forma constructiva cuando nos pusimos en contacto con él. Nuestros procesos internos no lograron detectar a tiempo su informe y las escaladas correspondientes.
Tras el trabajo con el investigador, ClickUp recibió el siguiente mensaje el 28 de abril a la 1:47 UTC: «Gracias, [ClickUp], te agradezco mucho la rapidez con la que has actuado. No es algo que vea a menudo y marca la diferencia».
ClickUp recompensará al investigador con una prima por el descubrimiento de este error. Animamos a otros investigadores a que se unan a nuestro programa de recompensas por errores, a que informen de forma responsable a través de nuestro Programa de divulgación de vulnerabilidades o directamente por correo electrónico a security@clickup.com.
Resumen
Los datos expuestos en esta incidencia se limitaron a 893 direcciones de correo electrónico; no se vieron afectados contenidos del entorno de trabajo, contraseñas ni datos de facturación de ningún cliente, con la excepción de un único cliente mencionado anteriormente, con el que estamos colaborando directamente para verificar que no se haya accedido indebidamente a su clave.
A nuestros clientes, les pedimos mil disculpas por lo ocurrido y haremos todo lo que esté en nuestra mano para garantizar que algo así no vuelva a suceder.
Actualizaremos esta publicación si surge nueva información. Si tienes alguna pregunta, ponte en contacto con seguridad@ClickUp.com.