Trigger.dev ha confirmado acceso no autorizado a las variables de entorno de un subconjunto de organizaciones. La empresa afirma haber bloqueado el exploit utilizado y enviado instrucciones a todos los propietarios de cuentas afectados. El comunicado original está fechado el 1 de noviembre de 2026.
La página oficial de estado marca el incidente como resuelto y registra el aviso a las 22:50 UTC del 1 de noviembre, las 23:50 en Madrid. Publicamos esta información el 2 de noviembre; la fecha del aviso no determina cuándo comenzó el acceso indebido.
Qué se conoce y qué sigue sin detallarse
Las dos comunicaciones consultadas confirman el acceso a variables de entorno, pero no enumeran las organizaciones afectadas ni explican la causa técnica. Tampoco ofrecen una relación pública de credenciales concretas utilizadas posteriormente por el atacante. La empresa indica que aportará más detalles.
Que el exploit esté bloqueado describe una medida sobre la vía de entrada. No permite concluir que un secreto ya leído haya dejado de ser válido en otro servicio. Tampoco sería correcto afirmar que todas las organizaciones de Trigger.dev quedaron expuestas.
Por qué importa para los equipos que ejecutan agentes
Las variables de entorno pueden guardar configuración y credenciales. El impacto depende de qué contenían y de los permisos de cada valor. Por eso, la pregunta operativa no termina en comprobar que una tarea vuelve a ejecutarse: hay que delimitar qué acceso podía conceder la configuración expuesta.
Ejemplo hipotético, no ejecutado por Puntoes: un equipo recibe el aviso y encuentra que una de sus tareas utilizaba una clave de un proveedor de modelos. Su responsable puede identificar esa clave sin copiarla en una incidencia, sustituirla en los consumidores autorizados y revocar la anterior, coordinando el cambio para no interrumpir el servicio. Revisar el uso registrado por el proveedor ayuda a investigar posibles accesos; el simple cambio de clave no demuestra qué ocurrió antes.
Esta secuencia es un criterio general de respuesta, no una reproducción del incidente ni una instrucción atribuida al correo privado de Trigger.dev. Puntoes no ha accedido a esos mensajes. Los propietarios afectados deben consultar las indicaciones que recibieron y los cambios del aviso oficial.
Qué comprobar ahora
El primer paso es localizar el aviso dirigido al propietario y contrastar su alcance con los proyectos y credenciales del equipo. Si hay dudas sobre la afectación, el comunicado ofrece el canal de contacto de Trigger.dev; la ausencia de un correo en una bandeja concreta no demuestra por sí sola que la organización esté fuera del alcance.
La noticia sobre caducidad y renovación de claves de API aporta un antecedente útil: limitar la duración de una credencial y sustituir una que puede haberse filtrado son decisiones diferentes. Mientras Trigger.dev amplía su informe, conviene conservar evidencias y distinguir exposición confirmada, uso indebido demostrado y cuestiones todavía abiertas.