Vulnerabilități critice Next.js: patch-ul din 14 octombrie

Pe 14 octombrie 2026, Vercel a publicat Next.js 16.4.1 și 15.5.28, un update de securitate în afara ciclului obișnuit. Repară trei vulnerabilități Next.js: două critice, cu scor CVSS v4 de 9.5, care permit execuție de cod la distanță (RCE) fără autentificare, și una de severitate ridicată, care poate bloca serverul cu cereri construite special. Una dintre cele critice are identificatorul CVE-2026-96889 și vine dintr-o bibliotecă de procesare SVG folosită de sharp.

Dacă rulezi o aplicație Next.js în producție, fie pe Vercel, fie self-hosted într-un container sau pe un VPS, merită să citești până la capăt. Pe lângă versiunile reparate, găsești o capcană concretă pentru proiectele pe Next.js 15: poți face upgrade corect și să rămâi vulnerabil, din cauza lockfile-ului. Găsești și cum verifici în cinci minute ce rulează de fapt pe server.

Ce s-a întâmplat între 30 septembrie și 20 octombrie

Update-ul din 14 octombrie nu a venit din senin. E a doua jumătate a unei lansări de securitate care a fost amânată.

Pe 30 septembrie, Next.js a publicat lansarea de securitate din septembrie (16.3.8 și 15.5.27), cu șapte probleme rezolvate, de la SSRF în Image Optimization la cache poisoning pe paginile SSG și ISR. În același anunț, echipa spunea că două fix-uri, unul critic și unul de severitate ridicată, au fost amânate din cauza unor întârzieri la dependențe upstream. Tot pe 30 septembrie, maintainerul sharp publica advisory-ul GHSA-wq5f-xc86-pv6w pentru bug-ul din librsvg.

Pe 8 octombrie, Vercel a anunțat în avans update-ul pentru miercuri, 14 octombrie, cu două vulnerabilități critice și una ridicată, toate în dependențe upstream. Pe 14 octombrie au apărut versiunile reparate și advisory-urile complete. Pe 20 octombrie, Agenția de Securitate Cibernetică din Singapore a emis o alertă oficială cu recomandarea de a instala patch-ul imediat.

Situația exploatării

Potrivit The Hacker News, pe 15 octombrie nu exista niciun raport public de atac care să folosească vreuna dintre cele trei vulnerabilități. Același articol notează însă că un exploit funcțional pentru vulnerabilitatea din septembrie în next/og a fost deja publicat, iar cercetătorul care a raportat bug-ul din librsvg leagă cele două probleme de aceeași cauză. Cu alte cuvinte, atacatorii au deja un punct de plecare.

„Nicio exploatare raportată” nu e un motiv să amâni. După anunțul în avans din 8 octombrie, toată lumea știa că urmează ceva critic. După 14 octombrie, advisory-urile spun exact unde să cauți. Diferența dintre o versiune reparată și una vulnerabilă e publică, deci reverse-engineering-ul patch-ului e doar o chestiune de timp.

De unde vin vulnerabilitățile

Toate trei își au originea în cod pe care Next.js îl folosește, dar nu îl scrie:

• React Server Components, pentru RCE-ul din use cache și pentru DoS-ul din Server Actions. React a publicat advisory-urile corespondente GHSA-xqc2-xf4c-x3h3 și GHSA-h3gv-c5rc-p453.
• librsvg, biblioteca de decodare SVG pe care sharp o include în binarele lui precompilate, pentru CVE-2026-96889.

Asta contează practic. Vulnerabilitatea nu e în codul tău și nu se repară cu npm install react@latest. Next.js livrează propria copie compilată a rendererului React pentru server, așa că doar upgrade-ul pachetului next aduce fix-ul.

Cele trei vulnerabilități, pe scurt

Fiecare are alte condiții de declanșare. Unele aplicații sunt expuse la toate trei, altele doar la una. Diagrama de mai jos rezumă cine e afectat de ce.

RCE în funcțiile use cache (GHSA-673q-mjm6-r5xr)

Advisory-ul descrie o execuție de cod la distanță fără autentificare în aplicațiile care folosesc App Router cu Cache Components, atunci când o funcție marcată use cache returnează mai multe typed arrays (Uint8Array, Float32Array și altele din aceeași familie). React descrie condiția ca fiind un caz „extrem de rar”: un răspuns care transportă mai multe typed arrays împreună cu o valoare controlată de atacator.

Detalii importante:

• Versiuni afectate: doar Next.js 16, de la 16.0.0 până la 16.4.0. Reparat în 16.4.1. Ramura 15 nu e listată.
• Scor: CVSS v4 9.5, vector AV:N/AC:L/AT:P/PR:N/UI:N, adică atac prin rețea, fără cont, fără interacțiune, cu o precondiție (AT:P), anume existența unei funcții de tipul descris.
• Workaround: nu există. Advisory-ul spune explicit să faci upgrade imediat, chiar dacă aplicația ta nu are funcții de acest tip.

Ultima recomandare pare exagerată, dar are sens. Codul tău de azi poate să nu aibă o asemenea funcție, iar mâine un coleg poate adăuga una într-un PR fără să știe de advisory. Sau o poate aduce o bibliotecă.

RCE la procesarea SVG prin sharp (CVE-2026-96889)

Al doilea RCE critic e un bug de memorie în librsvg. Red Hat îl descrie ca un use-after-free care apare când librsvg procesează un SVG cu XInclude-uri imbricate și declarații de entități duplicate: biblioteca eliberează o entitate XML pe care parserul încă o folosește. Next.js ajunge la librsvg prin sharp, biblioteca de procesare a imaginilor pe care o folosește Image Optimization.

Advisory-ul Next.js dă:

• Versiuni afectate: de la 10.0.0 până la 15.5.27 și de la 16.0.0 până la 16.4.0.
• Versiuni reparate: 15.5.28 și 16.4.1, cu condiția să ai sharp 0.35.5 sau mai nou.
• Scor: CVSS v4 9.5.
• Condiție de mediu: Next.js rulează pe Linux bazat pe glibc (Debian, Ubuntu, RHEL și imaginile Docker derivate din ele).

DoS în Server Actions (GHSA-p3m5-59mp-jv5r)

A treia problemă nu duce la execuție de cod, dar poate opri aplicația. Potrivit advisory-ului, cereri construite special către o aplicație App Router cu cel puțin o Server Action pot urca procesorul la maximum. Procesul Node.js rămâne blocat și nu mai servește alte cereri.

• Versiuni afectate: 13.0.0 până la 15.5.27 și 16.0.0 până la 16.4.0. Reparat în 15.5.28 și 16.4.1.
• Scor: CVSS v4 8.2, impact doar pe disponibilitate (VA:H).
• Neafectate: aplicațiile Pages Router și aplicațiile App Router fără nicio Server Action.
• Workaround: nu există, doar upgrade.

Un DoS pare mai puțin grav decât un RCE. Pe un self-hosted cu un singur proces Node, însă, o singură cerere bine construită înseamnă un site căzut până la restart. Iar formularele de contact, coșurile de cumpărături și panourile de administrare construite pe App Router folosesc frecvent Server Actions.

Cine e afectat de vulnerabilitatea Next.js

Sunt trei întrebări simple: ce versiune rulezi, ce router folosești și unde rulează aplicația.

Versiuni afectate și versiuni reparate

Rândurile pentru 13.x și 14.x merită o explicație. Advisory-urile includ aceste versiuni în intervalul afectat, dar fix-urile au apărut doar pentru 15.5 și 16.4, cele două ramuri cu suport LTS. Potrivit analizei HOL, pentru Next.js 14 și mai vechi poți fixa sharp la 0.35.5 ca să închizi calea SVG, dar DoS-ul din Server Actions rămâne deschis până migrezi la o ramură suportată.

Exportul static (output: 'export') nu are server la runtime, deci niciuna dintre cele trei căi nu există în producție. Dacă servești doar HTML generat la build, de pe un CDN, ești în afara problemei. Singura excepție: build-ul în sine procesează SVG-uri din surse în care nu ai încredere.

App Router sau Pages Router

Calea SVG nu ține de router, ci de Image Optimization și de mediul în care rulează procesul. De aceea apare „depinde de mediu” pe fiecare rând.

Mediul de rulare: glibc, musl și Node.js PIE

Advisory-urile limitează RCE-ul prin SVG la Linux bazat pe glibc. Imaginile Alpine (musl), macOS și Windows nu sunt în condiția declarată. Advisory-ul sharp mai adaugă un detaliu: un binar Node.js compilat ca Position Independent Executable (PIE) blochează calea de execuție de cod. Binarele oficiale Node.js de pe nodejs.org nu sunt PIE. Cele din pachetele distribuțiilor Linux, de regulă, sunt.

Maintainerul sharp explică astfel de ce același bug poate produce doar un crash pe un server și execuție de cod pe altul: depinde de cum a fost compilat Node.js. Pentru tine, concluzia practică e simplă. Imaginea Docker oficială node:22 sau node:24 (Debian, glibc, binar non-PIE) e exact combinația despre care avertizează advisory-ul.

SVG: Image Optimization, next/og și codul tău

Potrivit The Hacker News, optimizarea SVG în next/image e dezactivată implicit și se activează doar cu images.dangerouslyAllowSVG. Asta reduce expunerea, dar nu o elimină. Același articol spune că bug-ul e atins și prin next/og pe runtime-ul Node.js, iar Netlify indică ImageResponse din next/og ca fiind calea relevantă pe platforma lor. În plus, orice cod din aplicația ta care trimite un SVG primit de la utilizator către sharp (generare de thumbnail-uri, avatare, import de logo-uri) e expus, indiferent de Next.js.

Vercel nu condiționează însă advisory-ul de dangerouslyAllowSVG. Advisory-ul oficial cere upgrade fără excepții, iar o configurare care azi e sigură poate fi schimbată mâine. Tratează setarea ca pe un factor de risc, nu ca pe o scutire.

Vercel, Netlify sau self-hosted

Advisory-urile Vercel nu spun că deploy-urile de pe platforma Vercel ar fi protejate automat. Pentru vulnerabilitățile din septembrie, Vercel a precizat explicit când aplicațiile găzduite la ei nu sunt afectate. Pentru cele din octombrie nu există o asemenea precizare, deci presupune că ești expus până faci redeploy cu versiunea nouă.

Netlify spune că platforma lor nu rulează calea Image Optimization afectată și că impactul e limitat, dar recomandă oricum upgrade-ul. Netlify mai semnalează o capcană ușor de ratat: deploy-urile de preview și de branch rămân pe versiunea veche până le ștergi. Un preview de acum trei săptămâni, cu URL public, e tot un server Next.js vulnerabil. Același lucru e valabil pe Vercel și pe orice platformă care păstrează deploy-uri vechi accesibile.

Pe self-hosted (Docker, VPS, Kubernetes) riscul e cel mai mare, pentru că ai cel mai probabil glibc, binarul oficial Node.js și Image Optimization activ în același proces. Dacă ai construit un SaaS MVP pe Next.js și îl rulezi pe propria infrastructură, ești exact în profilul vizat.

Capcana Next.js 15: upgrade făcut, sharp vechi

Pentru ramura 15, cea mai importantă parte a acestui update e una pe care advisory-ul o menționează doar în treacăt.

De ce un upgrade corect poate rămâne vulnerabil

Next.js 15.5.28 declară sharp cu intervalul ^0.34.3 || ^0.35.5. Next.js 16.4.1 cere ^0.35.5. Diferența pare minoră, dar are consecințe:

• Pe Next.js 16, upgrade-ul la 16.4.1 forțează sharp 0.35.5. Fix-ul vine automat.
• Pe Next.js 15, dacă package-lock.json (sau pnpm-lock.yaml, yarn.lock) are deja sharp 0.34.x, acea versiune satisface noul interval. Managerul de pachete nu are niciun motiv s-o schimbe. Rezultatul: npm ls next îți arată 15.5.28, iar decodorul SVG din producție e tot cel vulnerabil.

sharp 0.35.5, publicat pe 27 septembrie, e prima versiune reparată și include librsvg 2.63.2. Orice sharp sub 0.35.5 e afectat.

Cum forțezi versiunea corectă

Cea mai sigură metodă e un override, care fixează sharp peste tot în arborele de dependențe, inclusiv în pachetele care îl aduc tranzitiv:

1{
2  "dependencies": {
3    "next": "15.5.28"
4  },
5  "overrides": {
6    "sharp": "^0.35.5"
7  }
8}

1{
2  "dependencies": {
3    "next": "15.5.28"
4  },
5  "overrides": {
6    "sharp": "^0.35.5"
7  }
8}

Pe pnpm, echivalentul este "pnpm": { "overrides": { "sharp": "^0.35.5" } } în package.json. Pe Yarn, folosești resolutions. După modificare:

1# Regenerate the lockfile with the override applied
2npm install
3
4# Every sharp entry in the tree must be 0.35.5 or newer
5npm ls sharp
6
7# Commit both files: npm ci installs exactly what the lockfile pins
8git add package.json package-lock.json
9git commit -m "fix(deps): upgrade next to 15.5.28 and pin sharp >= 0.35.5"

1# Regenerate the lockfile with the override applied
2npm install
3
4# Every sharp entry in the tree must be 0.35.5 or newer
5npm ls sharp
6
7# Commit both files: npm ci installs exactly what the lockfile pins
8git add package.json package-lock.json
9git commit -m "fix(deps): upgrade next to 15.5.28 and pin sharp >= 0.35.5"

Dacă rulezi npm ci în CI sau în Dockerfile, instalează exact ce e în lockfile. Un package.json corect cu un lockfile necommitat nu schimbă nimic în producție.

Ce ratează npm audit

Potrivit The Hacker News, pe 15 octombrie advisory-urile pentru use cache și Server Actions nu aveau CVE și nu apăreau în feed-ul de advisory-uri pe care îl folosește npm audit. Doar problema SVG era vizibilă, prin advisory-ul propriu al sharp. Scannerele de dependențe recuperează de obicei în câteva zile, dar un npm audit curat din săptămâna aceea nu spunea nimic despre cele două vulnerabilități React.

Lecția depășește acest incident. Un scanner automat e un plus, nu o sursă de adevăr. Pentru framework-urile pe care îți rulezi producția, abonează-te direct la canalul de securitate al proiectului (pentru Next.js, blogul oficial și pagina de advisory-uri de pe GitHub).

Cum verifici în cinci minute ce rulează de fapt

Versiunea din package.json e o intenție, nu o realitate. Verifică în locul în care rulează aplicația.

Versiunile Next.js și sharp

Rulează comenzile din directorul aplicației, de preferat în containerul de producție sau într-o copie identică a lui:

1# Resolved versions, including transitive copies
2npm ls next sharp
3
4# Exact runtime versions, read from the installed packages
5node -p "require('next/package.json').version"
6node -p "require('sharp/package.json').version"
7
8# Monorepos: every copy of next across workspaces
9npm ls next --all
10pnpm why next -r

1# Resolved versions, including transitive copies
2npm ls next sharp
3
4# Exact runtime versions, read from the installed packages
5node -p "require('next/package.json').version"
6node -p "require('sharp/package.json').version"
7
8# Monorepos: every copy of next across workspaces
9npm ls next --all
10pnpm why next -r

Pentru Next.js 16 vrei să vezi cel puțin 16.4.1. Pentru 15, cel puțin 15.5.28 și sharp cel puțin 0.35.5. Un alt loc rapid de verificat e log-ul de build: next build afișează versiunea pe primul rând, deci o găsești în CI sau în log-urile platformei de hosting.

Mediul: glibc sau musl, PIE sau nu

1# glibc or musl? (musl prints "musl libc" or fails on Alpine)
2ldd --version
3
4# Is the Node binary position-independent?
5# "pie executable" = PIE, plain "executable" = non-PIE
6file "$(command -v node)"

1# glibc or musl? (musl prints "musl libc" or fails on Alpine)
2ldd --version
3
4# Is the Node binary position-independent?
5# "pie executable" = PIE, plain "executable" = non-PIE
6file "$(command -v node)"

Combinația de risc maxim pentru CVE-2026-96889 este: glibc, Node non-PIE, sharp sub 0.35.5. Fă upgrade-ul indiferent de rezultat. Verificarea mediului îți spune doar cât de urgent era, nu dacă e necesar.

Imaginile Docker

Docker poate reutiliza un strat vechi în care npm ci a instalat versiunile de dinainte. După upgrade, construiește fără cache și verifică în imaginea rezultată:

1docker build --no-cache -t myapp:patched .
2docker run --rm myapp:patched node -p "require('next/package.json').version"
3docker run --rm myapp:patched node -p "require('sharp/package.json').version"

1docker build --no-cache -t myapp:patched .
2docker run --rm myapp:patched node -p "require('next/package.json').version"
3docker run --rm myapp:patched node -p "require('sharp/package.json').version"

Dacă imaginea de bază e fixată pe un digest, actualizează și digest-ul. Pe Kubernetes, confirmă că pod-urile vechi au fost înlocuite (kubectl rollout status) și că niciun replica set vechi nu mai servește trafic.

Ce faci în funcție de situația ta

Matricea cu cele trei vulnerabilități îți arată la ce ești expus. Pașii de mai jos îți spun ce faci, în ordinea urgenței.

Next.js 16.x

1. npm install next@16.4.1 (sau ultima 16.x disponibilă).
2. Verifică npm ls sharp: trebuie să fie 0.35.5+, ceea ce se întâmplă automat pe 16.4.1.
3. Commit pentru package.json și lockfile, build, redeploy.
4. Șterge sau redeployează deploy-urile de preview și de branch care mai sunt publice.

Next.js 15.x

1. npm install next@15.5.28.
2. Adaugă override-ul pentru sharp (secțiunea de mai sus) și regenerează lockfile-ul.
3. Confirmă npm ls sharp și npm ls next, apoi commit, build fără cache, redeploy.
4. Același pas pentru deploy-urile de preview.

Next.js 14 sau mai vechi

Aici nu există release reparat. Fixează sharp la 0.35.5 cu un override, ca să închizi calea SVG, și planifică migrarea pe 15.5 sau 16.4. DoS-ul din Server Actions rămâne deschis pe 14.x până la migrare. Dacă aplicația nu folosește Server Actions, riscul rămas e mic. Dacă le folosește, pune limite de rată și timeout-uri stricte la proxy (Nginx, load balancer, WAF) și rulează mai multe procese în spatele unui balancer, ca un proces blocat să nu oprească tot site-ul.

Dacă nu poți face upgrade azi

Pentru use cache și Server Actions nu există workaround oficial. Pentru calea SVG există două măsuri temporare, documentate în advisory-ul sharp:

1// Stop sharp from decoding SVG input anywhere in this process.
2// Run it once at startup, before any image is processed.
3const sharp = require("sharp");
4sharp.block({ operation: ["VipsForeignLoadSvg"] });

1// Stop sharp from decoding SVG input anywhere in this process.
2// Run it once at startup, before any image is processed.
3const sharp = require("sharp");
4sharp.block({ operation: ["VipsForeignLoadSvg"] });

• Blocarea decodorului SVG în sharp, ca mai sus. Dacă aplicația nu are nevoie să proceseze SVG-uri, e o măsură pe care o poți păstra și după patch.
• Un binar Node.js compilat ca PIE, de exemplu cel din pachetele distribuției, în loc de binarul oficial. Reduce riscul de RCE, nu și pe cel de crash.

Pe lângă ele, dezactivează images.dangerouslyAllowSVG dacă e activ și nu ai nevoie de el, și nu trimite SVG-uri primite de la utilizatori către sharp sau next/og până la upgrade.

Dacă rulai o versiune vulnerabilă

Nu au fost publicați indicatori de compromitere pentru aceste vulnerabilități, iar exploatarea nu a fost raportată până la jumătatea lui octombrie. Asta reduce probabilitatea unui incident, dar nu o elimină. Dacă aplicația ta a fost expusă, mai ales self-hosted, pe glibc, cu Image Optimization activ pentru surse externe, fă câteva verificări de bază.

Ce cauți

• Procese neașteptate pornite de utilizatorul sub care rulează Node.js (ps -u node -o pid,lstart,cmd), mai ales shell-uri, curl, wget sau mineri.
• Conexiuni de ieșire către adrese necunoscute, din containerul aplicației.
• Fișiere noi în directoarele aplicației sau în /tmp, create după 8 octombrie, data anunțului în avans.
• Restart-uri și crash-uri ale procesului Node.js în log-uri, mai ales corelate cu cereri către /_next/image sau către rutele next/og. Un crash în librsvg poate fi o încercare de exploatare nereușită.
• Vârfuri de CPU la 100% pe un singur proces, corelate cu cereri POST către rute cu Server Actions.

Secretele trebuie tratate ca expuse

Un RCE în procesul Next.js rulează cu toate variabilele de mediu ale aplicației: chei de bază de date, NEXTAUTH_SECRET, chei API pentru plăți, email tranzacțional sau modele AI. Dacă găsești orice semn de compromitere, rotește toate aceste secrete, nu doar parola bazei de date. Pe o aplicație cu mai mulți clienți, un singur proces compromis poate citi datele tuturor, iar modelul de izolare multi-tenant pe care l-ai ales decide cât de mare e paguba.

Dacă aplicația procesa date personale și găsești dovezi de acces neautorizat, articolul 33 din GDPR cere notificarea ANSPDCP în cel mult 72 de ore de la momentul în care afli de încălcare. Checklist-ul pentru un site legal în România te ajută să faci inventarul datelor colectate înainte să ai nevoie de el sub presiunea termenului de 72 de ore.

Ce înveți din acest update

În două săptămâni, Next.js a publicat două update-uri de securitate cu zece probleme în total, iar în aceeași lună PHP a avut PHP2Shell. Ritmul nu e întâmplător. Framework-urile full-stack fac tot mai mult pe server, deci suprafața de atac crește odată cu ele.

Dependențele tale au dependențe

Niciuna dintre cele trei probleme nu era în codul Next.js propriu-zis. Două erau în React, una într-o bibliotecă C de decodare SVG, inclusă într-un binar precompilat al unui pachet npm opțional. Un inventar care se oprește la package.json nu vede nimic din toate astea. Un SBOM generat la build (de exemplu cu npm sbom sau Syft) și verificat la fiecare deploy le vede.

Lockfile-ul e o decizie de securitate

Capcana sharp pe Next.js 15 arată că upgrade-ul unei dependențe directe nu actualizează automat dependențele ei tranzitive. Revizuiește diff-ul lockfile-ului la fiecare update de securitate, nu doar package.json. Dacă diff-ul nu conține pachetul pe care advisory-ul spune că trebuie să-l schimbi, upgrade-ul nu e complet.

Mediul de rulare face parte din vulnerabilitate

Aceeași versiune de sharp produce un crash pe un server și execuție de cod pe altul, în funcție de libc și de modul în care a fost compilat Node.js. Alegerea imaginii de bază (Debian sau Alpine, binar oficial sau din distribuție) e o decizie de securitate, nu doar de mărime a imaginii. Documenteaz-o și revizuiește-o. Pe 21 octombrie, Node.js a confirmat ideea din alt unghi: vulnerabilitatea Brotli CVE-2026-111497 stă în binarul Node, deci niciun npm install nu o repară, ci doar o versiune nouă a runtime-ului.

Ciclurile LTS contează

Echipele pe Next.js 13 și 14 nu au primit release. Pentru ele, un update de cinci minute a devenit o migrare. Dacă un pipeline RAG construit pe Next.js sau un panou intern rulează încă pe o ramură ieșită din suport, acum e momentul să-l muți. Pentru alte articole despre protejarea aplicațiilor web, vezi categoria Securitate aplicații web și eticheta Securitatea datelor.

Întrebări frecvente

Ce versiuni Next.js repară vulnerabilitățile din octombrie 2026?

Next.js 16.4.1 pentru ramura 16 și 15.5.28 pentru ramura 15. Pe 15.5.28 trebuie să te asiguri separat că sharp e la 0.35.5 sau mai nou, pentru că intervalul declarat acceptă încă sharp 0.34, iar un lockfile vechi îl poate păstra.

Ce este CVE-2026-96889?

E un use-after-free în librsvg, biblioteca de decodare SVG inclusă în sharp. Prin Image Optimization din Next.js poate duce la execuție de cod la distanță pe Linux cu glibc. Vercel îl evaluează la CVSS v4 9.5. Fix-ul e sharp 0.35.5, care include librsvg 2.63.2.

Aplicația mea folosește Pages Router. Sunt afectat?

Nu de RCE-ul din use cache și nici de DoS-ul din Server Actions. Poți fi însă afectat de CVE-2026-96889, care ține de procesarea imaginilor, nu de router. Fă upgrade-ul oricum.

E suficient să actualizez React la ultima versiune?

Nu. Next.js livrează propria copie compilată a rendererului React pentru server. Fix-ul pentru use cache și Server Actions vine doar odată cu upgrade-ul pachetului next. Actualizarea directă a pachetelor react-server-dom-* contează doar dacă folosești React Server Components fără Next.js.

Sunt protejat dacă găzduiesc aplicația pe Vercel?

Advisory-urile Vercel nu spun că deploy-urile de pe platformă sunt protejate automat. Fă redeploy cu versiunea reparată și șterge deploy-urile de preview vechi, care rămân pe codul vulnerabil.

npm audit nu raportează nimic. Înseamnă că sunt în siguranță?

Nu neapărat. La publicare, două dintre cele trei advisory-uri nu aveau CVE și nu apăreau în feed-ul folosit de npm audit. Verifică direct versiunile cu npm ls next sharp și compară-le cu cele din advisory.

Următorul pas

Fă upgrade la 16.4.1 sau 15.5.28 azi, confirmă sharp 0.35.5 în lockfile și în containerul de producție, apoi curăță deploy-urile de preview vechi. Dacă aplicația ta rulează pe o ramură Next.js fără suport, pune migrarea în sprintul următor, cu termen și responsabil. Pentru felul în care arhitectura unei platforme web influențează costul unor astfel de update-uri, vezi hub-ul SaaS.