Para: desenvolvedores e equipes que executam tarefas ou jobs na Trigger.dev e guardam em seus ambientes chaves de API, dados de conexão de bancos de dados ou credenciais de nuvem. Este artigo se baseia nas publicações do blog e na página de status da Trigger.dev, e não trata de técnicas de ataque.
Acompanhamento publicado: este artigo é atualizado conforme a organização publicar mais informações
- Quem é afetado
desenvolvedores e equipes que executam tarefas ou jobs na Trigger.dev e guardam em seus ambientes chaves de API, dados de conexão de bancos de dados ou credenciais de nuvem.
- Confirmado até agoraVer a tabela ↓
- Proporção de clientes afetados
- Chaves de API root
- Variáveis de ambiente
Mais 1
- Listas e metadados de execuções, implantações e agendamentos
- Ainda não confirmado
- O vetor de ataque (a empresa o reserva para proteger a investigação e os clientes)
- Quando o acesso não autorizado começou e por quanto tempo
- O número real de clientes afetados
Mais 1
- Se as informações obtidas foram de fato usadas indevidamente
- O que fazer agoraVer os passos ↓
- Verifique se há um aviso: tanto o e-mail quanto o banner do painel
- Se foi afetado, regenere suas chaves de API da Trigger.dev
- Se foi afetado, troque as credenciais do ambiente
Mais 3
- Confira uso, logs e cobrança nos emissores
- Faça nova implantação com os novos valores e confirme que suas tarefas rodam
- Defina limites de gastos e divida as chaves em chaves menores
- Onde verificar (fonte)Todas as fontes ↓
- Trigger.dev, blog, relatório do incidente (6 de novembro de 2026)
- Última verificação
- Em 7 de novembro de 2026 (JST)
Próximos avisos e o que verificamos
A empresa publicou um relatório em 6 de novembro. Ele cobre o bloqueio do atacante, a proporção de clientes afetados, o que foi obtido e o que os clientes devem fazer. Diz que compartilhará o vetor de ataque quando puder fazê-lo de forma responsável. Na nossa checagem de 7 de novembro de 2026 (JST), nenhuma outra atualização havia sido publicada.
O que os usuários da Trigger.dev devem fazer hoje
Verifique se há um aviso: tanto o e-mail quanto o banner do painel
A empresa diz que os clientes afetados receberam e-mail em 1º de novembro (por volta de 21:36 UTC) e em 2 de novembro (20:27 UTC), e veem um banner de notificação no painel. Confira primeiro se o proprietário da sua organização recebeu o e-mail, inclusive na pasta de spam, e se o painel mostra um banner.
A empresa diz que clientes que não receberam aviso de impacto não foram afetados. Se você não tiver certeza, ela pede que escreva para help@trigger.dev a partir do e-mail da sua conta, e diz que prioriza o suporte a este incidente.
Se foi afetado, regenere suas chaves de API da Trigger.dev
A empresa diz que o atacante obteve chaves de API root e que revogou as chaves potencialmente afetadas dos ambientes afetados. As instruções para regenerá-las foram enviadas por e-mail aos clientes afetados. Se um CI ou aplicativo ainda usar uma chave antiga, substitua-a pela nova.
A empresa liberou restrições de IP para chaves de API com escopo limitado e suporte a OIDC. Use-os ao reemitir as chaves, se combinarem com a sua configuração.
Se foi afetado, troque as credenciais do ambiente
Isso inclui senhas de bancos de dados, chaves de API de terceiros, tokens de acesso e itens semelhantes do ambiente afetado. Faça nesta ordem: revogue a credencial antiga no serviço emissor (provedor de IA, nuvem, banco de dados, pagamentos, e-mail), crie uma nova, configure-a na Trigger.dev e faça uma nova implantação. Editar ou apagar uma variável na Trigger.dev não impede uma cópia que alguém já tenha.
A empresa diz que as variáveis de ambiente são armazenadas criptografadas em repouso e descriptografadas na hora de executar as tarefas. Mas uma chave root dá acesso total às configurações de um ambiente, incluindo suas variáveis de ambiente, então o mais seguro é tratar as de um ambiente afetado como tomadas.
Confira uso, logs e cobrança nos emissores
Nas fontes que lemos, a empresa não informa quando o acesso não autorizado começou; por isso, como regra prática deste site, olhe para trás pelo menos até o fim de outubro e mantenha a janela ampla. Em cada serviço emissor, abra o uso, os logs de acesso, a lista de chaves e a cobrança em busca de requisições que você não reconhece, modelos ou regiões incomuns e um aumento repentino de custo.
Em bancos de dados, procure também conexões de origens desconhecidas e jobs que você normalmente não executa. Se encontrar uso suspeito, avise o emissor e troque também os demais segredos daquele ambiente.
Faça nova implantação com os novos valores e confirme que suas tarefas rodam
Depois de configurar os novos valores, faça nova implantação e confirme que as tarefas em execução e agendadas funcionam com eles. Como as chaves antigas agora estão revogadas, uma variável esquecida faz uma tarefa falhar. Use as falhas para descobrir qual variável ainda está desatualizada.
Defina limites de gastos e divida as chaves em chaves menores
Em provedores de IA e nuvens, defina um teto de orçamento mensal e um alerta. Dê a cada chave uma única finalidade e as permissões mais restritas, e use chaves separadas por aplicativo e por ambiente. Uma chave menor limita o custo de um vazamento. Para o básico de manter as chaves fora do código e dos logs, veja o que realmente é perigoso no .env e nas chaves de API.
O que aconteceu (segundo os comunicados da Trigger.dev)
O texto a seguir se baseia no relatório da empresa de 6 de novembro, na sua publicação do blog de 1º de novembro e na entrada da página de status. O relatório de 6 de novembro foi publicado como acompanhamento da primeira divulgação.
1º de novembro
A empresa toma conhecimento do incidente. Alertas da infraestrutura sinalizam atividade anômala; ela a julga maliciosa, bloqueia o atacante e mitiga o vetor de ataque. Primeira divulgação no blog.1º de novembro, por volta de 21:36 UTC
Primeiro e-mail aos clientes afetados.1º de novembro, 22:50 UTC
É criada a entrada da página de status com o mesmo título.2 de novembro, 20:27 UTC
Segundo e-mail aos clientes afetados.6 de novembro, 12:27 UTC
A entrada da página de status é marcada como "Resolved" e aponta para o relatório de 6 de novembro.6 de novembro
A empresa publica um relatório mais completo: 0,66% dos clientes afetados, chaves de API root obtidas, o que foi retornado e o que os clientes devem fazer.7 de novembro
Este site confere de novo. Nenhuma outra atualização foi publicada.
O que a empresa diz
0,66% dos clientes. Chaves de API root obtidas, variáveis de ambiente acessadas, dados de execuções, implantações e agendamentos retornados
Não informado
O vetor de ataque (reservado), a data de início, o número real de clientes, se houve uso indevido
Se foi afetado: regenere as chaves de API e depois revogue e substitua as credenciais do ambiente nos emissores.
- Impacto
- 0,66% de todos os clientes. O atacante obteve chaves de API root de alguns ambientes de clientes e acessou suas variáveis de ambiente
- O que foi retornado
- Em alguns ambientes, listas de execuções, implantações e agendamentos recentes: IDs, nomes de tarefas, chaves de idempotência de execuções, status das execuções, tags, metadados e erros de implantações, IDs externos de agendamentos e metadados de execuções
- Não encontrado
- Nenhum indício de que outros dados de clientes, outros serviços, seus próprios bancos de dados de produção ou contas do painel de clientes tenham sido acessados (empresa)
- Resposta da empresa
- Bloqueou o atacante e mitigou o vetor, trocou credenciais internas por precaução, revisou logs, notificou os clientes afetados, revogou as chaves de API potencialmente afetadas, aplicou restrições automáticas de contas baseadas em risco, contratou especialistas em resposta a incidentes e avisou as autoridades
- Não divulgado
- O vetor de ataque (para proteger a investigação e os clientes), a data de início, o número real de clientes, se algo foi usado indevidamente
O que se sabe e o que não se sabe
Situação em 7 de novembro de 2026 (JST). Os itens marcados como "não informado" não constam do relatório da empresa como o lemos; não está confirmado que estejam seguros.
| Item | O que a empresa diz | Situação |
|---|---|---|
| Proporção de clientes afetados | 0,66% de todos os clientes | Confirmado (empresa) |
| Chaves de API root | Obtidas pelo atacante para alguns ambientes de clientes | Vazamento confirmado (empresa) |
| Variáveis de ambiente | O atacante obteve acesso não autorizado | Afetado (empresa) |
| Listas e metadados de execuções, implantações e agendamentos | Retornados em alguns ambientes | Vazamento confirmado (empresa) |
| Outros dados de clientes, outros serviços, seus próprios bancos de dados de produção, contas do painel | Nenhum indício de que tenham sido acessados | Não confirmado (empresa) |
| Segredos de assinatura de webhooks | Não expostos | Não incluídos (empresa) |
| Implantações auto-hospedadas | Não afetadas | Não incluídos (empresa) |
| Clientes sem aviso | Não afetados | Declaração da empresa |
| O vetor de ataque | Reservado para proteger a investigação e os clientes; será compartilhado quando for possível de forma responsável | Em investigação (reservado pela empresa) |
| Quando o acesso começou e por quanto tempo | Não informado no relatório como o lemos | Não informado |
| Número real de clientes afetados | Apenas a proporção (0,66%) | Não informado |
| Uso indevido das informações obtidas | Não informado | Não informado |
Como ler isto: ainda não se sabe se as credenciais guardadas nas variáveis foram usadas
A empresa separa o que foi obtido do que não tem indício de ter sido acessado. Ela não diz se as credenciais guardadas nas variáveis de ambiente foram de fato usadas. Se você foi afetado, não espere a confirmação de que não foram; revogue-as primeiro no emissor.
A que o acesso a variáveis de ambiente pode levar
De modo geral, segredos acessados em variáveis de ambiente podem ser usados indevidamente como segue. Isso não significa que tudo tenha acontecido aqui.
- Chaves de API de serviços de IA: outra pessoa envia requisições na sua conta e você recebe a cobrança, ou a chave é revendida
- Senhas e strings de conexão de bancos de dados: ler ou alterar os dados do seu aplicativo, incluindo registros dos seus próprios usuários
- Chaves de nuvem e de pagamentos: criar recursos ou fazer chamadas que geram custo
- Chaves de assinatura: aceitar requisições forjadas ou forjar sessões
Os metadados de execuções e implantações retornados aqui (nomes de tarefas, tags, erros) não são um segredo em si, mas dão pistas sobre quais serviços você usa e como. Isso pode servir para elaborar mensagens direcionadas e convincentes.
Uma plataforma de tarefas em segundo plano guarda, por natureza, as credenciais de muitos serviços externos em um só lugar. Se as variáveis de uma plataforma forem vistas, chaves de vários serviços podem ficar em risco ao mesmo tempo. Para outros casos envolvendo variáveis de ambiente e segredos, veja Northflank, Zeabur e Railway. São casos separados, e não se confirmou que algum deles compartilhe causa com este.
Para operadores: lições do que a empresa divulgou
Estes pontos vêm dos fatos que a empresa publicou. Não são um julgamento adicional sobre a Trigger.dev.
- Uma chave quase root alcança as configurações de todo o ambiente. A empresa diz que obter chaves de API root deu acesso às variáveis de ambiente. Divida as chaves da plataforma por finalidade e use, onde puder, as opções de restrição que a empresa liberou, como restrições de IP e OIDC.
- Os avisos chegam por e-mail e no painel. Faça do endereço do proprietário uma caixa compartilhada que continue funcionando quando uma pessoa sair, mantenha-a fora da filtragem de spam e confira o banner do painel com regularidade.
- Mantenha fáceis de substituir os segredos que você entrega a uma plataforma. Decida por emissor como revogar e reemitir, e divida as chaves por ambiente e finalidade, para poder agir no dia em que um aviso chegar.
- Dê aos segredos guardados em variáveis as permissões mais restritas. Se as variáveis de uma plataforma forem vistas, o dano depende do que cada chave pode fazer.
Fontes (registros públicos)
Os fatos deste artigo se baseiam nas informações públicas abaixo. Não especulamos sobre o vetor de ataque nem sobre a causa, que a empresa não divulgou.
- Trigger.dev, blog, relatório do incidente (6 de novembro de 2026) — trigger.dev/blog/security-incident-report-nov-2026
- Trigger.dev, blog, "Security Disclosure: Sunday November 1st" (1º de novembro de 2026) — trigger.dev/blog/security-incident-nov-2026
- Trigger.dev, página de status, "Security Disclosure: Sunday November 1st" (criada em 1º de novembro de 2026, 22:50 UTC; marcada como resolvida em 6 de novembro, 12:27 UTC, com um link para o relatório de 6 de novembro) — status.trigger.dev/incident/1110434
Histórico de atualizações
2026-11-07: Acrescentado o relatório da empresa de 6 de novembro: 0,66% dos clientes afetados, chaves de API root e variáveis de ambiente obtidas, dados de execuções, implantações e agendamentos retornados, vetor de ataque reservado. Os passos agora se concentram em verificar se há um aviso (e-mail e banner do painel), regenerar as chaves de API e trocar as credenciais do ambiente; acrescentado que os segredos de assinatura de webhooks não foram expostos e que as implantações auto-hospedadas não foram afetadas. 2026-11-05: Primeira versão. Baseada no blog e na página de status da Trigger.dev em 5 de novembro de 2026.
Leia a seguir
- Outros incidentes envolvendo variáveis de ambiente e segredos: Incidente de segurança da Northflank / Variáveis de ambiente da Railway possivelmente expostas / Incidente de segurança da Zeabur
- Um caso mais recente de plataforma para desenvolvedores: acesso não autorizado aos sistemas de produção da Chainstack / violação do OpenCode Console
- Manter as chaves seguras: o que realmente é perigoso no .env e nas chaves de API / chaves de API roubadas e bloqueio de conta
- Outros incidentes de 2026: Vazamentos de dados e ciberataques de 2026