Kritisk Next.js-uppdatering utan att slå ut produktionen

Den 22 september 2026 publicerade Next.js en säkerhetsuppdatering utanför det vanliga releaseschemat. Uppdateringen åtgärdar ett kritiskt problem som under vissa förutsättningar kan leda till att obehörig kod körs på servern.

Det viktiga är inte bara att uppdatera paketet. Du behöver också kontrollera vilken version appen faktiskt kör, om den använder den berörda bildfunktionen och om det nya bygget fungerar med inloggning, betalningar och andra centrala flöden.

Vad som har ändrats

Enligt Next.js säkerhetsmeddelande från den 22 september 2026 berörs Next.js-versioner från 16.2.0 fram till, men inte inklusive, 16.3.6. Den korrigerade versionen för den aktiva LTS-grenen är 16.3.6.

Next.js har även publicerat 15.5.26 för appar som ligger kvar på underhållsgrenen 15.x. Den grenen uppges inte vara sårbar för just fjärrkörningen av kod, men uppdateringen innehåller relaterad säkerhetshärdning.

Problemet finns i Node.js-varianten av ImageResponse från next/og. Funktionen används ofta för att skapa dynamiska bilder, exempelvis förhandsbilder som visas när en sida delas i sociala medier. Bakom funktionen finns beroendet Satori, som omvandlar gränssnittskod till SVG.

Sårbarheten blir relevant när värden som en besökare kan påverka förs in i SVG-innehåll, attribut eller stilar. Felaktig hantering av sådana värden kan tillsammans med andra beroenden leda till att kod körs på servern. Edge-varianten av ImageResponse omfattas inte av samma problem.

Att din app inte har en tydlig bildsida i navigationen betyder inte att funktionen saknas. Den kan ligga i en route för Open Graph-bilder, i en mall från Lovable eller i kod som lagts till av ett paket.

Kontrollera om appen berörs

Börja i projektets rotmapp och kontrollera den installerade versionen. Om du använder npm kan du köra:

npm ls next

Titta även i package.json och projektets låsfil. Det är låsfilen, exempelvis package-lock.json eller pnpm-lock.yaml, som visar vilken version bygget faktiskt installerar. En ändrad versionsrad i package.json räcker inte om den uppdaterade låsfilen inte följer med till Git och driftsättningen.

Sök därefter i koden efter följande uttryck:

grep -R "ImageResponse\|next/og" app pages src

Sökningen kan ge fel om projektet saknar någon av mapparna, men resultat från befintliga mappar visas ändå. Du kan också använda sökfunktionen i GitHub, VS Code eller Lovable.

Granska träffarna och kontrollera om data från URL-parametrar, formulär, databasen eller användarprofiler förs in i SVG-element, attribut eller stilar. Namn, rubriker, profiltexter och bildadresser bör betraktas som användarpåverkade om de kan ändras utanför den betrodda koden.

Använd denna kontrollista:

• Bekräfta vilken Next.js-version som installeras från låsfilen
• Sök efter ImageResponse och next/og
• Kontrollera om berörda routes använder Node.js eller Edge
• Identifiera värden som besökare eller användare kan påverka
• Kontrollera om flera Next.js-appar finns i samma kodlager
• Kontrollera att produktionsbygget använder samma låsfil som du granskar

Även om du inte hittar ImageResponse bör en berörd 16.x-version uppdateras. Frånvaro av en kodträff är inte ett bra skäl att lämna ett känt säkerhetshål öppet, särskilt när genererad kod eller beroenden kan göra användningen mindre synlig.

Uppgradera rätt versionsgren

Om appen redan använder 16.x, uppdatera till 16.3.6:

npm install next@16.3.6

Om appen använder 15.x, installera härdningsversionen:

npm install next@15.5.26

Använder projektet pnpm, Yarn eller Bun ska du använda motsvarande kommando och låta samma pakethanterare uppdatera låsfilen. Blanda inte pakethanterare och redigera inte låsfilen för hand.

Ligger appen på en äldre huvudversion bör du inte installera 16.3.6 blint. En större versionsuppgradering kan kräva kodändringar. Säkerhetsmeddelandet anger ingen separat korrigerad version för äldre, osupportade grenar, så behandla det som ett planerat uppgraderingsarbete och verifiera ramverkets aktuella supportstatus.

Efter installationen ska du köra projektets vanliga bygge lokalt. Kontrollera också att Git visar ändringar i både paketfilen och låsfilen. Om bara package.json har ändrats kan produktionsmiljön fortfarande installera något annat än du tänkt.

Testa före driftsättning

Skapa en preview-driftsättning i Vercel eller motsvarande miljö. Använd samma miljövariabler och externa tjänster som normalt används för tester, men undvik riktiga betalningar och oavsiktliga utskick.

Gå igenom flöden som kan stoppa verksamheten om de går sönder:

• Registrering, inloggning och utloggning
• Återställning av lösenord och länkar för engångsinloggning
• Omdirigering efter OAuth-inloggning
• Skyddade sidor och middleware
• Hämtning och uppdatering av data i Supabase
• Stripe Checkout i testläge
• Betalningens returvägar för lyckat och avbrutet köp
• Stripe-webhooks och uppdatering av abonnemangsstatus
• Dynamiska Open Graph-bilder och andra ImageResponse-routes
• Centrala formulär, mejlutskick och bakgrundsjobb

Öppna även byggloggarna. Varningar om beroenden, förändrad runtime eller misslyckade routes kan vara tecken på att preview-miljön inte motsvarar produktionen.

Driftsätt därefter under en period när någon kan följa loggar och felrapportering. En tidigare deployment kan vara praktisk vid ett funktionsfel, men en återställning återinför också den äldre säkerhetsversionen. Målet bör därför vara att rätta framåt och få den uppdaterade versionen stabil.

Om en omedelbar uppgradering inte är möjlig bör du tillfälligt stoppa angriparkontrollerade värden från att nå SVG-innehåll, attribut eller stilar i Node.js-versionen av ImageResponse. Att stänga av den berörda bildrouten är säkrare än att försöka filtrera enstaka tecken utan full förståelse för SVG-tolkningen. Detta är en tillfällig begränsning, inte en ersättning för uppdateringen.

När appen är uppdaterad och de kritiska flödena fungerar kan nästa steg vara att kontrollera hur produkten är förberedd för betalande kunder.

Källa: Next.js blog