Уеб и бизнес · 1.09.2026 г. · 10 мин. четене

Next.js security update 2026: две критични RCE уязвимости

Next.js публикува критичен security update за две RCE уязвимости. Виж кои версии са засегнати, какво да провериш и как да обновиш production проекта си.

Next.js security update 2026: две критични RCE уязвимости

На 25 август 2026 г. Next.js публикува security release за две уязвимости с критична тежест, които при определени конфигурации могат да доведат до Remote Code Execution (RCE) без предварителна автентикация.

Първите поправени версии в поддържаните линии са:

  • Next.js 16.3.3
  • Next.js 15.5.24

Важно е обаче да ги разглеждаме като минимално поправените версии за конкретния security release, а не като версии, към които трябва непременно да се връщаме.

При реален production проект правилният подход е да се използва най-новата съвместима версия в поддържаната major/LTS линия, след като бъде проверена съвместимостта на приложението.

Фактът, че е открита критична уязвимост в Next.js, не означава автоматично, че всеки Next.js сайт е бил еднакво изложен на риск.

При едната уязвимост значение има image optimization pipeline-ът.

При другата - конкретна комбинация от hosting среда и router архитектура.

Затова въпросът не е само „Каква Next.js версия използваме?“ а:

„Може ли конкретният уязвим code path изобщо да бъде достигнат в нашия production проект?“

Какво беше открито?

Security release-ът от август адресира две отделни уязвимости, които могат да доведат до Remote Code Execution.

RCE е сред най-сериозните категории уязвимости при server-side приложенията.

При успешна експлоатация атакуващият може потенциално да накара сървъра да изпълни код, който разработчикът никога не е предвиждал да бъде изпълняван.

Двете уязвимости обаче имат различен attack surface.

1. RCE при обработване на AVIF изображения

Първата уязвимост е свързана с Next.js Image Optimization API.

Проблемът не се намира директно в React компонент, Server Action или API route.

Той е по-надолу в dependency chain-а.

Next.js използва sharp за image optimization, а sharp разчита на библиотеки за декодиране и обработване на различни image формати.

Уязвимост в libheif може да бъде достигната при обработване на специално подготвено AVIF изображение.

При подходящи условия това позволява unauthenticated remote code execution.

Това е добър пример защо security моделът на едно модерно web приложение не приключва с кода, който сами сме написали.

Може никога да не сме писали image decoder, използвали libheif директно или добавяли тази библиотека ръчно към проекта и въпреки това dependency graph-ът на приложението ни може да стига до нея.

Точно затова framework и dependency updates не са само начин да получаваме нови функции.

Понякога те са част от security perimeter-а на приложението.

„Но ние не качваме AVIF изображения“

Това само по себе си не е достатъчна проверка.

Важният въпрос е:

Може ли външен или недоверен източник да накара Next.js image optimizer-а да обработи AVIF файл?

Например приложение може да:

  • приема изображения от потребители;
  • зарежда изображения от външни URL адреси;
  • използва CMS или media storage;
  • позволява съдържание, контролирано от клиенти или редактори;
  • подава remote изображения през стандартния next/image pipeline.

Важно е и кой контролира това съдържание.

CMS сам по себе си не означава автоматично повишен риск.

Има голяма разлика между CMS, в който изображения качва само доверен администратор и система, в която произволен потребител или външна услуга може да подаде изображение.

Какво бихме проверили?

При такъв проект бихме започнали от next.config.js или next.config.ts.

Например:

typescript
images: {
  remotePatterns: [
    // ...
  ],
}

Разбира се, само проверката на remotePatterns не е достатъчна.

Бихме проследили целия път: откъде идва изображението, кой може да го контролира, минава ли през Next.js Image Optimization и какво реално достига до production.

Бихме проверили и:

  • използването на next/image;
  • remote image sources;
  • local image routes;
  • unoptimized;
  • custom image loader, ако има такъв;
  • user-generated content;
  • CMS и external media integrations.

Има и един важен детайл.

images.formats не трябва да се бърка с входния формат на изображението.

Тази настройка основно влияе върху предпочитания output формат, който Next.js image optimizer-ът връща към клиента.

При конкретната уязвимост по-важният въпрос е дали непроверено AVIF изображение може да достигне до image optimization pipeline-а за декодиране и обработка.

В поправените версии Next.js временно деактивира AVIF optimization, докато fix-ът в upstream dependency chain-а бъде разпространен.

2. Критична RCE уязвимост при Windows-hosted Next.js приложения

Втората уязвимост е значително по-специфична.

Тя се проявява при конкретна комбинация от:

  • Next.js приложение, работещо върху Windows filesystem;
  • едновременно използване на Pages Router и App Router;
  • конфигурация без Cache Components.

При тези условия е възможно да се стигне до unauthenticated remote code execution.

Тук hosting средата е пряка част от attack surface-а.

Този конкретен advisory се отнася до Windows-hosted Next.js сървъри и е свързан с поведението на Windows filesystem-а.

За засегнатите Windows deployments няма известен workaround.

Решението е upgrade към поправена версия.

И точно тук се вижда защо твърдението:

„Сайтът използва Next.js.“

не казва достатъчно за реалния риск.

Два проекта могат да използват една и съща framework версия, но да имат напълно различен attack surface заради:

  • hosting средата;
  • router архитектурата;
  • configuration flags;
  • dependencies;
  • начина, по който приемат външно съдържание.

А какво става с Next.js 14 и по-стари проекти?

Това е особено важен въпрос при production приложения, които не са обновявани отдавна.

Към момента Next.js поддържа:

  • 16.x - Active LTS
  • 15.x - Maintenance LTS

Next.js 14 и по-старите major версии вече са извън стандартната LTS поддръжка.

Това означава, че ако приложение използва стара неподдържана линия, въпросът не е просто:

„Кой patch да инсталирам?“

Next.js 14 попада в засегнатите version ranges и за двете уязвимости. Тъй като вече е извън стандартната LTS поддръжка и няма отделен patched release за тази major линия, практическото решение е миграция към поддържана версия.

И точно затова отлагането на dependency updates с години обикновено прави следващата спешна актуализация значително по-трудна.

Практичен checklist: какво реално да проверите

1. Проверете коя Next.js версия действително е инсталирана

npx next --version

или:

npm ls next

Първата команда показва версията на Next.js CLI, а npm ls next е полезна и за проверка коя версия действително присъства в dependency tree-а на проекта.

Не разчитайте само на това какво пише в package.json.

2. Проверете коя е актуалната версия в поддържаната линия

Например:

npm view next@16 version

или за Next.js 15:

npm view next@15 version

Това е по-полезно от копиране на конкретна patch версия от стара статия или advisory, защото междувременно може вече да има по-нов security или bugfix release.

Проверете и дали major версията, която използвате, все още е официално поддържана от Next.js.

3. Проверете image configuration-а

Потърсете конфигурацията за изображения:

grep -R "remotePatterns\|localPatterns\|images:" next.config.*

При по-голям проект може да потърсите и използването на next/image:

grep -R "next/image" app pages src components 2>/dev/null

Ако използвате rg (ripgrep):

rg "next/image|remotePatterns|localPatterns|unoptimized|loader"

Тук целта не е просто да намерите AVIF файл, а да разберете откъде идват изображенията и може ли недоверен източник да ги подаде към Next.js image optimizer-а.

4. Проверете върху каква операционна система работи Next.js

От Node.js:

node -p "process.platform"

Типични резултати са:

linux
win32
darwin

При Linux server може да проверите и:

uname -a

или:

cat /etc/os-release

Това е особено важно за Windows-specific уязвимостта от августовския security release.

5. Обновете Next.js и lockfile-а

Ако проектът е на Next.js 16 и искате най-новата съвместима версия в тази поддържана major/LTS линия:

npm install next@16

Ако проектът използва eslint-config-next, обновете и него до същата major линия:

npm install --save-dev eslint-config-next@16

За Next.js 15 използвайте:

bash
npm install next@15
npm install --save-dev eslint-config-next@15

След това проверете действително инсталираните версии и прегледайте промените:

bash
npm ls next eslint-config-next
git diff -- package.json package-lock.json

Не обновявайте production проект на сляпо към нова major версия само заради security patch, ако поправена версия съществува в текущата поддържана линия.

6. Направете production build

npm run build

Следете не само дали процесът завършва успешно, но и за:

  • warnings;
  • deprecated configuration;
  • TypeScript проблеми;
  • route errors;
  • image optimization проблеми.

Ако проектът има lint script:

npm run lint

Ако има автоматизирани тестове:

npm test

7. Проверете какво точно ще бъде deploy-нато

Преди deployment:

git status

и:

git diff --check

По желание може да запишете и commit-а:

git rev-parse HEAD

Това дава конкретен Git SHA, с който после може да сравните production deployment-а.

8. Deploy-нете новия build

Тук няма една универсална команда.

Deployment-ът зависи от инфраструктурата:

  • Vercel;
  • Docker;
  • VPS;
  • собствен Node.js server;
  • друга cloud платформа.

При Docker например трябва да бъде изграден нов image:

docker build -t my-next-app .

а не просто да се рестартира container, изграден със старата Next.js версия.

9. Проверете production след deployment

Първо потвърдете, че сайтът отговаря:

curl -I https://example.com

След това проверете основните routes и функционалности в реалната production среда.

Ако deployment системата пази Git commit SHA, сравнете го с:

git rev-parse HEAD

Така може да потвърдите, че активният deployment действително е изграден от commit-а със security update-а.

Накрая проверете отново:

  • изображенията;
  • CMS съдържанието;
  • authentication;
  • API routes;
  • Server Actions;
  • формите;
  • checkout или плащанията;
  • production logs.

Най-кратко:

bash
npx next --version
npm ls next
node -p "process.platform"
npm view next@16 version
npm install next@16
npm install --save-dev eslint-config-next@16
npm run build
npm test
npm run lint
git diff --check
git rev-parse HEAD

Тези команди не заменят security анализа. Те просто помагат да проверим дали работим с правилната версия, дали update-ът е минал коректно и дали след deployment приложението в production е това, което очакваме.

А npm audit достатъчен ли е?

Не.

npm audit е полезен сигнал и има място в нормален dependency workflow.

Но не трябва да бъде единственото доказателство, че даден framework security issue е отстранен.

При прясно публикуван advisory по-надеждният източник е самият framework/vendor advisory и конкретните версии, които maintainers са посочили като patched.

Security проверката не трябва да бъде:

„npm audit е зелено, значи всичко е наред.“

А:

„Проверихме конкретната уязвимост, dependency версията, конфигурацията и production deployment-а.“

Защо този security release е интересен и отвъд конкретните две уязвимости?

За нас по-големият урок не е:

„Next.js има security проблем.“

Всеки достатъчно голям framework и dependency ecosystem ще има security fixes.

По-важният въпрос е:

Колко бързо един production проект може безопасно да реагира, когато такъв fix се появи?

Проект с:

  • актуални dependencies;
  • поддържана framework версия;
  • проследим lockfile;
  • възпроизводим build;
  • ясна hosting архитектура;
  • version-controlled deployment;
  • добра представа откъде идва външното съдържание;

може да бъде patch-нат сравнително спокойно.

При проект, който не е обновяван с години, една security актуализация може внезапно да се превърне в migration project.

Например:

„Трябва само да обновим Next.js.“

може бързо да се превърне в:

„Трябва първо да обновим Node.js, React, Next.js, няколко dependencies, да оправим deprecated API-та, после build-а и чак тогава да deploy-нем.“

Това е една от причините редовната техническа поддръжка да има стойност дори когато сайтът видимо „си работи“.

Как подхождаме ние към подобни Next.js security updates

При Next.js проект не бихме определили дали е защитен само по номера на framework версията.

Гледаме целия път: Framework, dependencies, application configuration, external content, hosting, build, deployment, production.

При security release-а от август бихме започнали с:

  • реалната Next.js версия;
  • LTS статуса на проекта;
  • image optimization pipeline-а;
  • hosting средата;
  • router архитектурата;
  • dependency и lockfile update;
  • production build;
  • regression test;
  • deployment;
  • потвърждение кой build действително обслужва production.

Това е малка разлика в начина на мислене, но важна.

Security не е:

„Обновихме package.json.“

Security е:

„Знаем какво работи в production и сме потвърдили, че известният уязвим code path вече не е част от активния deployment.“

Ако проектът ви изисква текущи dependency updates, debugging, deployment или техническо развитие, това е част от работата по Next.js поддръжка и развитие.

Трябва ли да обновите Next.js?

Ако използвате засегната версия - да.

Security release-ът от 25 август 2026 г. публикува поправките в:

  • 15.5.24
  • 16.3.3

Ако проектът ви е на поддържана LTS линия, проверете най-новата съвместима версия в същата major/LTS линия и планирайте upgrade.

Ако проектът е на Next.js 14 или по-стара неподдържана версия, не приемайте автоматично, че липсата на patch за конкретната ви версия означава липса на риск. Тук вече трябва да бъде оценено и преминаването към поддържана версия.

Не разчитайте само на това какво пише в package.json.

Не разчитайте само на това, че локално всичко работи.

Не приемайте, че cloud hosting автоматично поправя application dependencies вместо вас.

При security update най-важният въпрос е прост:

Какво действително работи в production в момента?

Официални източници

Автор: Борислав Димитров
Full Stack Developer
Next.js • SEO • AI Visibility