Vazamento na Trigger.dev: como girar seus segredos

No domingo, 1º de novembro de 2026, a Trigger.dev, plataforma usada para rodar tarefas em segundo plano, filas e agentes de IA escritos em TypeScript, publicou um aviso de segurança curto e direto: um atacante conseguiu acesso não autorizado às variáveis de ambiente de um grupo de organizações clientes. Para quem usa a plataforma, isso quer dizer que chaves de API, URLs de banco de dados e tokens guardados ali podem estar nas mãos de outra pessoa.

Este texto separa o que a empresa confirmou do que ainda não se sabe, e mostra o que fazer agora se você usa a Trigger.dev, ou qualquer outra plataforma que guarda seus segredos para rodar seu código.

O que a Trigger.dev confirmou

O comunicado oficial está no blog da Trigger.dev, assinado por Eric Allam, CTO da empresa, com o título "Security Disclosure: Sunday November 1st". O mesmo texto aparece como incidente na página de status oficial. Os fatos confirmados são estes:

• Houve um incidente de segurança na Trigger.dev.
• A falha explorada foi bloqueada. A empresa diz que já fechou o caminho usado no ataque.
• Só uma parte das organizações foi exposta ("a subset of organizations"). A empresa não disse quantas.
• O que vazou foram as variáveis de ambiente dessas organizações.
• Os donos das contas afetadas receberam e-mail com os passos para reduzir o estrago.
• Na página de status, o serviço afetado aparece como API, e a empresa promete publicar mais detalhes depois.

Isso é tudo o que está nas fontes oficiais. O comunicado não diz qual falha foi usada, por quanto tempo o atacante teve acesso, quantas organizações foram afetadas nem se os valores marcados como secretos no painel também foram lidos. Qualquer texto que afirme essas coisas hoje está chutando. A forma certa de agir é tratar o caso pelo pior cenário possível dentro do que foi confirmado.

Linha do tempo

• 1º/11/2026 (domingo): data do comunicado no blog da Trigger.dev, classificado como "Incident report".
• 1º/11/2026, 22h50 UTC (19h50 no horário de Brasília): o incidente é registrado na página de status, já como "Resolved", com o serviço API listado como afetado.
• Mesmo dia: a empresa diz que já mandou e-mail para todos os donos de contas afetadas.
• Até a madrugada de 3/11/2026 (horário de Brasília): nenhum relatório técnico detalhado tinha sido publicado. A promessa é atualizar pela página de status.

"Resolved" quer dizer que a porta foi fechada, não que o problema acabou para você. Se uma chave sua foi lida antes do bloqueio, ela continua funcionando até você trocar. Fechar a falha não cancela credenciais que já foram copiadas.

Por que variáveis de ambiente valem tanto

Uma plataforma de tarefas em segundo plano precisa dos seus segredos para funcionar. A própria documentação de variáveis de ambiente da Trigger.dev explica que, como ela faz o deploy das suas tarefas e escala tudo sozinha, toda variável que o código usa precisa ficar acessível para ela. Na prática, o painel de um projeto costuma reunir tudo o que essas tarefas tocam: a URL do banco de produção, a chave do provedor de e-mail, a chave secreta de pagamentos, tokens de modelos de IA, webhooks do Slack e credenciais de nuvem.

É o mesmo padrão que vimos no vazamento de chaves de API na Northflank: quando a plataforma de terceiro é atingida, o atacante não precisa invadir cada cliente. Ele pega as chaves de todos de uma vez. E quanto mais poderosa for cada chave, maior o estrago.

O que fazer agora

A ordem importa. Primeiro você descobre o que estava exposto, depois troca as chaves mais perigosas, depois procura sinais de uso e, por fim, diminui o que fica guardado na plataforma.

1. Confira o e-mail e a página de status

Procure na caixa de entrada (e no spam) do dono da organização um e-mail da Trigger.dev enviado a partir de 1º/11. Se ele chegou, siga os passos dele primeiro, porque são específicos para a sua conta. Se não chegou, isso indica que sua organização não está entre as expostas, mas não prova nada: vale ter o e-mail certo cadastrado como dono e assinar as atualizações da página de status. Se ficar com dúvida, a empresa diz que os clientes podem entrar em contato pelo canal oficial dela.

2. Faça a lista do que estava lá

Você não consegue trocar o que não sabe que existe. Abra a página Environment Variables de cada projeto e de cada ambiente (dev, staging, prod e preview, se usar). Para cruzar com o código, este comando lista os nomes de variáveis lidas via process.env num projeto TypeScript ou JavaScript (testado com acesso por ponto, por colchetes e com desestruturação):

{ grep -rhoE 'process\.env(\.[A-Z0-9_]+|\[.[A-Z0-9_]+.\])' src/
  grep -rhoE '\{[^}]*\} *= *process\.env' src/
} | grep -oE '[A-Z][A-Z0-9_]{2,}' | sort -u

A saída é só a lista de nomes, sem valores. Junte essa lista com o que aparece no painel: o que estiver no painel e não no código é variável esquecida, e deve ser trocada e depois apagada.

3. Troque as chaves, começando pelas mais perigosas

Não dá para trocar tudo ao mesmo tempo sem derrubar o sistema. Siga esta ordem:

1. Credenciais de nuvem e de banco de dados: chaves de acesso da AWS, GCP ou Azure, URLs de banco com usuário e senha. Elas dão acesso direto aos dados.
2. Pagamentos e dinheiro: chaves secretas de gateways de pagamento e segredos de assinatura de webhooks.
3. Tokens com poder de escrita: GitHub, provedores de e-mail transacional (dá para mandar phishing em seu nome), Slack e Discord.
4. Chaves de IA e APIs pagas: o risco aqui é a conta no fim do mês e o uso indevido da sua cota.
5. O resto: chaves de analytics, feature flags e serviços internos.

Para cada chave, o caminho seguro é: crie a nova no provedor, atualize na Trigger.dev (e em qualquer outro lugar onde ela é usada), confirme que as execuções seguintes funcionam e só então revogue a antiga. Trocar o valor no painel sem revogar a chave antiga no provedor não adianta nada, porque quem copiou a antiga continua usando. A documentação lembra que as variáveis são buscadas e injetadas antes de cada execução começar, então apagar uma variável sem colocar outra no lugar faz as execuções que dependem dela falharem.

No banco de dados, troque a senha do usuário (ou crie um usuário novo e apague o antigo) em vez de só mexer no endereço. Se a mesma senha for usada em outros lugares, troque lá também.

4. Procure sinais de uso nos logs

Trocar a chave impede o próximo acesso. Ver os logs mostra se já houve algum. Use o intervalo que vai de algumas semanas antes de 1º/11 até a hora em que você trocou cada chave, porque a empresa ainda não informou quando o acesso começou:

• Nuvem: no CloudTrail, Cloud Audit Logs ou Activity Log, procure chamadas feitas com a chave antiga vindas de IPs ou regiões que você não usa, criação de usuários, chaves novas ou máquinas novas.
• Banco: conexões de origens estranhas e consultas grandes de exportação fora do padrão.
• Provedores de API: quase todos mostram uso por chave. Um pico de consumo de IA ou de e-mails enviados é um bom sinal de alerta.
• GitHub: o log de auditoria da organização e os eventos de tokens.

Se aparecer uso estranho, o problema passou de "chave exposta" para "conta comprometida": aí é preciso revisar o que foi criado com aquela credencial e derrubar sessões abertas. No caso do ataque à GMO no Japão, mostramos por que só trocar a senha não derruba quem já está dentro.

5. Diminua o que fica guardado em plataformas de terceiros

Esse é o passo que reduz o próximo vazamento, seja na Trigger.dev ou em qualquer outra plataforma:

• Uma chave por serviço e por ambiente. Não use a mesma chave de produção no staging nem em dois fornecedores diferentes. Se uma vazar, você troca só uma.
• Permissão mínima. Se a tarefa só lê um bucket, a credencial só pode ler aquele bucket. Se só manda e-mail, a chave do provedor de e-mail não pode gerenciar domínios. Banco com usuário próprio para as tarefas, sem permissão de dono.
• Marque como Secret. Na Trigger.dev, um valor marcado como Secret fica escondido no painel e não pode ser visto depois de criado. A documentação avisa que isso só pode ser feito na criação e não tem volta. Isso protege contra quem só olha o painel, mas a plataforma continua precisando do valor para rodar suas tarefas, então não substitui os outros itens.
• Centralize num cofre de segredos. A documentação descreve a sincronização nativa com o Infisical e a extensão syncEnvVars para puxar segredos de outros serviços na hora do deploy. Com o segredo num lugar só, a próxima troca vira um passo único, em vez de caçar a chave em cinco painéis.
• Prefira credenciais que expiram. Sempre que o provedor permitir, use tokens com prazo curto ou chaves com data de validade, e não chaves que valem para sempre.
• Apague o que não é usado. Variável esquecida não traz nenhum benefício e ainda pode vazar.

Se você roda contêineres, a mesma regra vale fora da plataforma: segredo não vai dentro da imagem. Explicamos como fazer isso em segredo fora da imagem.

O que ainda falta saber

A Trigger.dev prometeu mais detalhes, e eles vão mudar a avaliação do caso. As perguntas que importam são: qual falha foi usada, desde quando o atacante tinha acesso, se os valores marcados como Secret também foram lidos e se houve acesso a outros dados além das variáveis. Até lá, o mais sensato é agir como se toda variável da organização afetada tivesse sido copiada. Vamos atualizar este texto quando a página de status trouxer novidades.

Para fechar

Um vazamento numa plataforma de terceiros não depende de nenhum erro seu, mas o tamanho do estrago depende de como você guardou os segredos. Se sua organização recebeu o e-mail, troque e revogue as chaves hoje, na ordem de risco, e confira os logs da nuvem, do banco e dos provedores de API. Se não recebeu, aproveite o susto para fazer a lista do que está guardado, apagar o que sobra e diminuir a permissão do que fica. Esse trabalho também vale para a próxima plataforma que for atacada.