Ta reda på var den app som dina användare besöker faktiskt körs. Skriv ned adress, driftleverantör och ansvarig person. Använd uppgifterna för att välja åtgärd nedan. Om du saknar besked om driftplatsen är nästa steg att få det bekräftat, innan du markerar säkerhetsärendet som klart.
Vad säkerhetsmeddelandet gäller
Den 30 september 2026 publicerade Lovable och TanStack information om CVE-2026-102989 i TanStack Start. Lovable uppger att upptäckten gjordes den 14 september. Det är alltså olika datum för upptäckt och offentlig information. Enligt Lovables säkerhetsmeddelande berörs vissa serverfunktioner; alla Lovable-projekt är inte påverkade. Berörda projektägare ska få mejl.
Sårbarheten kan låta oönskad JavaScript-kod köras i en besökares webbläsare med besökarens åtkomst till appen. TanStack beskriver felet och uppdateringskravet. Som appägare behöver du därför en bekräftad åtgärd för rätt app, snarare än en egen bedömning av attacktekniken.
1. Dokumentera driftplatsen för den publicerade appen
Utgå från adressen som kunder eller kollegor använder. Fråga den som byggde eller publicerade appen: ”Körs den här versionen hos Lovable eller hos en annan driftleverantör?” Be om leverantörens namn och vilken person som kan publicera en uppdatering. Spara svaret tillsammans med appens adress. En egen domän eller ett projekt i Lovable är inte ett tillräckligt svar på frågan i ditt åtgärdsprotokoll.
Har du flera publicerade versioner, till exempel en kundapp och ett internt testprojekt, skriv en rad för varje version. Låt varje rad ha sitt eget besked. Exempel: ”Kundapp: driftplats bekräftad av Anna, åtgärd beställd; testapp: driftplats ännu okänd.” Det gör det tydligt var du väntar på information och hindrar att ett besked om testprojektet används som kvitto för kundappen.
2. Om appen driftas hos Lovable
Lovable uppger att brandväggsskydd redan finns för appar som driftas där. Berörda projekt uppdateras automatiskt vid nästa ändring. Vill du åtgärda tidigare kan du använda projektets Security-sida utan kreditkostnad för denna incidentfix, enligt samma meddelande. Uppgiften ska inte användas som ett generellt löfte om kostnaden för andra säkerhetsfixar.
Välj nu om du ska använda Security eller göra nästa planerade ändring. Anteckna valet och vem som följer upp det. Skriv till exempel ”Security-åtgärd utförd, inväntar bekräftelse för publicerad version”, om det är vad du faktiskt vet. Be den ansvariga bekräfta att uppdateringen omfattar den app som användarna når. Att ha valt en väg framåt och att ha fått slutligt besked är två olika statusar i ditt protokoll.
Brandväggen är ett skydd runt den körande appen; paketuppdateringen ändrar programvaran. TanStack framhåller att skydd vid driftmiljöns kant inte ersätter rättningen. Använd därför en separat anteckning för leverantörens skydd och en för kodens uppdateringsstatus. Undvik den oprecisa raden ”säkerheten klar”, som lämnar båda frågorna obesvarade.
3. Om appen driftas någon annanstans
Lovables driftsskydd omfattar enligt meddelandet inte denna publicering. Lämna båda källorna till tekniskt ansvarig och be om paketuppdatering, ny byggning och ny publicering. TanStack anger @tanstack/start-server-core 1.169.39 som första rättade version. En lokal uppdatering rättar inte en redan driftsatt app.
Din beställning kan vara: ”Kontrollera om vår publicerade app berörs av CVE-2026-102989. Om den gör det, uppdatera enligt TanStacks säkerhetsmeddelande, bygg om och publicera. Återkom med appadress, verifierad paketversion och tidpunkt för publiceringen.” Be personen kontrollera hela beroendekedjan mot källan; du behöver inte själv välja paket eller tolka versionsintervall.
Om svaret blir ”vi har uppdaterat”, följ upp med ”Är den nya byggningen publicerad på den här adressen?” Om appen bedöms vara opåverkad, be om grunden för den bedömningen och vem som gjort den. Spara svaret. Då har du ett ansvarigt besked även när slutsatsen är att just denna publicering inte behöver ändras.
4. Kontrollera huvudflöden och spara ett avslut
Efter åtgärden rekommenderar vi att du provar appens viktigaste vardagsflöden. Logga in med ett testkonto, öppna en sida som kräver inloggning och genomför en central uppgift med testdata, exempelvis att skapa och läsa tillbaka en bokning. Skriv ned adressen, tiden, vad du gjorde och resultatet. Ett fungerande flöde ger ett kvitto på funktion; låt beskedet om paketversion och publicering vara kvittot på incidentåtgärden.
Har appen privata poster kan du återanvända de befintliga åtkomstproven i guiden om behörigheter i Lovable. Gör inga angreppsförsök för att kontrollera detta säkerhetsmeddelande. Fördela i stället ansvaret: tekniskt ansvarig bekräftar rättningen, du dokumenterar att huvudflödena fortfarande fungerar. Läs säkerhetsguiden för hur du organiserar det löpande ansvaret efter incidenten.
En rad per publicerad app med driftplats, ansvarig, besked om påverkan, vald åtgärd och bekräftelse för den publicerade versionen. Lägg till dina funktionsprov och eventuella öppna frågor. Om du fortfarande väntar på ett svar, skriv vem du väntar på och när du följer upp. Markera avslut först när det finns underlag för just den status du skriver.