Trigger.dev-läckan: rotera hemligheter utan driftstopp

Vad som har hänt

Trigger.dev publicerade den 1 november 2026 en säkerhetsrapport om att en angripare hade fått obehörig åtkomst till miljövariabler hos berörda organisationer. Trigger.dev uppger att angreppssättet har blockerats och att berörda kontoägare har fått instruktioner via mejl.

Rapporten är kort. Den anger inte vilka typer av variabler som lästes, när åtkomsten började eller om de exponerade uppgifterna användes. Det betyder att du behöver skilja mellan vad som är bekräftat och vad du måste utreda i din egen miljö.

En miljövariabel är ett namn med ett tillhörande värde som din kod kan läsa utan att värdet ligger direkt i källkoden. Det kan vara vanlig konfiguration, exempelvis vilken region som används, men också hemligheter som databaslösenord, API-nycklar och signeringsnycklar.

Om en angripare kan läsa en hemlig miljövariabel bör du behandla värdet som komprometterat. Det gäller även om du inte hittar bevis för missbruk. En kopierad nyckel kan sparas och användas senare, utanför Trigger.dev och utan att dina vanliga applikationsloggar visar hela förloppet.

Att du inte har fått ett mejl är samtidigt inte en teknisk bekräftelse på att allt är säkert. Kontrollera vilken adress som är registrerad som kontoägare, skräppostmappen och Trigger.dev-projektens organisationstillhörighet. Be Trigger.dev bekräfta berörda projekt, miljöer, variabelnamn och möjliga tidpunkter utan att skicka själva hemligheterna till supporten.

Avgör vad som kan ha läckt

Börja med en inventering innan du ändrar något. Annars riskerar du att tappa bort vilka värden som faktiskt fanns i Trigger.dev och var samma värden fortfarande används.

Gå igenom varje Trigger.dev-miljö, inklusive produktion, staging, utveckling och aktiva preview-miljöer. Notera variabelns namn, vilken tjänst som har utfärdat värdet, vilka system som använder det och var originalet förvaltas. Spara aldrig själva värdet i incidentdokumentet.

Var särskilt uppmärksam på variabler som ger åtkomst till:

• databaser och anslutningspooler
• Stripe eller andra betaltjänster
• Supabase med backendbehörighet
• e-postleverantörer
• fil- och objektlagring
• AI-tjänster och externa API:er
• webhook-signering
• autentisering och tokensignering
• Vercel, GitHub och andra distributionssystem
• övervakningstjänster som även kan innehålla känsliga loggar

Namn som DATABASE_URL, STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, SUPABASE_SERVICE_ROLE_KEY, RESEND_API_KEY och SENTRY_AUTH_TOKEN är tydliga kandidater. Egna namn som INTERNAL_API_KEY eller ADMIN_TOKEN kräver att du läser koden för att förstå behörigheten.

Alla miljövariabler är inte hemliga. En publicerbar Stripe-nyckel eller en Supabase-nyckel avsedd för klienten kan ligga i webbläsaren. Variabler med prefix som NEXT_PUBLIC_ och VITE_ byggs ofta in i klientkoden och ska därför aldrig betraktas som hemliga.

Det betyder inte att publika nycklar kan ignoreras. En publik Supabase-nyckel förutsätter exempelvis att databasens åtkomstregler begränsar vad en vanlig eller anonym användare får göra. Kontrollera därför Row Level Security och tillhörande policies, men prioritera rotation av nycklar med serverbehörighet.

Kontrollera även synkningar. Trigger.dev kan hämta miljövariabler från exempelvis Vercel. Samma hemlighet kan därför finnas i flera kontrollpaneler, lokala filer, CI-flöden och driftsatta versioner. Bestäm vilken plats som är källa till sanningen innan du börjar rotera, och pausa automatiska konfigurationsändringar om de riskerar att skriva tillbaka ett gammalt värde.

Rotera utan att skapa ett avbrott

Rotation innebär att du skapar en ny hemlighet, flyttar alla legitima användare till den och därefter spärrar den gamla. Ordningen är viktig. Om du spärrar först slutar beroende funktioner att fungera. Om du väntar för länge efter bytet lämnar du angriparens åtkomst öppen.

Den normala arbetsgången är:

• Skapa en ny nyckel hos tjänsten som utfärdar den, utan att ännu återkalla den gamla.
• Lägg den nya nyckeln i den plats som ska vara källa till sanningen.
• Uppdatera Trigger.dev och övriga system som använder samma credential.
• Starta om, driftsätt eller på annat sätt ladda om de processer som behöver läsa det nya värdet.
• Verifiera att riktiga anrop använder den nya nyckeln.
• Återkalla den gamla nyckeln hos utfärdaren.
• Kontrollera fel, köer, schemalagda jobb och externa anrop efter återkallelsen.

För Vercel gäller att en ändrad miljövariabel normalt behöver ingå i en ny driftsättning för att påverka den körande versionen. Utgå inte från att ett värde som syns i kontrollpanelen redan används i produktion. Trigger.dev, serverprocesser och externa workers kan ha andra regler för när värden läses in. Testa varje körmiljö i stället för att anta att synkningen har lyckats.

Stripe-nycklar bör hanteras utifrån deras funktion. En hemlig API-nyckel kan ge bred åtkomst, medan en begränsad nyckel kan ha rättigheter för ett visst arbetsflöde. Skapa helst en separat begränsad nyckel för Trigger.dev-jobben och ge den bara de rättigheter som koden behöver. Webhook-hemligheten är en annan credential än API-nyckeln och måste roteras separat om den fanns i Trigger.dev.

För Supabase ska du skilja på en publicerbar klientnyckel, en hemlig backendnyckel, databasens anslutningsuppgifter och nycklar som används för att signera tokens. De har olika konsekvenser och kan inte bytas som om de vore samma sak. En backendnyckel kan normalt ersättas parallellt, medan byte av äldre delade signeringshemligheter kan påverka sessioner och flera delar av systemet samtidigt.

Databasuppgifter kräver extra omsorg. Uppdatera både direkta anslutningssträngar och anslutningar via pooler. Kontrollera migrationer, administrationsverktyg, lokala produktionsskript och schemalagda jobb. När alla legitima processer använder det nya lösenordet kan du återkalla det gamla och vid behov avsluta gamla databasanslutningar.

Om du ser pågående missbruk ska du inte hålla den gamla nyckeln aktiv för att undvika avbrott. Återkalla den direkt, stoppa riskfyllda jobb och återställ tjänsten kontrollerat. Ett kort driftproblem är då mindre allvarligt än fortsatt åtkomst till betalningar, kunddata eller administrativ funktionalitet.

Kontrollera om nycklarna har använts

Rotation stoppar framtida användning men berättar inte vad som redan har hänt. Du behöver därför granska loggar hos både Trigger.dev och tjänsten bakom varje credential.

I Trigger.dev bör du leta efter:

• körningar som du inte känner igen
• oväntade payloads, taggar eller manuella anrop
• jobb som körts vid ovanliga tidpunkter
• förändringar av projekt, miljövariabler eller driftsättningar
• nya åtkomsttokens eller ändrade teambehörigheter
• ovanliga fel, omkörningar och externa nätverksanrop

Loggarna hos credentialens utfärdare är ofta viktigare. Ett stulet databaslösenord kan användas direkt mot databasen och en Stripe-nyckel direkt mot Stripes API utan att trafiken passerar Trigger.dev.

För Stripe kan du granska API-loggar och ändringar av exempelvis återbetalningar, betalningar, webhook-endpoints och kontoinställningar. För Supabase kan du kontrollera databas-, autentiserings- och API-loggar samt förändringar i användare, policies och schema. För Vercel och GitHub bör du kontrollera aktivitet kring driftsättningar, miljövariabler, integrationer och åtkomsttokens.

Sök inte bara efter lyckade anrop. Nekade försök kan visa att någon testat nyckeln eller försökt förstå dess behörighet. Jämför med kända körningar från din applikation och notera vilka källor, tider och operationer som avviker.

Bevara underlaget innan loggar försvinner eller skrivs över. Exportera relevanta händelser, men undvik att kopiera hemligheter, fullständiga personuppgifter eller känsliga payloads till ett oskyddat dokument. Dokumentera vad du kontrollerade, vilka beslut du tog och när den gamla nyckeln slutade vara giltig.

Checklista för att avsluta incidenten

Använd checklistan som ett gemensamt arbetsdokument för teknik, produkt och den som ansvarar för berörda leverantörskonton.

• Bekräfta om organisationen eller något projekt omfattas av Trigger.devs besked.
• Inventera alla miljöer och variabelnamn utan att kopiera värdena.
• Märk upp vilka variabler som är publika, hemliga eller har administrativ behörighet.
• Kartlägg var varje hemlighet används och vilken plats som är källa till sanningen.
• Säkra relevanta loggar och händelser innan konfigurationen ändras.
• Rotera privilegierade nycklar och databasuppgifter med parallell giltighet där det är säkert.
• Uppdatera Trigger.dev, Vercel, lokala miljöer och andra konsumenter.
• Driftsätt eller starta om processer som annars behåller gamla värden.
• Verifiera kritiska flöden som betalning, inloggning, e-post och bakgrundsjobb.
• Återkalla gamla credentials och kontrollera att de inte längre accepteras.
• Granska leverantörernas loggar efter obehöriga eller avvikande anrop.
• Begränsa breda nycklar och separera credentials mellan tjänster och miljöer.
• Dokumentera händelsen och gör rotationen reproducerbar inför nästa incident.

När produkten fungerar igen bör du också minska konsekvensen av framtida läckor. Använd separata nycklar per miljö och komponent, välj begränsade behörigheter, undvik delade administratörsnycklar och se till att någon kan genomföra en rotation utan att först leta igenom hela kodbasen.

Om du vill prioritera säkerhetsarbetet utifrån det som påverkar intäkterna kan du börja med flödet för betalande kunder.

---

Källa: Trigger.dev blog