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

Category: Уеб и бизнес

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

На 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**](https://www.cloudflare.com/learning/security/what-is-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 поддръжка и развитие](https://evtinwebsite.com/nextjs-poddrazhka-i-razvitie).

## Трябва ли да обновите 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 в момента?**

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

- [Next.js - August 2026 Security Release](https://nextjs.org/blog/august-2026-security-release)
- [Next.js Support Policy](https://nextjs.org/support-policy)
- [GitHub Security Advisory GHSA-2xp9-vwfh-vxw4](https://github.com/vercel/next.js/security/advisories/GHSA-2xp9-vwfh-vxw4) - Unauthenticated Remote Code Execution in Image Optimization API when AVIF files are used
- [GitHub Security Advisory GHSA-p293-qw3h-jr36](https://github.com/vercel/next.js/security/advisories/GHSA-p293-qw3h-jr36) - Unauthenticated Remote Code Execution on Windows-hosted servers
- [libheif Security Advisory GHSA-g89c-p67h-r497](https://github.com/strukturag/libheif/security/advisories/GHSA-g89c-p67h-r497)

> Автор: [Борислав Димитров](https://www.linkedin.com/in/borislav-dimitrov-fizer/)
> Full Stack Developer
> Next.js • SEO • AI Visibility

---

Source: https://evtinwebsite.com/blog/next-js-security-update-2026-dve-kritichni-rce-uyazvimosti