CVE-2025-29927
Next.js: почему проверка входа могла пропустить постороннего
Если сайт на Next.js проверяет доступ только в middleware, некоторые старые версии позволяют обойти эту проверку. Узнайте способ размещения сайта, обновите Next.js и проверьте защиту самих данных.
Кому нужно проверить
Владельцам сайтов с личным кабинетом, платными материалами или административными страницами на Next.js. Разработчику нужно проверить, где именно приложение решает, кому разрешено читать и менять данные. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Middleware — промежуточная проверка перед обработкой запроса. Представьте охранника перед дверью: старый Next.js мог принять внешний запрос за внутреннее обращение приложения и пропустить этот пост. Если за дверью больше никто не проверяет права, посторонний получает доступ к действиям или данным. Уязвимость не создаёт учётную запись и не расшифровывает пароль. Результат зависит от того, какие операции защищены только этим промежуточным слоем. Серверная проверка прав непосредственно перед чтением или изменением данных остаётся необходимой.
Затронутые версии
По таблице advisory проекта затронуты next начиная с 11.1.4 до 12.3.5, ветка 13 начиная с 13.0.0 до 13.5.9, ветка 14 до 14.2.25 и ветка 15 до 15.2.3; верхние границы не включаются. Условие — проверка прав в middleware. Vercel подтвердил применимость к самостоятельному размещению через next start и output: 'standalone'. Статический экспорт не использует такой серверный middleware. По разбору производителя размещения на Vercel, Netlify и Cloudflare Workers не были затронуты этим механизмом; это не гарантия безопасности любого стороннего адаптера.
Исправленные версии
Первоначальные исправления: 12.3.5, 13.5.9, 14.2.25 и 15.2.3. Для 11.x advisory предлагает временную фильтрацию запросов. Сегодня выбирайте поддерживаемую ветку с актуальными исправлениями, а не устанавливайте старый минимальный выпуск только ради этого CVE. Пакет в рабочем образе должен действительно обновиться: одного изменения package.json недостаточно.
Что сделать
- 1Попросите разработчика назвать фактически развёрнутую версию next, способ запуска и место проверки прав. Проверьте рабочий контейнер или установленный релиз, а не только копию проекта на ноутбуке. Не отправляйте специальные запросы для обхода защиты на действующий сайт.
- 2Составьте список закрытых страниц и серверных операций: просмотр заказов, выгрузка документов, изменение настроек. Уточните, проверяют ли они личность пользователя и принадлежность данных независимо от middleware.
- 3Если обновление задерживается, на внешнем прокси блокируйте входящие запросы с x-middleware-subrequest, как рекомендует проект. Настройка зависит от прокси и должна охватывать все входы, включая прямой доступ к серверу. Это временная мера, не замена исправлению.
- 4Сохраните исходный код, файл фиксации зависимостей и предыдущий образ. На тестовой копии установите исправленный поддерживаемый выпуск, пересоберите приложение и проверьте совместимость. Если меняется база данных, отдельно подготовьте её резервную копию и проверенный порядок восстановления.
- 5Разверните новый образ на всех экземплярах. План отката должен сохранять внешнюю фильтрацию и ограничения доступа: возврат старого образа возвращает и ошибку. При неудаче безопаснее временно закрыть затронутые функции.
- 6Проверьте обычным браузером без входа, с обычным пользователем и с администратором, что закрытые операции доступны только нужной роли. Проверяйте не только видимость кнопок, но и серверный отказ в доступе. Сверьте версию работающего приложения после развёртывания.
- 7Изучите журналы доступа и изменения важных данных за период работы уязвимой версии. Отсутствие подозрительных записей не доказывает отсутствия обхода. При обнаружении чужих действий сохраните журналы и начните разбор инцидента.
Где должна проверяться защита
Статичная схема показывает два разных места проверки. Нумерация и текст передают смысл без цвета и движения.
- 1Посетитель запрашивает закрытые данные
- 2Middleware выполняет предварительную проверку
- 3Серверная операция отдельно проверяет пользователя и права
- 4Данные выдаются только после успешной проверки прав
Примеры конфигурации и проверки
npm ls next --depth=0Для проекта, установленного через npm, с доступным npm и node_modules. Запускайте в каталоге развёрнутого приложения от его обычного пользователя; root не нужен. Ожидается строка next@ с версией. Команда ничего не устанавливает, откат не требуется. Ошибка или пустой результат не означают безопасность: standalone-образ может не содержать npm или полного дерева зависимостей. В таком случае проверьте состав образа и журнал сборки. Не публикуйте полный вывод с внутренними путями.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.