Если сайт на Next.js сам собирает картинки для превью ссылок, проверьте не только вид карточки, но и код её генератора. После сообщения Next.js от 22 сентября 2026 года главный вопрос — использует ли проект ImageResponse в среде Node.js и попадают ли внешние данные в SVG. Владелец проекта может начать с трёх подтверждений: версия работающей сборки, среда выполнения маршрута и происхождение данных в изображении.
Кому это актуально
Разбор адресован владельцу сайта или руководителю продукта, у которого превью товаров, публикаций или профилей создаются автоматически. Open Graph — это метаданные для представления ссылки; изображение из них может показываться в мессенджере или социальной сети. В Next.js функция ImageResponse позволяет собирать такие изображения из разметки и стилей.
Наличие красивого превью ничего не говорит о способе его создания. Готовый файл, генерация при сборке и обработчик, который создаёт картинку по запросу, требуют разной проверки. Если этой частью сайта занимался прежний подрядчик, попросите разработчика найти фактический обработчик, а не определять технологию по внешнему виду.
Какие риски закрывает проверка
В предупреждении Next.js GHSA-vcvr-r3jv-pc5j описан риск удалённого выполнения кода в Node.js-реализации ImageResponse из next/og. Он относится к затронутым приложениям, которые передают управляемые злоумышленником значения в содержимое, атрибуты или стили SVG — формата векторной графики. Возможные последствия зависят от прав процесса приложения; само предупреждение не доказывает, что сайт уже взломан.
На дату проверки, 26 сентября 2026 года, официальный диапазон затронутых версий — от 16.2.0 включительно до 16.3.6 не включительно. Исправление выпущено в 16.3.6. Согласно сообщению разработчиков, Next.js 15.x не затронут именно этим риском выполнения кода, а выпуск 15.5.26 содержит дополнительное усиление защиты.
Отдельно в официальном предупреждении указано, что Edge-реализация и приложения без передачи управляемых извне значений в SVG не затронуты этим сценарием. Это узкая граница конкретной проблемы, а не оценка всей безопасности проекта.
Не проверяйте рабочий сайт вредоносными картинками или готовым эксплойтом. Для первичного решения достаточно сопоставить версию, среду выполнения и путь данных с официальным предупреждением.
Как проверить генератор превью
1. Найти маршрут и фактическую версию
Попросите разработчика проверить импорты ImageResponse из next/og, файлы opengraph-image и собственные обработчики изображений. Документация Next.js допускает использование этой функции и в обработчике запроса, и в файле метаданных. Проверка только одного привычного адреса может пропустить другой генератор.
Для каждого найденного места нужна небольшая карточка: публичный маршрут, способ генерации, среда Node.js или Edge, версия Next.js в работающей сборке. Номер в техническом задании или диапазон зависимости в package.json не подтверждает, какой пакет попал в действующий выпуск.
2. Проследить путь внешних данных
Пусть разработчик отметит, откуда берутся текст, атрибуты и стили для SVG. Источником может быть параметр адреса, запись пользователя, поле каталога или внешний сервис. Данные из базы тоже требуют проверки происхождения: запись могла появиться там через доступную посетителю форму.
Полезный результат — короткая цепочка «источник → преобразование → место подстановки». Например, в условном сервисе пользователь меняет подпись профиля, а обработчик добавляет её в SVG для превью. Это повод проверить путь подписи по коду; сам пример не устанавливает уязвимость конкретного сайта.
3. Зафиксировать решение
Сведения удобно разделить на три результата:
- Условия совпали. Есть затронутая версия, Node.js-обработчик и управляемые извне значения в SVG. Нужны исправленный выпуск и проверка его доставки в рабочую среду.
- Условия исключены доказательствами. Подтверждены другая реализация либо отсутствие такого пути данных. Сохраните основание вывода и продолжайте обычный процесс обновлений.
- Сведений недостаточно. Версия, среда или происхождение данных неизвестны. Это незавершённая проверка; ответ «у нас только картинки» её не закрывает.
Если обновить приложение сразу нельзя, официальное предупреждение предлагает временно исключить передачу управляемых извне значений в SVG этого обработчика. Возможный способ для конкретного проекта — подготовленное статичное превью, но разработчик должен подтвердить, что прежний динамический путь больше недоступен. Смена ссылки на картинку в метаданных сама по себе этого не доказывает.
4. Принять результат после обновления
Проверяйте отдельно исправление зависимости и работоспособность изображений. На тестовой среде, похожей на рабочую, полезны обычные карточки с кириллицей, длинным заголовком, отсутствующей картинкой и пустым необязательным полем. Ожидаемый результат задают заранее: читаемое изображение или предусмотренная замена без внутренней ошибки.
После выпуска нужны подтверждение версии на всех обслуживающих экземплярах и проверка каждого найденного генератора. Превью, сохранённое в кеше, не подтверждает работу нового кода: проверяйте также фактическую генерацию в контролируемых условиях. Не требуется очищать весь кеш рабочего магазина ради одного теста.
Если появились признаки посторонних изменений, обычного патча недостаточно. Сохранение диагностических данных и разбор возможного инцидента становятся отдельной задачей; обновление не является доказательством отсутствия прежнего доступа.
Что запросить у подрядчика
Для приёмки полезен небольшой комплект доказательств:
- список генераторов превью и среда выполнения каждого;
- версия Next.js в проверенной рабочей сборке;
- схема происхождения значений, попадающих в SVG;
- вывод о применимости предупреждения с основанием;
- результаты проверки изображений до и после изменения;
- способ безопасного возврата сервиса при сбое релиза.
Откат на прежний уязвимый обработчик может вернуть исходный риск. Поэтому аварийный вариант стоит согласовать заранее: например, временную выдачу подготовленных изображений при отключённом динамическом маршруте. Формулировка «пакет обновлён» не заменяет эти критерии.
Как это решает OpenStart
Если у команды есть доступ к исходному коду, воспроизводимая сборка и тестовая среда, такую проверку можно провести своими силами. Отдельный подрядчик полезен, когда неизвестно, где создаются картинки, код передан без документации или исправление связано с другими частями приложения.
В рамках разработки и поддержки React- и Next.js-проектов OpenStart разбирает существующий код, зависимости и сборку, а изменения проверяет до релиза. Для этого сценария разумно сначала согласовать диагностику генераторов и критерии приёмки. Объём дальнейших работ зависит от найденной реализации, без обещания заранее известного результата.
Для первичного описания задачи достаточно публичной ссылки и пояснения, какие превью создаются автоматически. Пароли, ключи и пользовательские данные в обращении не нужны. После обращения можно согласовать объём проверки, риски и следующий шаг.
Частые вопросы
Если картинки отображаются правильно, проверка всё равно нужна?
Да, если у проекта есть потенциально затронутый генератор. Обычный внешний вид подтверждает работу знакомого сценария, но не показывает версию зависимости и путь внешних данных.
Достаточно обновить Node.js на сервере?
Предупреждение относится к реализации в Next.js и её зависимостям. Обновление среды Node.js само по себе не подтверждает установку исправленной версии пакета Next.js.
Нужно ли срочно переносить генератор на Edge?
Предупреждение исключает Edge-реализацию из этого сценария, но перенос может изменить совместимость кода. Выбор среды — отдельное решение; исправление существующего приложения следует оценивать по официальному обновлению и его проверке.
Можно ли дождаться следующего планового выпуска безопасности?
Уже выпущенное исправление для затронутой конфигурации следует обрабатывать отдельно от будущего релиза. Анонс следующего выпуска не означает, что текущая проблема устранена в работающей сборке.