Két kritikus Next.js biztonsági frissítés egy hónap alatt: mit tanulhat belőle minden ügynökség?

A Next.js fejlesztőcsapata 2026. augusztus 25-én két kritikus sérülékenységet javított a népszerű webes keretrendszerben, szeptember 21-én pedig bejelentette, hogy egy külső, úgynevezett upstream függőségben talált újabb kritikus hiba miatt szeptember 22-én soron kívüli Next.js biztonsági frissítés érkezik a 16.3.6-os és a 15.5.26-os verzióval. Egy hónapon belül tehát kétszer kellett mindent félretéve frissíteni, ráadásul az augusztusi két hiba bejelentkezés nélküli távoli kódfuttatást tett lehetővé, ami a sérülékenységek legsúlyosabb kategóriája. Ha a céged weboldala, webshopja vagy ügyfélportálja Next.js-en fut (ma rengeteg modern, React-alapú oldal ilyen), akkor a frissítés már nem a fejlesztők belügye, hanem az üzletmenet folytonosságának alapfeltétele.

A következőkben 2026. szeptember 22-i állapot szerint végigvesszük, pontosan mi történt a két kiadásban, kiket érintenek a hibák, mit jelent a Next.js támogatási rendjében az Active LTS és a Maintenance LTS (és miért lesz kiemelt dátum 2026. október 21.), végül lépésről lépésre azt is, hogyan telepíthető egy sürgős javítás úgy, hogy közben ne boruljon fel az éles oldal. A végén összeszedtük azokat a tanulságokat is, amelyeket minden webes ügynökségnek be kellene építenie a működésébe, cégvezetőként pedig éppen ezekből tudod lemérni, hogy a fejlesztőd tényleg vigyáz-e az oldaladra, vagy csak reméli, hogy nem lesz baj.

Röviden

• A Next.js a Vercel által fejlesztett, React-alapú nyílt forráskódú webes keretrendszer, amelyben 2026. augusztus 25-én két kritikus, bejelentkezés nélkül kihasználható távoli kódfuttatási hibát javítottak a 16.3.3-as és a 15.5.24-es verzióval.
• Az augusztusi első hiba a beépített képoptimalizálást érintette AVIF-képeknél a sharp csomag által használt libheif könyvtáron keresztül, a második pedig azokat az alkalmazásokat, amelyek Windows-szerveren futnak és a Pages Routert és az App Routert egyszerre, Cache Components nélkül használják.
• A Next.js csapata 2026. szeptember 21-én jelentette be, hogy egy upstream függőség kritikus hibája miatt szeptember 22-én soron kívül kiadja a 16.3.6-os és a 15.5.26-os verziót, a részleteket tartalmazó GHSA-vcvr-r3jv-pc5j jelű biztonsági közlemény azonban szeptember 22-i ellenőrzésünkkor még nem volt nyilvános.
• A hivatalos támogatási szabályzat szerint a 16.x ág Active LTS, a 15.x ág pedig Maintenance LTS státuszú. Ez utóbbi csak 2026. október 21-ig kap kritikus javításokat, a 14.x és a régebbi verziók pedig már nem támogatottak.
• Mivel a Next.js 2026 júliusa óta nagyjából havonta előre bejelentett biztonsági kiadásokat ad ki, egy felelős ügynökségnek rögzített frissítési folyamatra van szüksége: verzióleltárra, tesztkörnyezetre, automatikus tesztekre, visszaállítási tervre és rendszeres ügyfélkommunikációra.
• Cégvezetőként akkor alhatsz nyugodtan, ha tudod, melyik Next.js-verzión fut az oldalad, írásban rögzítetted, hány órán belül telepítik a kritikus javításokat, valamint az oldal legkésőbb október 21-ig átkerül a 16-os főverzióra.

Mi az a Next.js és miért érdekel ez egy cégvezetőt?

A Next.js a Vercel által fejlesztett nyílt forráskódú webes keretrendszer, amely a React könyvtárra épülve szerveroldali megjelenítést, útválasztást és képoptimalizálást ad a weboldalaknak. Cégvezetőként azért érdekel, mert ha az oldalad ezen fut, egy kritikus Next.js-hiba közvetlenül a bevételedet, az ügyféladataidat és a keresőben elért helyezésedet veszélyezteti.

A keretrendszer olyan előre megírt szoftveres váz, amelyre a fejlesztők a konkrét weboldalt építik, nagyjából úgy, ahogy egy családi ház falai egy előre gyártott vasbeton szerkezetre kerülnek. A React a Meta által fejlesztett felületépítő könyvtár, amely a gombokat, űrlapokat és oldalelemeket kezeli a böngészőben, a Next.js pedig ehhez adja hozzá a szerveroldali részt: a HTML-t már a szerveren összerakja, így az oldal gyorsan betölt és a Google is könnyen feldolgozza. Emiatt lett az elmúlt években az egyik kedvenc eszköze a modern webes ügynökségeknek, a headless webshopoknak (ahol a kirakat és a háttérrendszer külön fut) és az ügyfélportáloknak.

Van viszont egy lényeges különbség a WordPresshez képest, amelyet sok cégvezető nem ismer. A WordPress tartalomkezelő rendszer, amelynek adminfelületén ott a frissítés gomb, a kisebb biztonsági javításokat pedig alapbeállítás szerint magától telepíti. Egy Next.js-oldal ezzel szemben egyedi szoftver, amelyet a fejlesztő a keretrendszerből épített fel, így nincs olyan felület, ahol a tulajdonos egy kattintással frissíthetne. A javításhoz valakinek módosítania kell a projekt függőségeit, újra kell fordítania (buildelnie) az alkalmazást, majd újra ki kell telepítenie a szerverre. Ha ezt senki nem teszi meg, az oldal hónapokig vagy évekig futhat ismert, nyilvánosan dokumentált hibákkal.

Mit tehet egy kritikus hiba egy céges oldallal?

A távoli kódfuttatás (remote code execution, RCE) azt jelenti, hogy egy kívülálló a saját utasításait futtathatja azon a szerveren, ahol az oldalad fut. Ha ehhez bejelentkezés sem kell, elvileg bárki megpróbálkozhat vele, aki megtalálja az oldalt. Egy ilyen incidens következménye lehet az ügyféladatok vagy a szerveren tárolt titkos kulcsok (fizetési szolgáltató, CRM, hírlevélküldő, e-mail-szerver hozzáférései) eltulajdonítása, az oldal tartalmának észrevétlen átírása, rejtett kéretlen hivatkozások elhelyezése vagy kártevő terjesztése a látogatók felé.

Ha személyes adatok is érintettek, a GDPR szerint az adatkezelőnek az incidensről tudomásszerzéstől számított 72 órán belül értesítenie kell a felügyeleti hatóságot, Magyarországon a NAIH-t, kivéve ha az incidens valószínűleg nem jár kockázattal az érintettekre nézve. Egy kompromittált oldalt a keresők és a böngészők biztonsági figyelmeztetéssel is megjelölhetnek, ami napok alatt lenullázhatja a forgalmat. Mindez jóval többe kerül, mint egy időben elvégzett frissítés, erre a cikk későbbi részében konkrét, szemléltető számítást is mutatunk.

Mi történt augusztus 25-én és szeptember 22-én?

Augusztus 25-én a Next.js 16.3.3-as és 15.5.24-es verziója két kritikus, bejelentkezés nélkül kihasználható távoli kódfuttatási hibát javított, szeptember 22-re pedig a csapat egy upstream függőség kritikus hibája miatt soron kívüli kiadást ütemezett a 16.3.6-os és a 15.5.26-os verzióval. A két esemény között rendes hibajavító kiadások is megjelentek.

A két kritikus kiadás nem előzmények nélküli. A Netlify tárhelyszolgáltató összesítése szerint már 2026. május elején egy közös React- és Next.js-kiadás tizenkét sérülékenységet javított, júliusban pedig elindult a Next.js formális biztonsági kiadási programja. Az alábbi idővonal a hivatalos Next.js-blog, a Netlify és a Releasebot kiadáskövető oldal adataiból készült.

Augusztus 25.: két kritikus távoli kódfuttatási hiba

A csapat augusztus 20-án még egy kritikus hibát jelentett be augusztus 26-ra, augusztus 25-én azonban előrehozta a kiadást, mert az egyik upstream függőségben egy további kritikus sérülékenységet azonosítottak. A hivatalos közlemény szerint a 16.3.3 (Active LTS) és a 15.5.24 (Maintenance LTS) két problémát zárt be.

Az első a képoptimalizáló felületet (Image Optimization API) érintette, azonosítója GHSA-2xp9-vwfh-vxw4, illetve a libheif oldalán GHSA-g89c-p67h-r497. A Next.js a képek átméretezéséhez és tömörítéséhez a sharp nevű csomagot használja, ez pedig az AVIF és HEIF formátumú képek kezeléséhez a libheif könyvtárra támaszkodik. A közlemény szerint a libheif hibája miatt egy támadó által ellenőrzött AVIF-kép optimalizálása bejelentkezés nélküli távoli kódfuttatáshoz vezethetett. A javított kiadások ezért átmenetileg kikapcsolták az AVIF-optimalizálást, amíg a javítás a teljes láncon végig nem ér. A Releasebot adatai szerint augusztus 31-én a 16.3.4 már javította az AVIF-optimalizálást, a 15.5.25 pedig az újabb sharp-verziókkal visszakapcsolta.

A második hiba (CVE-2026-75604, GHSA-p293-qw3h-jr36) szűkebb kört érintett. A közlemény szerint azok az alkalmazások voltak sérülékenyek, amelyek a Pages Routert és az App Routert együtt használják Cache Components nélkül, ha a Next.js szerver Windows fájlrendszeren fut. Linux és macOS alatt a hiba nem jelentkezik, az érintett Windows-alapú telepítésekre viszont nem létezett ismert kerülőmegoldás, vagyis ott egyedül a frissítés segített.

Szeptember 22.: soron kívüli frissítés, egyelőre részletek nélkül

A Next.js blogján 2026. szeptember 21-én megjelent bejelentés szerint egy upstream függőségben kritikus biztonsági hibát azonosítottak, ezért a csapat szeptember 22-én, a havi ütemezésen kívül (out-of-band) kiadja a 16.3.6-os és a 15.5.26-os verziót. A teljes biztonsági közlemény GHSA-vcvr-r3jv-pc5j azonosítóval a frissítéssel együtt jelenik meg, amely a hatást, az érintett verziókat és a frissítési útmutatót is tartalmazza majd. A csapat kérése egyértelmű: amint elérhető, mindenki frissítsen a 16.3.6-ra vagy a 15.5.26-ra.

Szeptember 22-i ellenőrzésünkkor a GitHubon a GHSA-vcvr-r3jv-pc5j közlemény oldala még nem volt elérhető, a Releasebot kiadáslistájában pedig a két új verzió sem szerepelt még. Nem tudjuk tehát, melyik függőségről van szó, mely funkciókat érinti és milyen feltételek mellett kihasználható a hiba. Mi ezért nem is találgatunk: a felelős hozzáállás ilyenkor az, hogy a közlemény megjelenéséig minden 16.3-as és 15.5-ös ágon futó oldalt érintettnek tekintesz, a frissítés előkészítését pedig már most elkezded. Aki a leltárral, a tesztkörnyezettel és a visszaállítási tervvel ma végez, az a kiadás megjelenése után órák alatt élesítheti a javítást, nem napok alatt.

Kit érint a Next.js biztonsági frissítés: App Router, Pages Router vagy mindkettő?

Az augusztusi hibák közül az egyik minden olyan oldalt érinthetett, amely a beépített képoptimalizálással AVIF-képeket dolgozott fel, a másik csak a Windows-szerveren futó, a két útválasztót vegyesen használó alkalmazásokat. A szeptemberi hiba részletei még nem ismertek, ezért addig minden App Router és Pages Router alapú oldalt érintettnek kell tekinteni.

A router (útválasztó) a Next.js azon része, amely eldönti, melyik webcímhez melyik oldal tartozik és hogyan készül el. A Pages Router a keretrendszer eredeti, régebbi megoldása, amelyben minden oldal egy fájl a pages mappában. Az App Router a Next.js 13 óta elérhető újabb modell, amely az app mappára épül és a React szerverkomponenseit használja. Sok, évek óta futó projekt félúton jár a kettő között: az új oldalak már App Routerrel készülnek, a régiek maradtak Pages Routeren. Az augusztusi Windows-hiba éppen ezt a vegyes állapotot érintette, ami jól mutatja, hogy a félbehagyott migráció nemcsak technikai adósság, hanem biztonsági kockázat is lehet.

A táblázat az augusztusi hivatalos közlemény feltételeit fordítja le gyakorlati helyzetekre, a saját projekted átnézését viszont nem helyettesíti. A statikus exportnál például nincs futó Next.js-szerver, ezért a szerveroldali hibák jellemzően nem érintik, a szeptemberi, egyelőre ismeretlen upstream hibáról viszont ezt sem lehet biztosan kijelenteni.

Mi a helyzet a Vercelen és más menedzselt platformokon futó oldalakkal?

A Next.js csapata a július 13-i programbejelentésében azt írta, hogy az előzetes értesítések célja részben az, hogy a tárhelyszolgáltatókkal és platformpartnerekkel összehangolva átmeneti védelmet, például tűzfalszabályokat vezethessenek be a még nem frissített alkalmazások elé. Ez hasznos biztonsági öv, de nem javítás. A Netlify a májusi kiadásnál azt közölte, hogy több sérülékenység az architektúrája miatt nem vagy csak minimálisan érintette a náluk futó oldalakat, a felhasználóknak ennek ellenére frissíteniük kellett a Next.js-t és újra kellett telepíteniük a projektjeiket.

Ha a céged oldala saját virtuális szerveren, Docker-konténerben vagy egy általános felhőszolgáltatónál fut, akkor nincs, aki előtted beállítsa ezeket az átmeneti szabályokat: ilyenkor te vagy a platform. Ez nem ok a pánikra, csak azt jelenti, hogy a frissítési fegyelem teljes egészében rajtatok múlik.

A React is a képben van

Aki React-alapú oldalt üzemeltet, annak nemcsak a Next.js, hanem a React verziójára is figyelnie kell, mert a két projekt hibái összefüggnek. A Next.js blogja a július 13-i bejegyzésében külön megemlítette a tavaly decemberben nyilvánosságra hozott React2Shell nevű hibát, a Netlify májusi összesítése szerint pedig a tizenkét javított sérülékenység közül egy a React szerverkomponenseiben volt. Ekkor a React 19.0.6-os, 19.1.7-es és 19.2.6-os verziója hozta a javítást. Egy frissítésnél ezért mindig érdemes ellenőrizni, hogy a hivatalos közlemény kér-e React-frissítést is. Ha igen, a két csomagot együtt kell cserélni.

Havonta érkező javítások: a mesterséges intelligencia is hibavadász lett

A 2026. júliusi fordulat előtt a Next.js ritkán, de előzetes figyelmeztetés nélkül adta ki a biztonsági javításait, ami a csapat saját szavai szerint fennakadást okozott a felhasználóknál. A július 13-i bejelentés óta a rend a következő: nagyjából havonta előzetes értesítés jelenik meg a Next.js blogján a várható kiadási időponttal és a várható legmagasabb súlyossággal, a sürgős vagy már aktívan kihasznált hibákra pedig továbbra is soron kívüli javítás érkezik. A szeptember 22-i kiadás pontosan ilyen, egynapos előzetes jelzéssel érkező soron kívüli frissítés.

A csapat azt is leírta, miért lett ennyi dolguk: a bejelentés szerint a sérülékenységkutatás mennyisége az egész iparágban gyorsan nő, amit a nagy nyelvi modellekkel támogatott hibakeresés hajt: a Mozilla egyetlen Firefox-kiadáshoz 271 hibát hozott nyilvánosságra, amelyeket mind az Anthropic Mythos Preview modellje talált meg. A Vercel ugyanilyen eszközöket futtat a Next.js-en a saját deepsec nevű eszközével, saját kutatóival és egy kibővített hibavadász (bug bounty) programmal, hogy a hibák előbb jussanak el hozzájuk, mint a támadókhoz.

Ebből két következtetés adódik. Az első, hogy a gyakoribb biztonsági kiadás nem azt jelenti, hogy a Next.js rosszabb lett, hanem azt, hogy sokkal több szem (köztük gépi szem) nézi a kódot, a hibák pedig előbb derülnek ki. A második kevésbé megnyugtató: ugyanezek az eszközök a támadók kezében is ott vannak. Az OpenAI szeptember 3-án bemutatott GPT-6 Astra modellje a cég közlése szerint az ExploitBench teszten 100%-os eredményt ért el, ami arra utal, hogy a nyilvános hibák kihasználásához egyre kevesebb emberi szakértelem kell. A javítás megjelenése és az első támadási kísérletek között eltelt idő így várhatóan tovább rövidül, a „majd a jövő héten ránézünk” típusú hozzáállás pedig egyre drágább lehet.

Az ügynökségek szempontjából a havi ritmus egyszerre teher és könnyebbség. Teher, mert minden Next.js-alapú ügyféloldalra havonta legalább egy frissítési kört kell tervezni. Könnyebbség, mert a kiszámítható kiadási napokra előre le lehet foglalni a fejlesztői kapacitást, így nem egy péntek délutáni meglepetés borítja fel a heti ütemtervet.

Az upstream függőség: amikor a hiba nem is a Next.js-ben van

Az upstream függőség olyan külső szoftvercsomag, amelyre a Next.js (vagy a te projekted) épít, de nem a Next.js csapata fejleszti. A név a folyó hasonlatából jön: ami a folyón feljebb kerül a vízbe, az előbb-utóbb lejjebb is megérkezik. Egy hiba tehát születhet több lépcsővel „feljebb”, mégis a te oldaladat teszi sebezhetővé.

Az augusztusi AVIF-hiba iskolapéldája ennek. A láncolat nagyjából így néz ki: a céges oldal a Next.js-re épül, a Next.js a képoptimalizáláshoz a sharp csomagot használja, a sharp pedig bizonyos képformátumokhoz a libheif könyvtárat. A hiba a lánc legalsó szemében volt, a Next.js-t használó oldalak mégis ugyanúgy érintettek lettek, mintha a keretrendszerben lett volna. Ha megnézzük az elmúlt egy hónap három kritikus sérülékenységét, abból kettő (az augusztusi AVIF-hiba és a szeptemberi, még részletezetlen hiba) a hivatalos közlemények szerint upstream függőségből eredt. Ez saját összesítés, de jól látszik belőle, hogy a keretrendszer verziószáma csak a jéghegy csúcsa.

Mit jelent ez a gyakorlatban?

Egy átlagos Next.js-projekt a közvetlenül telepített csomagokon felül akár több száz közvetett (tranzitív) függőséget is magával hoz, vagyis olyan csomagokat, amelyeket nem a fejlesztő választott ki, hanem a választott csomagok húznak be. Ezeknek a pontos verzióját a zárolófájl (package-lock.json, pnpm-lock.yaml vagy yarn.lock) rögzíti. A zárolófájl jó dolog, mert garantálja, hogy a fejlesztő gépén és a szerveren ugyanaz fut, de azt is jelenti, hogy egy upstream javítás magától nem kerül be a projektbe: valakinek frissítenie kell a zárolt verziókat, majd újra kell buildelnie és telepítenie az alkalmazást.

A képfeldolgozó könyvtárak ráadásul jellemzően natív, nem JavaScriptben írt programkódok, ezért egy saját szerveren vagy Docker-konténerben futó telepítésnél nem elég a package.json-t átírni. Ilyenkor a konténer alapképét és a build-gyorsítótárat is érdemes frissen újraépíteni, különben előfordulhat, hogy a régi, sérülékeny komponens csendben a helyén marad.

Három eszköz sokat segít abban, hogy az upstream hibák ne érjenek váratlanul. A GitHub Dependabot vagy a Renovate automatikusan figyeli a függőségeket és frissítési javaslatot (pull requestet) nyit, ha egy csomaghoz biztonsági javítás jelenik meg. Az npm audit parancs a build-folyamatba építve jelzi az ismert sérülékenységeket. A szoftveres anyagjegyzék (SBOM, software bill of materials) pedig olyan géppel olvasható lista, amely egy alkalmazás összes összetevőjét és azok verzióját tartalmazza, így egy új közleménynél percek alatt kideríthető, mely ügyféloldalakban szerepel az érintett csomag.

A biztonsági javításnak is lehet mellékhatása

Az augusztusi esetnek van egy második tanulsága is: a javított kiadások az AVIF-optimalizálást átmenetileg kikapcsolták, vagyis a frissítés után az oldalak egy ideig nem ebben a formátumban optimalizálták a képeket, amíg a 16.3.4 és a 15.5.25 augusztus 31-én ezt rendbe nem tette. Egy biztonsági javítás is megváltoztathatja az oldal viselkedését, ami egy képekkel teli webshopnál a betöltési időben és így a Core Web Vitals mutatókban is látszhat. A Core Web Vitals a Google által mért, a felhasználói élményt leíró betöltési, válaszkészségi és vizuális stabilitási mutatók csoportja. Ezért kell a kiadási jegyzetet mindig végigolvasni és a frissítést legalább egy rövid tesztkörön átengedni, akkor is, ha csak a javítószám változik.

Active LTS vagy Maintenance LTS: melyik Next.js-verziót érdemes futtatni?

Az Active LTS a Next.js aktuális főverziója (jelenleg a 16.x), amely új funkciókat, hibajavításokat és biztonsági javításokat is kap, a Maintenance LTS pedig az előző főverzió (jelenleg a 15.x), amely már csak kritikus hibajavításokat és alapvető biztonsági frissítéseket kap. Élesben a 16.x ág legfrissebb javítóverzióját érdemes futtatni.

Az LTS (long-term support, hosszú távú támogatás) azt jelzi, hogy a fejlesztők egy verzióágat meghatározott ideig javításokkal látnak el. A Next.js hivatalos támogatási szabályzata szerint egy főverzió addig marad Active LTS, amíg meg nem jelenik a következő főverzió. Ekkor Maintenance LTS státuszba kerül, az első kiadásától számított két évig pedig még kap kritikus hibajavításokat és alapvető biztonsági frissítéseket. A 14.x és a korábbi verziók már egyáltalán nem támogatottak, a szabályzat csak annyit enged meg, hogy ritka esetben, a hiba súlyosságától függően a csapat az LTS-körön kívüli verziókat is javíthatja.

A javítóverzió nem minden: a kisebb verziót is követni kell

A táblázatnál is fontosabb egy részlet, amely az idei kiadásokból olvasható ki. A júliusi biztonsági kiadás még a 16.2-es és a 15.5-ös ágat javította (16.2.11 és 15.5.21), augusztus 3-án viszont megjelent a Next.js 16.3, az augusztusi és a szeptemberi javítás pedig már csak a 16.3-as és a 15.5-ös ágra érkezett. Aki tehát július végén a 16.2.11-en futott, annak az augusztusi kritikus javításhoz nem egy apró javítószámot kellett léptetnie, hanem egy teljes kisebb verziót (minor release), a 16.3 minden újdonságával együtt. A Next.js blogjának augusztus 3-i bejegyzése szerint a 16.3 akár 90%-kal kevesebb memóriát használ fejlesztés közben és bevezette az Instant Navigations funkciócsomagot, vagyis a váltás nem pusztán egy szám átírása, hanem egy bővebb tesztet igénylő frissítés.

A Next.js a szemantikus verziózást (semver) követi, ahol a három szám a főverziót, a kisebb verziót és a javítóverziót jelöli: a 16.3.6-ban a 16 a főverzió, a 3 a kisebb verzió, a 6 a javítóverzió. Főszabály szerint csak a főverzió váltása hozhat visszafelé nem kompatibilis változást. A támogatási szabályzat azonban kifejezetten rögzíti, hogy a Maintenance LTS ágon a frissítések kisebb verzióként érkezhetnek akkor is, ha visszafelé nem kompatibilis változást tartalmaznak. A 15-ös ágon futó oldalaknál ezért egy látszólag ártalmatlan frissítés is eltörhet valamit, a teszt tehát itt különösen indokolt.

Hogyan kövesd a kiadásokat?

Ügynökségként és házon belüli fejlesztőként is ugyanaz a cél: a biztonsági bejelentés órákon belül eljusson ahhoz, aki dönteni tud róla. Erre több csatorna is kínálkozik, a legjobb pedig az, ha egyszerre többet használsz:

• a Next.js hivatalos blogja, ahol a program szerint nagyjából havonta megjelenik az előzetes értesítés a várható időponttal és súlyossággal;
• a vercel/next.js GitHub-tároló biztonsági közleményei (Security Advisories), amelyekre a tároló figyelésével értesítést lehet kérni;
• a Dependabot vagy a Renovate automatikus frissítési javaslatai minden ügyfélprojekt kódtárában;
• az npm audit futtatása a build-folyamat részeként, amely jelzi, ha ismert sérülékenységű csomag kerülne élesbe;
• a tárhelyszolgáltató vagy a platform (például a Vercel vagy a Netlify) biztonsági értesítései.

Mi történik, ha a 15-ös ágon maradsz október 21. után?

• október 21. után a Next.js 15.x ág kikerül a Maintenance LTS támogatásból, vagyis a szabályzat szerint már nem kap biztonsági javításokat, legfeljebb ritka, a hiba súlyosságától függő kivételként. Minden ezután felfedezett hiba nyitva marad rajta, amelyre az egyetlen tartós megoldás a 16-os főverzióra való átállás.

Ez szeptember 22-én azt jelenti, hogy kevesebb mint egy hónap maradt. Aki most kapja a 15.5.26-os javítást, az ezt jó eséllyel az utolsó néhány 15-ös biztonsági kiadás egyikeként kapja meg. A „ritka kivétel” pedig tényleg ritka: a Netlify májusi összesítése szerint a React- és Next.js-hibák javításánál a 13.x és a 14.x ágra nem terveztek javítást, az ezeken futó oldalak egyszerűen sérülékenyek maradtak.

Az alábbi táblázat azt mutatja, hogy szeptember 22-én milyen verzióról mit érdemes tenni. Az ajánlott határidők a mi javaslataink, nem a Next.js csapatának előírásai.

Mennyi munka a 15-ösről a 16-osra váltani?

Ezt projektje válogatja, ezért csak irányokat lehet mondani. A főverzió-váltás visszafelé nem kompatibilis változásokat hozhat, ezeket a Next.js 16 hivatalos frissítési útmutatója sorolja fel, a rutinszerű átírások nagy részére pedig a Next.js automatikus kódátalakító eszközt (codemod) biztosít. Egy jól karbantartott, néhány tucat oldalas céges bemutatkozó oldalnál ez tapasztalatunk szerint néhány fejlesztői nap tesztekkel együtt. Egy sok egyedi megoldással, elavult külső csomagokkal és a két router vegyes használatával működő projektnél viszont hetekig is eltarthat, mert a függőségek egy részét is cserélni kell.

A legdrágább forgatókönyv az, amikor egy 14-es vagy még régebbi verzión ragadt oldalnál egy kritikus hiba miatt kell hirtelen két főverziót ugrani. Ilyenkor a nyugodt átállás helyett kapkodva, túlórában kell dolgozni, a hibák kockázata pedig éppen akkor a legnagyobb, amikor a legkevésbé van rá idő. A 15-ös ágon futó oldalaknál ezért az a legolcsóbb döntés, ha az átállás még októberben, a saját ütemezésed szerint megtörténik.

Hogyan frissíts úgy, hogy ne boruljon fel az éles oldal?

Biztonságosan úgy frissítesz, hogy a javítást előbb külön fejlesztési ágon és tesztkörnyezetben telepíted, lefuttatod az automatikus és a kézi ellenőrzéseket, majd alacsony forgalmú időszakban, azonnali visszaállítási lehetőséggel élesíted. Egy jól előkészített projektnél ez a teljes kör néhány óra, egy előkészítetlennél akár több nap is lehet.

A tesztkörnyezet (staging) az éles oldal másolata, amely ugyanazzal a kóddal és beállításokkal fut, de a látogatók nem érik el, így ott nyugodtan ki lehet próbálni a változásokat. A Vercelen és a Netlifyn minden fejlesztési ágból automatikusan készülhet előnézeti telepítés (preview deployment), amely ugyanezt a szerepet tölti be. Az alábbi lépések egy tipikus Next.js-projektre vonatkoznak.

• Leltár. Írd össze, melyik oldal melyik Next.js- és React-verzión fut, hol üzemel (menedzselt platformon, saját szerveren, Windows- vagy Linux-környezetben), melyik routert használja és igénybe veszi-e a beépített képoptimalizálást.
• A közlemény elolvasása. Nézd meg a hivatalos biztonsági közleményben az érintett verziókat, a feltételeket, a javasolt javított verziót, az esetleges ideiglenes kerülőmegoldást és a várható mellékhatásokat (mint augusztusban az AVIF-optimalizálás kikapcsolása). Ebből derül ki, hogy az oldal érintett-e és mennyire sürgős a dolog.
• Külön ág és csomagfrissítés. Hozz létre egy új ágat a verziókezelőben, majd frissítsd a next csomagot a javított verzióra, a hivatalos augusztusi bejegyzés példája szerint például az npm install next@16.3.3 paranccsal, szeptemberben értelemszerűen a 16.3.6-tal vagy a 15.5.26-tal. Ha a közlemény kéri, a React-csomagokat is frissítsd, a módosított zárolófájlt pedig mindenképp mentsd el a változtatással együtt.
• Tiszta build. Töröld a build-gyorsítótárat, saját szerveres vagy Docker-alapú telepítésnél frissítsd az alapképet is, majd buildeld újra az alkalmazást. A build figyelmeztetéseit ilyenkor tényleg olvasd el, mert gyakran ezek jelzik előre, hogy egy csomag nem kompatibilis az új verzióval.
• Automatikus tesztek. Futtasd le az egység- és a végponttól végpontig tartó (end-to-end) teszteket a kritikus útvonalakon: kezdőlap, terméklista, termékoldal, kosár, fizetés, ajánlatkérő űrlap, bejelentkezés. Ha ilyen tesztek nincsenek, ez a frissítés jó alkalom arra, hogy legalább ezt a néhány útvonalat lefedjétek velük.
• Kézi füstteszt a tesztkörnyezetben. Egy 15 perces ellenőrzőlistával kattints végig az oldalon: betöltenek-e a képek, működnek-e az űrlapok és az e-mail-értesítések, rendben van-e a sitemap.xml és a robots.txt, nem jelez-e hibát a böngésző konzolja, illetve a mérőkódok (analitika, hirdetési pixelek) továbbra is küldik-e az adatokat.
• Élesítés alacsony forgalomban. Válassz olyan időpontot, amikor a legkevesebb látogató van az oldalon, az előző, működő verzió pedig legyen kéznél. A legtöbb menedzselt platformon egy kattintással visszaállítható az előző telepítés, saját szervernél pedig előre ki kell próbálni, hogyan megy a visszaállás.
• Figyelés egy-két napig. Kövesd a hibaarányt, a válaszidőt, a szervernaplókat, a Core Web Vitals mutatókat és az üzleti számokat (rendelések, ajánlatkérések).
• Dokumentálás és tájékoztatás. Rögzítsd, melyik verzióról melyikre, mikor és milyen eredménnyel frissítettél, majd küldj rövid tájékoztatót az ügyfélnek vagy a cégvezetésnek. Ez a következő incidensnél aranyat ér és a bizalmat is építi.

Mi van, ha nincs idő a teljes körre?

Egy aktívan kihasznált, kritikus hibánál a mérlegelés egyszerű: a frissítés elmaradásának kockázata szinte mindig nagyobb, mint annak az esélye, hogy egy javítóverzió elront valamit. Ilyenkor a rövidített kör is elfogadható: leltár, frissítés, build, a legfontosabb három-négy útvonal gyors ellenőrzése, élesítés, majd a teljes tesztkör pótlása a következő munkanapon. A lényeg, hogy a visszaállítási lehetőség ekkor is meglegyen, a rövidítés pedig tudatos döntés legyen, ne kapkodás eredménye.

Egy webalkalmazás-tűzfal (WAF) vagy a közleményben ajánlott ideiglenes kerülőmegoldás időt nyerhet, de a javítást egyik sem helyettesíti. Az augusztusi Windows-hibánál a hivatalos közlemény szerint nem is létezett ismert kerülőmegoldás.

Halogatás vagy azonnali frissítés: egy képzeletbeli webshop számai

A „majd ha ráérünk” típusú frissítési gyakorlat azért olyan makacs, mert a költsége láthatatlan, amíg nem történik baj. Érdemes ezért egyszer kiszámolni, mibe kerül a rendszeres karbantartás és mibe egyetlen incidens. Az alábbi számok egy szemléltető példa feltételezésein alapulnak, nem valós ügyfél adatai.

Vegyünk egy képzeletbeli debreceni webshopot, amelynek Next.js-alapú kirakata havonta 15 millió Ft online forgalmat hoz, vagyis 30 nappal számolva naponta átlagosan 500 000 Ft-ot. Tegyük fel, hogy a fejlesztői óradíj 15 000 Ft, a Next.js pedig egy évben tizenkét tervezett és két soron kívüli biztonsági kiadást hoz, ami tizennégy frissítési kört jelent. Ha a projektben vannak automatikus tesztek és működő tesztkörnyezet, egy kör nagyjából két óra munka. Ehhez jön évente egy tervezett főverzió-váltás, amelyet ennél az oldalnál három fejlesztői napra, azaz 24 órára becsülünk.

A számítás nem azt állítja, hogy minden elmaradt frissítés biztosan incidenshez vezet. Azt viszont megmutatja, hogy egyetlen komolyabb eset a mi feltételezéseink mellett több mint három évnyi rendszeres karbantartás költségét viszi el, pedig ebben még nincs benne a nehezen mérhető kár, például az, hogy a vásárlók egy része a hír hallatán egyszerűen máshol rendel.

A táblázatból egy második, kevésbé nyilvánvaló tanulság is kiolvasható. Ha a projektben nincsenek automatikus tesztek és minden frissítési kört kézzel, mondjuk hat órában kell végigcsinálni, akkor a tizennégy kör 84 órára, azaz 1 260 000 Ft-ra nő. A kritikus útvonalakat lefedő tesztek megírása így néhány frissítési kör alatt megtérülhet, ráadásul a gyors reakciót is lehetővé teszi, amikor egy szeptember 22-ihez hasonló soron kívüli kiadás érkezik.

Mit tanulhat a két riasztásból minden ügynökség?

Az ügynökségek legfontosabb tanulsága, hogy egy Next.js-alapú oldal nem egyszer átadott termék, hanem folyamatosan karbantartandó szoftver. A biztonságos működéshez ügyfelenkénti verzióleltár, a biztonsági értesítésekért felelős kolléga, írásban vállalt frissítési határidő, automatikus tesztek és tesztkörnyezet, valamint rendszeres ügyfélkommunikáció kell.

Leltár nélkül nincs gyors reakció

Szeptember 21-én este az az ügynökség tudott nyugodtan aludni, amelyik egy táblázatból percek alatt ki tudta listázni, melyik ügyfele fut 16.3-as, melyik 15.5-ös és melyik még régebbi Next.js-en, hol üzemelnek ezek az oldalak és ki felel értük. Akinek ehhez minden projektet egyenként elő kellett vennie, az a soron kívüli kiadás napját keresgéléssel töltötte a javítás helyett. A leltár elkészítése egyszeri munka, a karbantartása pedig havi néhány perc.

Legyen neve annak, aki a riasztást olvassa

A Next.js csapata előre jelzi a kiadásokat, de ez csak akkor ér valamit, ha a jelzés valakinek a postafiókjában landol, aki dönteni is tud róla. Érdemes kijelölni egy felelőst és egy helyettest, valamint rögzíteni, hogy egy kritikus besorolású bejelentés után hány órán belül kell elkészülnie az első értékelésnek (érintett-e az ügyfél, mikor frissítünk, kell-e szólni neki).

A frissítési határidő kerüljön be a szerződésbe

Az ügyfél akkor tudja számon kérni a gyors reakciót, ha az szerepel a karbantartási szerződésben. Mi észszerűnek tartjuk, ha a kritikus súlyosságú javítás egy-két munkanapon belül, a magas súlyosságú egy héten belül, a többi pedig a következő tervezett frissítési körben kerül élesbe. A pontos számok ügyfelenként eltérhetnek, a lényeg az, hogy legyenek leírva és mindkét fél ugyanazt értse alattuk.

Ne ragadj le régi kisebb verzión és félkész migrációban

Az idei kiadásokból két konkrét figyelmeztetés olvasható ki. Az egyik a már említett jelenség, hogy a biztonsági javítások csak a legfrissebb kisebb verzióra érkeznek. A másik, hogy az augusztusi Windows-hiba éppen a két routert vegyesen használó projekteket érintette. A félbehagyott App Router-migrációt ezért érdemes befejezni, a Next.js-t pedig különösebb ok nélkül nem Windows-szerveren, hanem Linux-alapú környezetben futtatni.

Csökkentsd a támadási felületet

Minél kevesebb funkció fut élesben, annál kevesebb hiba érintheti az oldalt. A beépített képoptimalizáló például a Next.js beállításaiban (images.remotePatterns) korlátozható arra, hogy csak megbízható, előre megadott forrásokból fogadjon távoli képeket, ami általános jó gyakorlat. A szerveren tárolt titkos kulcsokból csak annyi legyen, amennyi tényleg kell, jogosultságuk pedig a lehető legszűkebb legyen. Egy gyanús esemény után a kulcsok cseréje az első lépések egyike, ezért azt is előre dokumentálni kell, melyik kulcs hol és hogyan cserélhető.

Az automatizálás segít, de nem dönt helyetted

A Dependabot és a Renovate nagyszerűen jelzi a frissítéseket, de egy automatikusan nyitott frissítési javaslatot tesztek nélkül élesbe engedni könnyen új hibát hozhat az oldalra. Az AI-alapú hibakeresőket a Next.js csapata is használja, egy ügynökségnél is hasznos segítők lehetnek, a sürgősség megítélése és az élesítés jóváhagyása azonban maradjon egy felelős ember döntése.

Kommunikálj akkor is, ha nincs baj

A legtöbb ügyfél csak akkor hall a frissítésekről, amikor valami elromlott. Egy havi, néhány soros összefoglaló (melyik verzión fut az oldal, milyen javítások kerültek fel, van-e közelgő teendő, például a 15-ös ág október 21-i kifutása) sokkal jobb alapot ad a bizalomhoz, mint az utólagos magyarázkodás. Így az ügyfél azt is látja, miért fizet a karbantartásért.

Öt kérdés, amelyet még ezen a héten tegyél fel a fejlesztődnek

Ha a céged oldala Next.js-en fut, nem kell értened a kódhoz ahhoz, hogy felmérd, jó kezekben van-e. Az alábbi öt kérdésre egy felkészült fejlesztő vagy ügynökség rövid, konkrét választ tud adni, a homályos válasz viszont önmagában is intő jel.

Ha a válaszok többsége a jobb oldali oszlopba esik, az nem feltétlenül jelenti, hogy rossz a fejlesztőd, de azt igen, hogy a frissítés nálatok senkinek sincs a feladatlistáján. Ilyenkor a legjobb lépés egy rövid, független biztonsági és verzióátvilágítás, amely után egyértelmű lesz, mennyi munka van hátra és mi a sorrend.

Miben segít a Convergo?

Ha nem tudod pontosan, melyik Next.js-verzión fut az oldalad, vagy nincs írásos megállapodásod a biztonsági frissítésekről, az IT audit és digitális tanácsadás keretében feltérképezzük a weboldalad és a webes rendszereid verzióit, függőségeit és kitettségét. A support, üzemeltetés és tárhely szolgáltatásunk részeként (Support csomag: 30 000 Ft/hó, benne 3 fejlesztői óra) nyomon követjük a biztonsági kiadásokat, a javításokat pedig tesztkörnyezetben ellenőrizve telepítjük. Ha a 15-ös ágról a 16-osra kell átállni, vagy félbemaradt App Router-migrációt kell befejezni, a programozás és egyedi fejlesztés csapatunk tervezetten, ütemezve elvégzi. Az első lépés egy ingyenes egyeztetés, ahol közösen átnézzük, hol tart most az oldalad.